---
title: Can Cheaper Models Use Your MCP Server? A 90-Run Test
description: Can a small, cheap model use your MCP server? Same jobs, before and after fixes: a free model passed 10/10 like the frontier ones. Fix tools, then test it.
canonical: https://spiritroom.app/blog/cheaper-models-mcp-reliability/
published: 2026-10-21
updated: 2026-10-21
---

> Markdown version of https://spiritroom.app/blog/cheaper-models-mcp-reliability/ for agents. Index: /llms.txt

[Blog](/blog/) / [Agent experience (AX)](/guides/agent-experience-ax/)

# 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.

Leonid Bugaev · Published 21 Oct 2026

**TL;DR**

- **On our server, the small model matched the frontier ones.** A free GLM-5.3 Flash model in OpenCode passed 10 of 10 runs before and 10 of 10 after the fixes, the same as Claude Code's and Codex's default models (each 72–100%).
- **The small model needed the clear descriptions most.** With terse descriptions it never used the summary tool on counting questions (0 of 6) and paged through lists instead: 17 list calls. With clear ones it used it in 4 of 6, and the other 2 used the overview tool.
- **Fixes cut its cost:** median input tokens 21,344 → 17,168 (−20%), tool result text −93%, errors 1 → 0, median time 10.3 s → 7.6 s.
- **The jobs were simple lookups.** Published benchmarks find small models weaker on multi-step work. Fix the tools first, then test the downshift on your own jobs, including the hard ones.
[Why downshift](#question)[The test](#setup)[Results](#results)[What the small model needed](#needed)[How to test a downshift](#how)[How we measured](#how-we-measured)[FAQ](#faq)

## 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.

Same 5 jobs**→**3 server versions**→**Small vs 2 frontier models**→**Pass, tokens, errors

## Results

Pass rate · median input tokens per job (10 runs per cell, mock, 21 Oct 2026)

| 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.

[Test a cheaper model →](/#contact)

## What the small model needed

The small model didn't fail, but it worked harder on the worst version of the server:

Small free model, before → fixed (10 runs each)

| 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?](/blog/per-model-mcp-tool-surfaces/)

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

1. **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.
2. **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.
3. **Run each job several times per model** and report pass/N with a range. See [pass rates and confidence intervals for agent runs](/blog/agent-pass-rates-confidence-intervals/).
4. **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](/blog/cost-per-successful-agent-task/).
5. **Route, don't replace.** Send the jobs that pass to the small model and keep the rest on the frontier one.

**Go deeper:** [Agent experience: how to measure it](/guides/agent-experience-ax/), [MCP server or CLI for AI agents?](/blog/mcp-vs-cli-for-agents/), [How to measure MCP server quality](/blog/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.

[Test a cheaper model →](/#contact)

## Keep reading

- Up[Agent experience (AX): how to measure it (guide)](/guides/agent-experience-ax/)
- Related[Cost per successful task: the one number that shows if your tools are agent-ready](/blog/cost-per-successful-agent-task/)
- Related[Per-model MCP tool surfaces: 90 runs across three models](/blog/per-model-mcp-tool-surfaces/)