Updated: | Originally published: | By Nic Butler
As more SaaS companies move from experimenting with AI to building it into their products, one question keeps surfacing: how do we make this scale?
It is easy to connect an AI agent to a single system and watch it work in a demo. It is much harder to run that same capability across many integrations, thousands of customers, and millions of requests, and keep it fast, affordable, and reliable the whole way.
The instinct most teams reach for makes that harder. When you are connecting an AI agent to a system like HubSpot or NetSuite, you want to give it everything. Expose the full API. Hand the model every tool you have. The whole job of an agent is to be capable, after all, so why hold capability back?
We ran 30 controlled tests to put that instinct under the microscope, across real SaaS systems and two different models. The most reliable and most affordable agents we measured were the ones with the fewest tools.
Restraint, it turns out, is the discipline that makes agentic integrations work. And it is as much a product decision as an engineering one.
Your AI Agent Needs Fewer Tools
The worry with trimming tools is always the same. Surely a smaller toolset means a less capable agent?
Our tests pointed the other way. A server scoped to just the tools a task needs used around 75% fewer tokens than one that exposed the full API. Same questions, same models and the same data. A quarter of the cost.
The usual fear is that trimming tools costs you accuracy. But in our study, the lean server held its ground. It matched the full server in accuracy of its answers, while costing far less to run.
So why does a smaller toolset win? Every tool you expose carries a schema that loads into the model’s context on every request, whether it uses it or not. Expose forty tools to answer a question that would only need four, and you pay for the other thirty-six on every single call.
The extra tools added cost without adding capability. They were overhead dressed up as flexibility.
Going Direct Was The Worst Option
There is a tempting shortcut hiding in those numbers. If tool definitions cost tokens, why use an MCP server at all? Why let the agent call the API directly, with no schema to load? We tested that path too.
The direct API came out as the most expensive and the least reliable of the three. It burned 58% more tokens than the thin server, and delivered the worst accuracy of the three methods. On some runs a direct API connection churned through 40,000 to 60,000 tokens and still failed to finish the task.
Without a typed schema telling the model what methods exist and what parameters they need, the model starts to guess. It invents a method name, hits an error, corrects itself, and tries again. Every wrong guess is a round-trip you pay for. We started calling it the retry tax. The tokens you save by dropping the schema, you spend several times over on trial and error, and the customer still gets a worse answer.
The lesson is that a typed MCP layer earns its keep. It is the thing that keeps an agent both lean and dependable. A well-built MCP server gives you the small surface area and the guardrails together.
Why This Matters Most For SaaS
In a single demo, a wasteful design is a rounding error. But in an embedded product, it starts to compound.
Let’s do the math. You run many integrations, each one called thousands of times a day, across your whole customer base. A design that wastes tokens wastes them on every task, for every customer, forever. The cost hides quietly until you read the bill or watch latency creep up.
For a SaaS company embedding integrations into its own product, that bill and that experience belong to you. A few percent of waste per call becomes a real line on your budget at the volume an embedded product generates.
Scalable embedded MCP integrations are built on restraint. The leanest, best-scoped server is the one that holds up when you multiply it by your customer base.
How To Design MCP Servers That Scale
The playbook from the research is short and consistent:
- Expose the fewest tools that cover real tasks. Around 75% fewer tokens, with no loss in accuracy.
- Keep the typed MCP layer. The schema is what prevents the retry tax of raw API access.
- Design endpoints around the questions users ask. Surface the fields people actually request, so the agent has a path to them.
- Control response bloat. Keep payloads compact, field-filtered, and paginated.
- Measure tokens per tool and per task. Instrument it, track the schema share, and catch waste before it reaches the invoice.
- Treat every tool call as a recurring tax. Each one costs tokens on every request, and too many of them cut accuracy.
The core takeaway is to treat every tool you expose as a deliberate design choice.
MCP PaaS Makes Restraint Easy To Apply
The catch is that restraint is a discipline you have to apply over and over. Scoping a toolset. Keeping a typed schema. Designing endpoints around the questions customers actually ask. Keeping responses compact. The same work, on every connector, for every system your product touches.
Built from scratch, that is real engineering effort per integration. It is a big part of why teams fall back on exposing the whole API, because it ships faster.
This is the reason we built Cyclr’s MCP PaaS (MCP Platform as a Service). Cyclr gives you a deep library of pre-built connectors and the tooling to turn them into MCP servers scoped exactly the way you want. You decide the surface area of each server, from a tight handful of endpoints for a focused task to a broader set when the use case calls for it.
Discover Cyclr’s Embedded iPaaS
As AI becomes central to modern SaaS, the real differentiator won’t be the model, it will be the infrastructure that connects it to the rest of your ecosystem.
Cyclr’s embedded iPaaS gives you the tools to securely orchestrate data, manage integrations at scale, and empower AI features with the context they need to deliver real value.
Final Thoughts
As AI and embedded interoperability mature, the winners will be the teams whose integrations stay reliable as usage grows. That outcome is a design choice, made early, in how you build your MCP servers.
Fewer tools. A typed layer you keep in place. Endpoints shaped around real questions. Do that, and you get a well-scoped MCP server that behaves consistently.
For any SaaS company building agentic experiences into its product, restraint is the most effective cost-and-quality lever available. If you would like to see how MCP PaaS helps SaaS teams handle this, we would be glad to walk you through it.
