One Way to Plug In a Tool
The fourth time we implemented an adapter so a model could query an order system, it took two days and looked exactly like the previous three. That is not a hard problem, it is an absence of a convention, and the difference matters when deciding what to fix.
The Same Two Days, Four Times
Each project needed the same thing: describe a handful of operations to a model, accept its calls, validate the arguments, execute them and return results in a form it can use. Each time we wrote it against whatever framework that project used, and each implementation was mildly different in ways nobody had chosen.
None of this was difficult work. It was undifferentiated work, and undifferentiated work that gets rewritten is where inconsistency accumulates: four slightly different error formats, four notions of what a timeout means, four places to fix a bug.
What a Convention Buys
The Model Context Protocol gives tools a described surface that a model client can discover and call without a bespoke adapter. Szeider published MCP-Solver around the turn of that year, exposing a constraint programming system through the protocol so a model can use a solver as a tool.
That example is the one that convinced us, because it is not a wrapper around an API. It is a deterministic engine exposed as a capability, which is exactly the shape we care about: the model decides what to ask, and something that is not a model computes the answer.
What We Standardised
The transport, the description of each tool, the error shape and the way results come back. Those are the parts where variation bought us nothing, and unifying them turned a two-day adapter into an afternoon of describing operations we already had.
We also standardised what a tool must declare: whether it reads or writes, whether it is idempotent, and what scope its credentials carry. Those three facts drive our approval rules, and having them in the tool description rather than in a comment is most of why the rules can be enforced rather than remembered.
| Standardised | Left to the project |
|---|---|
| Transport and tool description | Which tools exist at all |
| Error shape and result format | What each tool is allowed to do |
| Read or write, and idempotency | Approval policy for writes |
| Credential scope declaration | The credentials themselves |
The Work That Remained
Deciding what a tool should expose, which is the part that was always the real work and had been crowded out by plumbing. A tool that offers search orders by any field is easy to build and hard to constrain; one that offers find order by number and list orders for this customer is narrower and answers the question of what the model can reach.
We now design tools the way we design an API for an untrusted client, because that is what a model is. Fewer operations, narrower parameters, and no operation whose blast radius depends on the caller getting an argument right.
The Security Property
A shared interface makes it possible to state one rule in one place: this client may call these tools with this credential scope. That is a genuine improvement over four adapters each making their own arrangements, and it is also the thing most likely to be got wrong, because a convenient default is to give a server the union of what any of its tools need.
So our servers are split by scope rather than by subject. The read-only order tools and the write tools are separate servers with separate credentials, which is more processes to run and removes the case where a read-only assistant is one configuration mistake away from being able to write.
What We Did Not Adopt
Dynamic discovery in production. The protocol allows a client to discover what tools a server offers at runtime, which is useful in development and is not how we ship: the tool list for a deployed system is fixed in configuration and reviewed, because a system whose capabilities can change without a deployment cannot be reasoned about.
We also did not route everything through it. Steps that call one fixed API with fixed arguments do not need a tool interface at all, and adding one makes a direct call into an indirect one for no benefit.
What It Actually Saved
The fifth integration took about half a day. That is the visible saving and it is not the important one; the important one is that a bug in argument validation is now fixed once, and that a new engineer reads one description of how tools work rather than four.
Against that, we took on a dependency on a specification we do not control, and one that was moving quickly at the time. We pin versions and we have had to adjust twice, which is a cost we were willing to pay and would state plainly to anyone considering the same move.
What We Do Not Claim
We do not claim a standard interface makes a system safer. It makes a policy expressible in one place, and an expressible policy that nobody sets is exactly as permissive as four ad hoc ones. The safety came from splitting servers by scope, which the protocol permits rather than provides.
We also do not claim this is settled. The ecosystem around it was young when we adopted it, and a convention is only worth having while enough other people follow it, which is a bet rather than a technical judgement.