The numbers are staggering. By April 2026, the Model Context Protocol records 97 million monthly SDK downloads, over 10,000 published servers, and native support across Claude, ChatGPT, Gemini, and Microsoft Copilot. Gartner forecasts that 75% of API gateway vendors will include MCP support by end of year.
But here's the problem nobody is talking about: discovery is broken.
You can build the best MCP server in the world, but if agents can't find it — and if the clients that discover it can't understand what it does, how much it costs, or whether to trust it — it doesn't exist.
The Discovery Gap in the Agent Economy
Compare the current state of MCP discovery to how the web handles service discovery. When you visit a website, you can inspect its robots.txt, sitemap.xml, and increasingly llms.txt to understand its structure and permissions. These standards emerged because the web needed to be readable by automated systems — crawlers, bots, and eventually AI agents.
MCP is in the same moment right now. Registries like Smithery, PulseMCP, and Glamas are aggregating server metadata, but they rely on manual submissions, inconsistent descriptions, and no standardized format for pricing, trust, or invocation details. Every registry has different schemas. Every client has different ways of presenting tools to users.
This fragmentation is familiar. It's the same fragmentation that killed Web Services in the 2000s and the same pattern that made API discovery a persistent pain point for developers for decades. The difference is that in 2026, the consumers are AI agents — they don't tolerate ambiguity the way humans do.
What the MCP Server Card Standard Gets Right
The emerging MCP Server Card standard (.well-known/mcp.json), being developed through collaboration between Anthropic, GitHub, and major registry operators, finally addresses this gap.
A Server Card is a structured metadata document served at a standardized URL. It tells any client — Claude Desktop, Cursor, n8n, or a custom agent framework — everything it needs to know about an MCP server before invoking it:
- What tools are available with full input schemas
- How to authenticate (or whether auth is required)
- What the server costs per tool invocation
- Who operates it and what trust signals exist
- What protocol version is supported
This isn't just documentation. It's machine-readable identity.
{
"schema_version": "1.0",
"name": "bluepages",
"display_name": "BluePages — AI Agent Skills Directory",
"server": {
"url": "https://bluepages.ai/api/v1/mcp",
"transport": "http",
"auth": { "type": "none" }
},
"capabilities": { "tools": true },
"stats": {
"total_tools": 54,
"free_tools": 31,
"categories": ["ai", "data", "development", "nlp", "security"]
}
}
BluePages now serves its own Server Card at /.well-known/mcp.json, listing all 54+ published skills as MCP tools with pricing and category metadata — queryable by any compliant agent client.
The Three Layers of Agent Discovery
Good discovery requires three layers, and most platforms only have one.
Layer 1: Static Metadata — The .well-known/mcp.json Server Card. Machine-readable, cached, always available. Tells clients the shape of the server before they ever make a call.
Layer 2: Dynamic Search — Runtime queries against a registry or index. "Find me a skill that does sentiment analysis on text" should return ranked results with trust scores and pricing. BluePages' /api/v1/agents and /browse handle this layer for both humans and agents.
Layer 3: Semantic Matching — The hardest layer. An agent working on a task should be able to describe what it needs in natural language and get back a ranked list of capabilities that fit, even if the terminology doesn't match exactly. This is where fuzzy search, tag matching, and eventually embedding-based retrieval come in.
The registries that will dominate the next two years are the ones building all three layers, not just one.
Why x402 Payments Change the Discovery Equation
Here's a subtlety that most commentary misses: discovery and payment are not separate problems.
When an agent discovers a skill through a registry, the first question after "can it do the task?" is "what does it cost?" In traditional API marketplaces, this answer is buried in documentation, negotiated in a contract, or hidden behind a signup flow. None of those are acceptable for autonomous agent workflows running at high frequency.
x402 makes pricing a first-class part of the discovery metadata. The Server Card includes price_per_call per tool. The invocation response includes the exact payment amount and recipient. The agent can evaluate cost-effectiveness before committing.
This shifts the competitive dynamic. Agents won't just search for "capability X" — they'll search for "capability X under $0.01/call with trust tier A or above." The registries that support this kind of filtered, pricing-aware discovery will capture the programmatic consumers. The ones that don't will remain human-facing portals.
The Stickiness Equation for Registries
Let's talk about what actually makes developers keep coming back to a registry.
We've been tracking engagement patterns on BluePages since launch. The data tells a clear story: the first successful invocation is the hook. Developers who successfully invoke a skill within 24 hours of discovery have 4x higher 30-day retention than those who don't.
What gets in the way of that first invocation?
- Integration friction — copying endpoint URLs, figuring out auth, building request bodies manually
- Trust uncertainty — "is this skill reliable enough to depend on in my workflow?"
- Protocol mismatch — "does this work with my framework / language / client?"
The new "Claude Config" tab on every BluePages skill detail page directly attacks friction #1 and #3. It generates a ready-to-paste claude_desktop_config.json snippet that connects any skill to Claude Desktop or Claude Code in seconds:
{
"mcpServers": {
"bluepages": {
"command": "npx",
"args": ["-y", "@bluepages/mcp-server"],
"env": {
"BLUEPAGES_FILTER_TOOLS": "sentiment_analyzer"
}
}
}
}
One copy-paste. That's the goal.
What Comes After Server Cards
The current MCP Server Card standard solves static discovery. The next frontier is live registry federation.
Imagine a world where Claude Desktop's server card resolver doesn't just check bluepages.ai/.well-known/mcp.json — it checks a federated metaregistry (like Glamas) and surfaces the best tool for a given task from across the entire ecosystem, with trust scores and pricing inline.
This is the Yellow Pages model, fully realized for the agent economy. Not a directory you look up once, but a live, ranked, trusted index that agents consult on every task.
BluePages is positioning for this future with:
- Server Cards at
/.well-known/mcp.json(live today) - Collections API at
/api/v1/marketplace/collectionsfor thematic bundles - Publisher Leaderboard at
/api/v1/publishersfor social proof - A2A Agent Card at
/.well-known/agent.jsonfor agent-to-agent discovery
The registries that own the discovery layer own the agent economy. The standard is being set right now.
BluePages serves the MCP Server Card at /.well-known/mcp.json. All 54+ skills are available as MCP tools — browse the directory at /browse or invoke directly via /api/v1/mcp.