Two years ago, connecting a language model to your CRM was a quarter of the project plan. Today a competent engineer does it before lunch.
Integration friction was doing a second job nobody budgeted for. It forced somebody to justify a connection before the company paid for it. At three weeks, a manager asked what the tool was for. At twenty minutes, nobody asks.
The gate is gone and nothing replaced it.
Three costs land after that, and all three land on the executive rather than the engineer.
Three costs, one cause
Where each one lands
| Cost | What it shows up as | Who owns it |
|---|---|---|
| Context budget | Vaguer answers, higher bills, tools chosen wrong | Whoever signs off the model spend |
| Three-party security | An action taken on your behalf that nobody authorized | Whoever signs the GDPR processing record |
| The unasked question | An agent doing a job a script does better | Whoever defends the budget next year |
None is a protocol flaw. They are what happens when a decision gate disappears and nothing takes its place.
The tool menu charges rent
Every tool an agent can reach has to be described to it, and that description loads before the model reads a word of your request. Thirty servers added over a year, twenty minutes each, and the menu now arrives before the meal every single time.
A workflow that consumed roughly 150,000 tokens passing tool definitions and intermediate results through the model was rebuilt to use about 2,000, a reduction of 98.7 percent.
— Anthropic, Code execution with MCP, November 2025
Do not take 98.7 percent as your number. Take the shape of it and run your own: tokens loaded before the request, times volume, times your rate card. Most teams have never done that multiplication.
A useful scale, from Sebastian Wallkötter’s February 2026 interview with KDnuggets: a 200,000-token window is roughly a full-length novel. It turns something most people treat as unlimited into a budget with edges.
Those edges have competing claims, and the claims are not equal.
Claims on the window
| Claim on the window | Verdict |
|---|---|
| Tool definitions, loaded up front | Yes, load them on demand |
| Intermediate results round-tripping through the model | Yes, keep them in the execution environment |
| Retrieved documents | Partly, through better retrieval |
| Your operating context: rules, formats, what good looks like here | No, and this is the part you are paying for |
The bottom row is the point.
Orchestration and tool catalogs are things you can buy. Context is not, and the tool menu evicts it.
We made that case at length in the piece on buying the platform but not the context.
Your controls assume two parties. There are three.
Who is in the transaction
| Party | Claims | Controls check |
|---|---|---|
| The person | The employee who asked | Usually, yes |
| The model provider | Acting on that person’s behalf | Rarely, and not per action |
| The service reached | Honoring a token it was handed | Only that the token is valid |
The middle row is the one that shows up in a processing record.
If an agent moved personal data, the document has to say on whose instruction, and “the assistant decided to” does not survive a review.
The standard has moved. The first revision, November 2024, shipped with no authorization framework at all. OAuth 2.1 arrived in March 2025, and the June 2025 revision made the server a proper resource server.
Deployments have not.
Of 7,973 live remote MCP servers identified, 40.55 percent exposed tools with no authentication mechanism at all. Of 119 OAuth-enabled servers tested dynamically, every one carried at least one flaw, 325 in total, leading to nine CVE identifiers.
— A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, arXiv:2605.22333 · May 2026
Authentication is the tractable half. The other is prompt injection, where content a tool returns carries instructions the model then follows. The usual hope is a fix like the one that closed SQL injection: separate the instruction from the data.
SQL injection was solvable because query structure and user data are separable in principle. In a language model they are the same substance.
Two years in, every mitigation is probabilistic. We would drop that view the week somebody proves otherwise.
The practical consequence is narrow. Every tool an agent can reach is available to anyone who can write into that agent’s context. Tool count is blast radius.
The cheapest fix is often not AI
Wallkötter spent his doctorate on human-robot interaction and describes humanoid robots as “a bit like an unstable equilibrium.” Impressive in a demonstration, hard to justify once somebody asks what job it does. Take the legs off, put wheels on, and you get something cheaper and sturdier that nobody films.
The software version he ran into: a sophisticated coding system with an agent whose job was identifying unreliable tests. Run the test ten times. If it passes sometimes and fails sometimes, it is unreliable. That is what the word means.
The deterministic version is instant, free, right every time, and needs no security review. The agent version costs tokens, is occasionally wrong, and adds another line to a crowded menu.
Models earn their cost on judgment under ambiguity. They lose to a script wherever the answer has a definition you can write down.
Four questions separate the cases:
Ask them in this order
| Test | Question | Answer |
|---|---|---|
| The rule | Can a rule you can write down check the output? | Write the rule. |
| The repeat | Must the same input give the same answer every time? | Wrong instrument. |
| The blast | Would a wrong answer be costly and hard to notice? | Script, or a model with a human checkpoint on the action. |
| The judgment | Is the input unstructured language and the judgment genuinely fuzzy? | That is what the model is for. |
Most agent work we are asked to review fails the first question, and fails it untested, because the plain version was never built.
Narrow agents and a written tool budget
In our engagements, one agent with forty tools has consistently lost to four agents with six each. The component that picks which path a request takes can only choose well between options it can tell apart. Test that on your own traffic before committing to it.
The control that makes it stick is duller than the architecture. Every agent gets a written tool list, with an owner and a reason against each entry. Adding one means removing one or making the case.
This week Do this week: list the tools your agents can currently reach, put a name and a reason beside each, and count the ones nobody can defend. That takes an hour, and the number you cannot defend is usually the diagnosis.
The objection The objection is that load-on-demand already fixes this. It fixes one cost of three. A tool loaded only when needed still exists, still needs maintaining, and is still reachable.
The token bill was always the least interesting of the three.
Write down the dumb version first
Everything above assumes the agent should exist. The only honest moment to test that is now, while nobody has anything to defend yet.
Write three things down before the connection is made:
The floor A quality floor, with a date against it.
The ceiling A cost ceiling per run, once volume is real.
The baseline The deterministic baseline: the plainest non-AI version of the task, and how well it actually performs.
The third does most of the work. If nobody can describe the script version, the team does not understand the task well enough to automate it. If the script exists and the agent cannot beat it by a margin worth the operating cost and the added attack surface, the answer arrives in a day instead of a quarter.
This is the Bearing phase of our AZIMUTH method, set out on the Method page. Clients argue with it right up until the quarter it stops a project before the project stops itself.
The protocol removed a cost. It never removed the decision underneath it.
Last reviewed August 2026. Corrections are logged, not made silently. What would change our position: a prompt injection mitigation that holds under adversarial testing rather than on average.
