feat(mcp): list_provider_models — a provider's whole surface in one call

[guillaumegay13]

What this changes

Adds list_provider_models to the MCP server, and drops find_models_supporting.

The tools answered "tell me about this model". The question a team with AWS or GCP credits actually has is the other way round: the provider is fixed, and what's open is which models it serves, what each one is called on the wire, and which parameters each one takes. Answering that today costs one list_models call plus one get_model_params call per model — 57 round trips for Bedrock.

list_provider_models answers it in one call.

Profiles, not a flat dump

A provider's models are far less varied than their count suggests — Converse normalises Bedrock's 56 models down to four distinct parameter surfaces. So models that share a surface share a profile, and the models list points at it. That grouping is what makes a whole provider fit in a tool result at all:

provider	models	profiles	as profiles	flat
bedrock	56	4	~4.4k tok	~25.8k tok
vertex	11	6	~7.5k tok	~13.6k tok
openai	55	15	~6.1k tok	~17.5k tok
anthropic	42	12	~10.4k tok	~32.4k tok

There is one output shape, not a set of modes: an agent that wants bare ids already has list_models.

Shape

{
  "provider": "bedrock",
  "baseUrls": ["https://bedrock-runtime.*.amazonaws.com"],
  "total": 56, "returned": 56, "truncated": false,
  "paramProfiles": [
    { "id": "p1", "modelCount": 41, "parameterCount": 4, "params": [...], "defaults": {} }
  ],
  "models": [
    { "model": "bedrock/claude-opus-4-6", "authType": "api_key",
      "wireId": "{scope}.anthropic.claude-opus-4-6-v1", "profile": "p2" }
  ],
  "wireIdNote": "A wireId containing {scope} needs one substitution before you send it…",
  "docs": "https://modelparams.dev/providers/bedrock"
}

Profiles are ordered commonest-first, so p1 is the provider's house style. The reply carries each model's wireId, and explains the {scope} placeholder in the response that hands those ids over rather than leaving it to the docs — a Bedrock caller has to substitute a routing geography before sending.

Why find_models_supporting goes

Its inverse index — which models expose parameter X — is subsumed once a provider's whole surface arrives in one call. For anyone pinned to one or two providers by credits, the answer was always within a single provider anyway. Four tools is also about the right budget for an agent's context, and this one earns the slot more.

Lifecycle travels with the row

get_model_params gained status / replacement / shutdownOn in #316. Each model row here carries them too — a tool whose whole job is helping an agent choose a model has to show a retirement on the row being chosen from, not only to whoever looks that model up separately.

PROVIDER_ENDPOINTS is now exported from modelparams (additive) so the reply can name the endpoint the models are served from.

Type of change

• Add a model (new YAML file under models/)
• Add a provider (new folder under models/, plus a logo)
• Add or update parameters on an existing model
• Fix incorrect data (default, range, values, applicability)
• Site or tooling (code under src/, docs, CI)

Source

No data change — catalog YAML is untouched. The {scope} wording matches the existing note in packages/modelparams-mcp/README.md.

Before opening

• npm run validate and npm test pass locally (230 site tests, 30 MCP tests, 77 package tests, tsd type tests)
• npm run lint, npm run typecheck, and both package builds are clean
• The stdio smoke check CI runs advertises the new tool set
• No existing parameter was removed

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
modelparams.dev	Ready	Preview	Aug 20, 2026 10:07pm