Can cheaper models use your MCP server? Fix the tools, then downshift
Frontier models are the default in every agent app, and they're the expensive part. If your users or your own agents could run on a smaller model, the bill drops. The question is whether a small model can use your tools, and whether fixing the tools changes the answer.
Why downshift
Most of the cost of an agent run is model tokens, and a frontier model's tokens are the most expensive. Plenty of agent work is not frontier work: “how many tasks are blocked in this project?” is a lookup. If a smaller model can do your users' common jobs through your server, you can route those jobs to it, or recommend it to users who pay per token.
The worry is that small models are worse at tools. That's true in general benchmarks. Our question was narrower: on one server, before and after fixing it, does a small model get the job done?
The test
We used a mock task-tracker server with synthetic data and 21 tools, in three versions: before (terse descriptions, verbose errors, big default results, plain dates rejected), better descriptions, and fixed (better descriptions plus short errors, plain dates accepted, small default results). Five everyday questions, two runs each, on each version, with three models:
- Small: GLM-5.3 Flash, a free model, in OpenCode.
- Frontier: Claude Code's default model and Codex's default model, in their own apps.
Results
| Model | Before | Better descriptions | Fixed |
|---|---|---|---|
| Small free model (OpenCode) | 10/10 · 21,344 | 10/10 · 20,756 | 10/10 · 17,168 |
| Claude Code, default model | 10/10 · 26,960 | 10/10 · 20,293 | 10/10 · 20,249 |
| Codex, default model | 10/10 · 89,129 | 10/10 · 89,101 | 10/10 · 78,126 |
Every cell passed 10 of 10 (95% range 72–100%) after we read the answers by hand; two of the small model's answers were first marked wrong by our checker for mentioning a task while correctly explaining why it was excluded. Token counts compare each model with itself: each app sends its own system prompt, so the absolute numbers aren't a like-for-like price comparison.
Find out if a cheaper model can do your users' jobs.
We run your real jobs on frontier and smaller models against your server, before and after fixes, and report pass rates, tokens and failures for each, so you know when downshifting is safe.
What the small model needed
The small model didn't fail, but it worked harder on the worst version of the server:
| Measure | Before | Fixed |
|---|---|---|
| Used the summary tool on the 3 counting questions | 0 of 6 runs | 5 of 6 runs (the 6th used the overview) |
| List calls on those questions | 17 | 0 |
| Total tool calls | 32 | 19 |
| Tool result text | 68,521 chars | 4,911 chars |
| Runs with an error | 1 | 0 |
| Median time per job | 10.3 s | 7.6 s |
With terse descriptions, the summary tool was described as “Stats.”, and the small model never used it: it listed tasks and counted them itself. Claude Code did the same in 5 of 6 runs; Codex found the summary tool anyway. Once the description said what the tool returns and when to use it, both switched. The per-model detail is in should your MCP server look different to each model?
The one error was the same one every model made: asking for activity “since 2026-10-14” when the server wanted a full timestamp. Accepting the format agents actually send removed it for all three.
How to test a downshift on your server
- Fix the surface first. Clear descriptions, plain input formats, short errors and small default results helped the small model most. A downshift test on an unfixed server underrates small models.
- Use your real jobs, including multi-step ones and ones that need a confirmation before writing. Ours were 1–4 call lookups; that's where small models are strongest.
- Run each job several times per model and report pass/N with a range. See pass rates and confidence intervals for agent runs.
- Compare cost per successful task, not price per token: a cheap model that needs twice the calls or fails one job in five may cost more. See cost per successful task (coming soon).
- Route, don't replace. Send the jobs that pass to the small model and keep the rest on the frontier one.
Go deeper: MCP server or CLI for AI agents?, How to measure MCP server quality.
How we measured
- Server: local mock, synthetic data (4 projects, 6 people, 36 tasks, 76 events), 21 tools in three versions; write tools changed nothing and weren't called.
- Models and apps: OpenCode 1.18.34 with the free GLM-5.3 Flash model; Claude Code 2.1.304 and Codex CLI 0.161.0 with default models. Headless, isolated from other servers, 21 Oct 2026, about 21:10–21:35 (UTC+3). No paid API usage.
- Scoring: answers checked in code against known answers, failures read by hand; 5 of 90 overridden to pass across all models, reasons recorded.
- Tokens and text: from each app's usage report (cached input included); result text is the characters returned by tools.
- Limits: one small model, short lookups, 2 runs per job. 10/10 can't show a small difference; multi-step and write jobs weren't tested.
FAQ
Can smaller AI models use MCP servers reliably?
For simple lookups on a well-described server, yes in our test: a free small model in OpenCode passed 10 of 10 runs, the same as Claude Code's and Codex's frontier models. Public benchmarks find small models weaker on multi-step planning, so test your own harder jobs before switching.
Does fixing my MCP tools help small models more than large ones?
Clear descriptions helped the small model and Claude Code pick the right tool; Codex picked it either way. Behaviour fixes, such as accepting plain dates, short errors and small default results, helped every model about equally, cutting result text by 87–93%.
How much cheaper is a small model per task?
It depends on prices, but the token count is comparable: after the fixes, the small model used a median 17,168 input tokens per job, against 20,249 for Claude Code and 78,126 for Codex in their own apps. The per-token price difference then decides the saving.
How do I test whether a cheaper model can use my server?
Run your users' real jobs on both models, several runs each, against a fixed version of your server, and compare pass rate with confidence ranges, tool choice, errors and tokens. Include multi-step and write-with-confirmation jobs, where small models tend to fail.
Find out if a cheaper model can do your users' jobs.
We run your real jobs on frontier and smaller models against your server, before and after fixes, and report pass rates, tokens and failures for each, so you know when downshifting is safe.