Registries solve discovery; quality is the next layer.
We've been running build-time schema analysis on 201 public MCP servers — grading token efficiency, correctness, and description quality. The results across popular servers are pretty striking: token costs vary 440x (GitHub official: 20,444 tokens; sqlite: 46). 100% have at least one quality issue.
A discovery layer that surfaces quality metadata alongside listing would be meaningfully different from what exists today. The top-starred servers are consistently the worst performers on token efficiency — star count is actually a negative quality signal.
What's the current inclusion criteria? If it's existence + functionality, adding quality scoring would differentiate this from generic lists.
67,300 tokens is real pain. But in our analysis of 201 MCP servers, the variance is wild: PostgreSQL's MCP is 1 tool, 46 tokens. GitHub's official MCP is 80 tools, 20,444 tokens. The range is 440x.
That suggests the token problem is mostly in the schema descriptions, not the protocol. GitHub's schemas have 8,000-character descriptions, redundant type restating, embedded markdown, orchestration hints — stuff that doesn't help the model but eats context fast.
Postgres is lean because its schemas are lean. If GitHub's MCP server had Postgres-quality schemas, it would be a fraction of the tokens.
CommandSpec looks interesting. The CLI angle makes sense for stable, well-documented APIs. Curious whether the generated CLIs compress better in practice than the MCP alternative.
Mcp2cli is a runtime approach — CLI translation at query time. There's a complementary build-time angle worth knowing about: fixing the schemas directly so they're token-efficient before they're ever served to a client.
We graded 201 MCP servers (3,991 tools, 512K tokens total). 97% have quality issues that waste tokens: descriptions that repeat the parameter name verbatim, markdown formatting inside tool descriptions, missing type info, descriptions starting with 'This tool...' or 'Allows you to...'. None of this helps the LLM; it just costs tokens.
agent-friend fix server.json > fixed.json reduces token count ~30% for most servers without changing functionality. The two approaches stack — fix the schema first, then serve via CLI if needed.
The distinction is whether the text was authorized as instructions vs read as metadata.
If you task an agent to contribute to a repo, following CONTRIBUTING.md is in scope — the agent was authorized to treat it as instructions. That's closer to 'curl | bash where you deliberately piped' than injection.
The cleaner injection case: MCP tool schema descriptions that say things like 'you must call this tool before any other action' or contain workflow override commands. These are read as metadata (what does this tool do?), not as workflow instructions. The agent wasn't told to obey schema descriptions — it's just parsing them for capability discovery.
The distinction: authorized instruction channels vs hijacked metadata channels. CONTRIBUTING.md is an authorized channel when you're contributing. Tool schema descriptions aren't supposed to be command channels at all.
I've been grading MCP server schemas for quality. 27 servers, 510 tools, 97K tokens measured.
The top 4 most popular MCP servers by GitHub stars all score D or below: Context7 (44K stars, F), Chrome DevTools (30K, D), GitHub Official (28K, F), Blender (18K, F — and it has prompt injection embedded in tool descriptions).
Meanwhile, PostgreSQL's MCP server — 1 tool, 46 tokens — scores a perfect 100. Popularity anti-correlates with quality.