Cyclr has published benchmark findings that put a number on a design choice many AI product teams have been treating as plumbing: how much of an API a Model Context Protocol server exposes to a language model.
According to Cyclr, task-scoped “thin MCP” configurations used roughly 75% fewer tokens than broad “thick MCP” setups while producing the same clean first-answer accuracy in its tests. That is a cost claim, but it is also a systems-design claim. The model’s bill is being shaped by the tool surface it sees before it starts doing useful work.
The benchmark, titled MCP Server Design and Token Efficiency, evaluated 30 controlled configurations across HubSpot, Oracle NetSuite and QuickBooks. Cyclr ran the tests using Claude Haiku 4.5 and GPT-5-mini.
A thin MCP server gives the model only the tools needed for a specific task. A thick MCP server exposes the model, through MCP, to all tools available inside an API. In agentic SaaS interfaces, that difference matters because tool definitions, schemas and response payloads are loaded into context. Those tokens are spent before the model has produced an answer, clicked a button or updated a record.
The benchmark also found that direct API access was not the low-cost baseline. Cyclr reported that raw direct API access consumed 58% more tokens per task than thin MCP, even though it avoided tool-definition overhead, and produced the lowest clean first-answer accuracy among the tested approaches.
That result cuts against a lazy assumption in some AI builds: removing abstraction does not automatically make the system cheaper or more reliable. If the model has to infer parameters, discover structure through trial and error, or reason across too many possible actions, the token meter can keep running while the system looks busy.
Fraser Davidson, Cyclr’s chief executive, said the design of MCP servers affects cost, speed and reliability as SaaS companies begin distributing MCPs to customers and building more headless product experiences. His point is less about branding MCP as a feature and more about who pays when a model is handed an oversized menu of tools.
Nic Butler, Cyclr’s chief product and technology officer, said the benchmark showed that a narrow, typed and well-scoped interface reduced waste, while too many tools or parameter discovery pushed token use higher and made task completion less dependable.
The technical finding to watch is where the tokens went. Cyclr said output tokens were only a small share of total usage. Most consumption came from context loaded before the useful part of the task began, including tool definitions, schemas and response payloads.
That makes task-scoped MCP server design a production cost control, not an architectural nicety. Teams building agentic SaaS interfaces now have to treat schema size and tool exposure the way backend engineers already treat query plans or cache misses: small choices compound at runtime.
Cyclr’s stated takeaway is to expose the fewest tools that cover real user tasks, keep a typed MCP layer in place and design endpoints around the questions users actually ask. The benchmark does not settle every MCP design debate, but it gives SaaS teams a practical warning: broad context can be expensive even when the answer is short.
