Running Someone Else's Tool Server
Adding a tool server written by someone else takes about a minute. That is the entire value of a standard interface and it is also the reason we now have a checklist, because a component that is trivial to add is a component nobody reviews.
The Minute That Worries Us
A tool server for a common service can be added to a running system by putting a command and a package name in a configuration file. It is the same convenience that package managers brought, with the same consequence: the review step that used to be implied by the effort has disappeared.
We had two added to a development environment before anyone raised it. Neither was malicious and both were fine. The point is that nobody decided they were fine, because adding them did not feel like adding a dependency.
A Tool Description Is an Input
This is the part that is easy to miss. A tool server describes its tools in text, and that text goes into the model's context, where it is read as guidance about what to do. A description is therefore not only metadata, it is an instruction channel from whoever wrote the server into the model.
Hou and colleagues published a survey of the protocol's landscape and security considerations in early 2025, covering threats across the lifecycle of a server. The finding we act on most is the one about descriptions, because it is a channel that does not look like one.
| Check before it runs | What it rules out |
|---|---|
| Read the tool descriptions in full | Instructions hidden in metadata |
| Pin the version by digest | A server that changes under you |
| Run it with its own credentials | One tool reaching another's data |
| No network beyond its declared host | Exfiltration through a tool |
What We Check
We read every tool description as though it were user input, because in the relevant sense it is. We pin the version and mirror the package, exactly as we do for model artefacts. We give the server its own credentials with the narrowest scope its tools need, and we restrict its outbound network to the host it is supposed to talk to.
None of this is sophisticated and all of it is skipped by default, which is the argument for writing it down. A checklist that takes ten minutes is the difference between a reviewed component and one that arrived in a configuration file.
What We Refuse
Any server that wants credentials broader than its stated purpose, which is more common than it should be and usually not malicious: a server offering read access asks for a token that also writes because that was easier to document.
Any server we cannot run in our own infrastructure. A hosted tool endpoint means customer data leaves for a third party we have not contracted with, which is a data protection question long before it is a security one, and it is the check that has disqualified the most candidates.
The Ones We Write Ourselves
Most of them, still. A tool that queries a customer's order system is a few dozen lines against an API we already understand, and writing it is faster than evaluating a general-purpose server that does more than we want.
The exceptions are genuinely general things: a filesystem server for a sandbox, a search tool over public documentation. Those we take from upstream and treat with the checks above, and the split has held at roughly nine of our own to one taken in.
The Credential Point
If a tool server is compromised or simply wrong, what it can do is exactly what its credentials permit. That is the whole security story, and it means the review of a server matters much less than the scope of the token we hand it.
We had this the wrong way round initially. Considerable attention went into reading a server's source and almost none into what it could reach, which is precisely inverted: the source is a snapshot that changes with the next version, and the credential scope is the property that holds regardless.
What We Tell Customers
That every tool in their system is listed with what it can do and which credentials it holds, and that the list is short enough to read. If a system has forty tools, nobody has reviewed forty tools, and the honest answer is to reduce the number rather than to describe them all.
We also tell them that adding one is a deployment, not a configuration change. It goes through review like any other component, which slows down exactly the thing the standard made fast, and that friction is deliberate.
What We Do Not Claim
We do not claim our checks would catch a determined attack. They would catch an overreaching server, a version that changed underneath us and an instruction hidden in a description. A well-crafted supply chain attack against a widely used server is not something a ten-minute checklist addresses.
We also do not claim writing our own tools is safer in general. It is safer for us because we control the scope and the surface, and a team without the capacity to maintain a dozen small servers would reasonably choose differently.