feat: catch invalid model params before the provider does

[brunobuddy]

💭 Why

The catalog has always recorded which parameter combinations providers reject. Nothing acted on it. parseParams even said so in a comment: cross-parameter rules were "not yet enforced".

So the data that makes this catalog different from a model-metadata list was display-only.

✨ What changed

• POST /api/v1/validate returns the problems plus a corrected safeParams payload.
• New modelparams-mcp package: 4 read-only MCP tools, stdio, catalog bundled in.
• New llm-model-parameters agent skill (skills.sh format).
• modelparams gains checkApplicability, isApplicable, dropUnsupported, resolveModelId.
• parseParams now enforces cross-parameter rules.
• Both packages release in lockstep; modelparams-mcp pins modelparams exactly.
• CONTRIBUTING.md: new directories, and that applicability rules are now enforced.

👤 For users

Three issue codes come back: unknown_parameter, invalid_value, not_applicable (with conflictsWith). safeParams is always a payload that passes validation, so a caller can spread it and move on.

Catches the cases people currently hit as provider 400s: top_p with a non-default temperature on Anthropic, sampling knobs on reasoning models, a thinking budget without thinking enabled.

🔧 For operators

modelparams-mcp needs its own npm trusted publisher before the first release, pointing at release-modelparams.yml (org mnfst, repo modelparams.dev). Without it that publish step fails. Renaming the workflow file breaks trusted publishing for both packages.

Submitting the server to the MCP registry is still manual.

📝 Notes

• No backend. The 239-model catalog compiles into the function from the committed generated data.
• Verified with a local vercel build: the function builds and runs, and static /api/v1/*.json is unaffected. Header rules layer, so the no-store rule for /api/v1/validate has to stay after the general /api/(.*) s-maxage rule or verdicts get cached across callers.
• 245 tests (165 site, 62 package, 18 MCP), including a stdio smoke test in CI.
• Applicability evaluation falls back to a parameter's catalog default when the request omits it, since that is what the provider applies instead.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
modelparams.dev	Ready	Preview	Jul 30, 2026 8:00am

[brunobuddy]

Superseded by a stack of four, one per feature, so each can be reviewed on its own:

• feat: reject parameter combinations providers won't accept #170 — the applicability engine in the modelparams package
• feat: add an endpoint that checks params before you call a model #171 — POST /api/v1/validate (on feat: reject parameter combinations providers won't accept #170)
• feat: let agents look up model params over MCP #172 — the modelparams-mcp server (on feat: add an endpoint that checks params before you call a model #171)
• feat: add an agent skill for looking up model params #173 — the agent skill (on feat: let agents look up model params over MCP #172)

Same work, plus two fixes the split surfaced: resolveModelId was returning empty suggestion lists because it matched a bare query against the full provider/model id, and the lockfile here disagreed with the MCP package's own package.json.