Skip to content

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

Sep 2026 · 0 citations · 10 references
Computer Science

Abstract

Studies of the Model Context Protocol (MCP) server ecosystem draw their samples in ways that quietly select for servers that work: reference sets, popularity lists, hand-curated frames, or pipelines that repair a server until it starts. We report what an unrepaired probability sample actually contains. From a 24,135-server registry census we draw 400 npm/stdio servers with a published seed and probe each one over the wire. Only 48.8% complete an initialize handshake, against 66.7% for a hand-curated frame measured with the same instrument, and the dominant failure is not missing credentials (13.3%) but servers that never start at all (37.5%). Among the 195 that do run, hard conformance is total: zero fatal JSON Schema violations across 2,766 advertised tools. Optional safety annotations are the real variance, and the tool-level omission rate on a random draw is 58.8% against 41.5% on the curated frame, so curation flatters this figure too. We then compare the tool descriptions these servers advertise against two tool-use benchmark corpora using one method held constant. Real MCP tools show 2.8% near-duplication at cosine 0.70, and all of it lies within single servers: cross-author near-duplication is 0.0% at every threshold tested. BFCL v4 shows 16.7%, of which 16.4 points lie between independently presented tasks. UltraTool shows 0.3%, cleaner than real tools, so this is a property of BFCL and not of synthetic corpora as a class. Separately, 68.8% of raw BFCL rows and 85.6% of raw UltraTool rows are exact name-plus-description repeats, against 0.4% for real MCP, so any statistic computed over these releases without global deduplication measures repetition rather than tools. All figures regenerate from released scripts and a published seed.

View source

Similar papers

Review Aug 2026

Can MCP Clients Decide What to Do After Failure? A Result-Only Actionability Audit

What deterministic software can learn from a completed MCP failure result alone is studied; request arguments, schemas, discovery history, authen- tication state, transport metadata, host policy, and host policy, and host policy, and ap- plication state are outside that boundary.

Rishabh Mehan · 1 citation
Preprint Oct 2026

Understanding the Hierarchical Structure and Functional Landscape of the Model Context Protocol Ecosystem

AI agents increasingly rely on tools exposed through the Model Context Protocol (MCP) to complete user tasks. Hundreds of thousands of MCP servers are listed across marketplaces, yet they are organized only by coarse, marketplace-specific server categories. This makes it difficult for agents and users to identify tools...

Ting-Xuan Tang, Zi-Long Chen, Yue Xiao · 0 citations
Preprint Aug 2026

Outcome Monitors: Recovery Affordances for Silent Tool Failures

Outcome Monitors, which detect violations of outcome contracts mined from task-disjoint traces or derived from public schemas, are introduced, which detect violations of outcome contracts mined from task-disjoint traces or derived from public schemas.

Sugam Panthi, Rabab Abdelfattah · 2 citations
Book Open access Oct 2026

Technē: A Deterministic Craft Layer for Model Context Protocol Servers, Grounded in LLM-Authored X3D

When a language model builds 3D content by calling tools through the Model Context Protocol (MCP), the JSON Schema ensures each call is well-formed—but not that the result will render correctly. A texture placed in the wrong slot vanishes. A humanoid skeleton routed to the wrong parent field is invisible. The schema pa...

Alexander Hoffman · 0 citations

Related blog posts

Hugging Face Blog Oct 20, 2026

MPS in PyTorch 2.15

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.