Your agent tells you it cannot do the thing.
You believe it, because what else would you do. The vendor is connected, the tool list came back, the model read it and said no.
What actually happened is that whoever built that connector picked a handful of operations out of several hundred, shipped those, and shipped nothing that tells you what they left out.
The number is 19%
Meriem Mastouri, Emna Ksontini, Amine Barrak and Wael Kessentini went through 116 official Model Context Protocol servers, the connectors that let an assistant call an outside service. They lined each one up against the web API sitting behind it.
Three findings, and the third is the one to carry around.
88.6% of these servers are wrappers around an existing web API. Not new capability. A translation layer over something the vendor already had.
92% of the tools are bare wrappers. One tool, one endpoint, pass the arguments through. No composition, no judgment about what a person is actually trying to get done.
The median server exposes 19% of the operations the underlying API offers. GitHub's web API defines more than 600 operations. Its connector exposes 51 tools. Slack has more than 200 methods behind about 8.
Read that last one twice, because it is not a performance problem. It is an editorial decision. Four out of five things the service can do are not on the menu, and the menu does not mention them.
The usual caveats apply and they matter. These are 116 servers listed in Anthropic's public catalog as of July 2025, kept only if the vendor publishes a documented web API and the repository had at least ten stars on GitHub, so this is the well-resourced end of the ecosystem rather than the average weekend project, and it is a snapshot of a thing that changes monthly. Listed in that catalog does not mean written by the vendor, either. Some of these are a company's own work on its own product, and some are a third party wrapping a public API without anyone's permission, and the study does not split them. The paper first went up in July 2025 and was revised through April 2026. But the direction is not subtle, and the well-resourced end being the well-behaved end should make you more worried about the rest, not less.
Why a missing 81% is invisible
A web API has documentation. You can read the list, find the endpoint you need, and if it is not there you know within a minute.
A connector hands the model a list of tools and the model works with the list. Nothing in the protocol says "here is what this server chose not to expose." There is no diff against the underlying service. The absence has no shape.
So the failure mode is not an error. It is a confident, polite, completely reasonable sentence telling you the system cannot do something it can, in fact, do, through a door that was not included in the build. And you have no cheap way to tell that sentence apart from a true one.
This is the same structure as any other silent omission in software, with one difference that makes it worse: the thing reporting the limitation is fluent. A 404 looks like a 404. A model saying "that is not available through this integration" looks like an answer.
The wrapper is a second, quieter problem
One tool per endpoint sounds neutral. It is not.
It means the tools are named after the vendor's internal structure rather than after anything a person wants. It means getting one real task done requires the model to chain four or five calls in the right order, and requires you to know the vendor's vocabulary well enough to ask for the first one.
We know this one from the inside. Mallin ships a connector. Every tool in it works, each one is guarded properly, and the first time it got used on a real workflow the verdict was that it felt complicated and unintuitive. That was correct. We had shipped parts. The person using it was doing the integration by hand, in their head, one instruction at a time.
The study puts a number next to the instinct: filtering and regrouping the generated tools cuts the median tool count per API by about a third without cutting capability. Fewer, better-shaped tools. The pile was never the point.
What a connector should expose is not endpoints. It is jobs. One instruction that means something to the person saying it, which resolves into whatever sequence of calls that takes. If using the thing correctly requires remembering product vocabulary, an ordering, or a defensive phrase, that is a defect in the tool and not a gap in the customer's training.
The generation result cuts both ways
The same team built a pipeline that generates these servers automatically from a specification. It worked for 76% of tools straight away, and 94.2% after automatically repairing the specification first.
The optimistic reading is that wrapping is nearly solved and will be commodity within a year.
The pessimistic reading is the same sentence. If a connector is something you generate from a specification in an afternoon, then the connector is not the product and was never going to be. What survives is the part a generator cannot produce: which operations belong in front of a person, in what grouping, with what naming, and what the thing says when it reaches the edge of what it knows.
Note also what broke in the 24% that failed. Missing security schemes, malformed base URLs, undocumented headers, parameter type mismatches. Ordinary documentation rot. The bottleneck on machines using your software turns out to be whether your specification was ever true.
Two questions worth asking
If you are buying software that advertises an integration, ask which operations it exposes and which it does not. Not "does it connect to Salesforce." Which percent, and who chose, and whether the vendor wrote the connector at all or somebody else did. A vendor that cannot answer has not thought about it, which tells you the answer is closer to 19% than to 100%.
If you are building one, the study is a map of where everyone else is standing. Wrapping the API surface one endpoint at a time is the default, it is what 92% of the field did, and it produces something that technically works and does not get adopted. The open ground is the shape of the tools, not the count of them.
The protocol settled how machines talk to each other. It settled nothing about what they should be allowed to say.