MCP Made AI Tools Connectable, It Did Not Make Them Understandable

A universal socket is useful, but an agent still needs a legible contract for what each tool does, when it is safe to call, and how to prove the effect. Caption: A standard connector can make every machine reachable without explaining what the same-looking control will do.Picture two tools on a model's menu. One is called lookup. The other is called send. Both are valid under the protocol, and both connect cleanly. Neither one tells the model whether lookup can quietly pull a customer's full email history, or whether send drafts a message for review versus firing it to an external inbox the instant it is called. The connection succeeded, but the decision surface failed. MCP gives that surface a standard shape, but it does not make the decision legible by itself. What follows is an engineering audit of the surface, taken one layer at a time: the name, the schema, the declared side effects, the host gate, and the proof that anything actually happened. What the connection buys, and where the audit begins Give the protocol its due. When Anthropic introduced MCP in late 2024, the stated purpose was to replace one-off, custom connectors with a single open standard for wiring AI systems to tools and data. That was a real problem, and MCP is a real answer to it. Instead of rebuilding integration plumbing for every model and every data source, you get a common boundary. The current tools specification makes that boundary concrete. Tools are model-controlled, and each one is represented with metadata: a name, a description, an input schema, an optional output schema, and optional behavior annotations. Discovery, invocation, and the shape of the exchange are standardized. That is genuine leverage. But notice what standardization does and does not buy you. With a conforming application, a tool can be discovered and called through a standard interface. It does not guarantee that the tool can be understood, chosen correctly, or safely invoked. Transport compatibility is not semantic clarity, and it is not host policy. The same specification is careful about this line. It recommends that a human remain able to deny tool invocations, and it warns that behavior annotations must be treated as untrusted unless they come from a server you already trust. In other words, the protocol itself tells you that its metadata is a starting point, not a safety guarantee. That gap is exactly what an audit has to cover. An MCP plug feeds one continuous path through tool-contract interpretation, a host-policy gate, and three verified outcomes: changed, no-op, or unknown. Only the connector sits above the system-ownership boundary. Caption: An MCP socket carries the request. Tool meaning, host permission, and proof of effect are designed downstream. Layer one: the name An intent-revealing name lets the model separate this tool from its nearest look-alike before it reads anything else. lookup tells the model nothing about scope, side effects, or blast radius. It is a verb that could match half the requests it sees. The audit question here is blunt: could another tool plausibly match the same request? When two tools share a generic verb, the model has to guess, and it guesses with whatever weak signal is left. A name is the first disambiguation signal you can ship, and the first place a vague surface leaks. Layer two: the schema A constrained input schema can make invalid or underspecified calls harder to express, reducing the room for a dangerous or ambiguous argument. A permissive schema does the opposite. If a free-form string can stand in for a recipient, a filter, a query, and a command all at once, the model is free to produce a call the tool was never meant to receive. The audit question: can the schema represent an underspecified or dangerous call too easily? Tighten the inputs until the wrong call is hard to express. A schema is not just validation. It is a way to fence off the calls you never want the model to reach for in the first place. Layer three: declared side effects and preconditions Explicit side effects and preconditions say what changes the moment the tool runs and what must be true first. This is the layer where a read and a write get conflated. A read-only customer search that promises no writes and returns structured records is a fundamentally different object from a tool that immediately transmits an external email. Under a vague surface, both can hide behind the same generic verb. Under a real contract, the model can tell them apart before it commits to an action. A bounded description carries much of this weight. It states what the tool does and, critically, what it does not do. When side effects and preconditions live in a README or in tribal knowledge instead of in the contract the model reads, the model cannot use them. The audit question: does the model know what changes immediately? Layer four: the host gate Names, schemas, and descriptions shape the model's choice. They do not govern what happens when a choice becomes an action. That is host policy, and it lives outside the model entirely. The audit question here is the one that survives a wrong guess: what does the host enforce even if the model makes the wrong choice? Authorization, approval, and traceability are not things better wording can supply. They are gates the host either enforces or does not. A tool contract that reads perfectly still needs a host that can say no before the call lands. Layer five: proof of effect A structured output gives the caller evidence of what actually happened, rather than a friendly sentence that sounds like success. And failure semantics tell the model how to recognize and recover when the call does not go as planned. Between them, these two close the loop: the model made a choice, the host let it through, and now something either changed, did not change, or ended in an unknown state. The audit question: can the result prove the effect in structured data? A confident sentence is not evidence that an action occurred. If the only signal you get back is prose, you have no reliable way to distinguish a completed write from a hallucinated one. I wanted to see how much the wording of a tool surface changes a model's first move, so I ran a small local fixture for this article. I want to be precise about how small it is, because it is directional evidence and nothing more. I wrote ten synthetic CRM and email requests. I showed each request to the same model, GPT-5.6 Sol, under two conditions. The vague condition used generic names, one-line descriptions, and permissive schemas. The contract-rich condition bundled intent-revealing names, side-effect and precondition descriptions, and constrained schemas. Each condition received six observations per case across two independent runs. No tool was ever actually executed. I used an OpenAI-compatible function-calling adapter rather than a live MCP server, so there was no backend, no authorization layer, no latency, and no recovery path in the loop. Comparison graphic. The vague tool surface produced 49 expected first actions out of 60, while the contract-rich surface produced 60 out of 60. For explicit email sending the scores were 1 of 6 versus 6 of 6; for an unsupported email audit they were 0 of 6 versus 6 of 6. The fixture used one model and no tool was executed. Caption: In two runs of ten synthetic prompts, the vague surface produced 49 expected first actions out of 60; the contract-rich surface produced 60 out of 60. One model was tested, the treatment changed several interface dimensions together, and no tool ran. The vague surface produced the expected first action in 49 of 60 observations, or 81.7 percent. The contract-rich surface produced it in 60 of 60, or 100 percent. Two categories of prompt drove the gap. On the six prompts that asked for an action the tools did not actually support, an email audit, the vague surface failed all six by reaching for a generic lookup instead of declining or clarifying. On the six prompts that explicitly asked to send an email, the vague surface handled only one as expected. Better metadata closed both gaps in this fixture. Notice that both failure modes map straight back to the audit layers: an ambiguous name and a permissive schema let the model pick a lookup for a request the surface could not honor. I will not oversell it. This is one model, ten hand-authored prompts, and provider-default temperature. The treatment bundled names, descriptions, and schemas together, so it cannot isolate which of the three did the work. It is a fixture rather than a benchmark, and it shows a direction rather than a coefficient. Why the audit matters beyond one fixture Two recent preprints show why the boundary matters beyond my toy setup. DynamicMCPBench, a preprint submitted in July 2026, evaluates 24 models across 121 servers and 750 tasks in 15 categories, using effect-scored traces and a strict pass^3 rule that requires three successes. The strongest agents solved only about half of the tasks. Thirty-one percent were solved by no model at all. Accuracy fell from 39 percent on the shortest tool chains to 13 percent on the longest. Connectivity, in other words, is not completion. In this benchmark, longer tool chains were less reliable. The authors also make a point worth stealing, and it lands squarely on the proof-of-effect layer: an effect-scored trace tells you more about whether a real action occurred than a polished final answer does. The second preprint, an empirical study of 1,723 GitHub MCP applications submitted the same month, looks at how these systems are built rather than how they score. It reports that 90.8 percent log at least part of execution and 77.2 percent expose enable and disable controls, but only 37.2 percent implement a blocking approval gate before a tool executes. Treat that as a GitHub sample analyzed with an LLM-assisted classification pipeline, not a census of production deployments. Still, it says the host-side controls that actually govern safety are heterogeneous. The protocol permits a human veto. Most inspected projects did not enforce one before execution, which is the host-gate layer coming up short in the inspected GitHub sample. Put the two together. The tool interface gives the model its decision surface, and host policy governs what happens when a choice becomes an action. Neither comes for free with a working connection. The five-question audit, in one place Every layer above collapses into one short checklist. Run it against any tool surface before you ship it. Could another tool plausibly match the same request? If yes, your names and descriptions are doing too little. Can the schema represent an underspecified or dangerous call too easily? Tighten the inputs until the wrong call is hard to express. Does the model know what changes immediately? Side effects and preconditions belong in the contract, not in tribal knowledge. Can the result prove the effect in structured data? A confident sentence is not evidence that an action occurred. What does the host enforce even if the model makes the wrong choice? Authorization, approval, and traceability live outside the model, and better wording cannot substitute for them. The plug fits. Now the engineering starts. MCP made the plug fit, and that was worth doing. But a socket only moves the hard part downstream. The real work begins when you decide what may flow through it, how a model can tell one tool from another, and how your host proves that an action happened the way it was supposed to. Here is my question for you: what is the most dangerously ambiguous tool contract you have shipped or inherited, and what finally made you tighten it?