Half the registry never starts

Three papers on the tool surface you do not own: what the registry actually hands you, what you can tell about a server before you ever run it, and what kind of check catches a bad action once it is live.

Today's pick

48.8%

of 400 randomly drawn tool servers completed a handshake; 37.5% never started at all

What a Random Draw from the MCP Registry Contains, and What Tool-Use Benchmarks Contain Instead

Studies of the tool-server ecosystem sample from reference lists, popularity rankings or pipelines that repair a server until it boots, and all three quietly drop the servers that never work before anyone counts. Drawing 400 servers at random from a census of 24,135 and probing each exactly once — no credentials, no repair, no retry — 48.8% complete a handshake, against 66.7% for a hand-curated frame measured with the same instrument, and the dominant failure is not a missing key at 13.3% but servers that never start at all, at 37.5%. Of the 2,766 tools that do load, not one violates the required schema, while 58.8% carry none of the four optional annotations that tell an agent whether a tool writes before it calls it — and that omission is decided once per server, so 72 of 194 servers annotate every tool and 122 annotate none, with nothing in between. Budget a handshake check at the moment someone enables a server rather than at first use, and screen annotations per server instead of per tool.

open the explainer → abstract PDF code

94 of 95

tools later confirmed exploitable that were caught from registration metadata alone, against 80 for a single-prompt baseline

No-Box Vulnerability Analysis: Description-only Detection of Indirect Prompt Injection Vulnerabilities in MCP Servers

Before enabling a third-party tool server you would like to know whether it can carry an attacker's instructions into your model's context, but auditing normally needs the source, a running instance or both, and a hosted server gives you neither. This work reasons only over what a server publishes at registration — each tool's name, description and input schema — asking which data flows every possible implementation consistent with that description would have to contain, and then writing out the attack scenario that follows rather than an exploit. Across 20 widely deployed servers and 177 sampled tools it recovered 94 of the 95 tools a human team later confirmed exploitable, against 80 for a single-prompt baseline, at about $1.65 per server; the cost is precision, 65.7% against the baseline's 82.5%, and when the authors went back with the source in hand a quarter of its scenarios did not hold up. Use it to decide which servers are worth reading properly, not as a verdict on any one of them.

open the explainer → abstract PDF

62.9% vs 22.9%

unsafe actions approved by a second model reading the same evidence, against one reading an independent source

Engineering Reliable Commit Gates for Agentic AI: Cost-Aware Verification Portfolios under Common-Mode Data Failures

The usual answer to an agent about to write something is to have a second model check it first, which quietly assumes the two can fail independently. If the checker reads the same cached view the actor read, they cannot: across 849 unsafe proposals a cross-model vote over shared evidence approved 62.9% of them, while the same vote reading an independently replicated snapshot approved 22.9%, and the paired estimates put changing the evidence source at about 41 points against roughly 11 for changing the model. Run the same gates against a live service and a second gap opens: when a concurrent writer commits between the check and the action, every verify-then-act policy commits the same unsafe effects, and only re-checking the whole condition inside the write transaction reaches zero. Give your verifier its own read path rather than a different model, and put the final condition in the transaction instead of in a prompt.

open the explainer → abstract PDF