MCP · July 3, 2026

Does Any AI Agent Actually Know Your MCP Server Exists?

73,799 MCP servers are listed across the major registries as of July 2026. But the spec that lets AI agents find them automatically is still being finalized. So who actually knows your server exists?

73,799 MCP servers are listed across the major registries as of July 2026. That number sounds impressive until you realize the spec that would let AI agents find those servers automatically is still being finalized. Right now, if a user doesn't already know your server URL, there's a decent chance no AI agent will ever discover it.

This post draws on registry counts from MCPToplist (July 3 2026), a published analysis of 1,400+ MCP servers from Bloomberry, rate limiting operations guidance from Peliqan, and the open GitHub issue tracking the /.well-known discovery proposal (SEP-1649). We also looked at Wrenda's internal mcp_discovery_count data across active customer domains.

How many MCP servers are actually out there?

Registry counts vary dramatically depending on who you ask — and how they count. MCPToplist puts the total at 73,799 across all major directories, but that figure includes substantial overlap, since many servers are listed on multiple registries simultaneously. The largest single directory is Glama with roughly 36,950 listings, followed by PulseMCP (15,930), the official registry (9,652), Smithery (7,300), and mcp.so (3,967).

MCP Servers Tracked by Registry, July 2026
Total across all registries: 73,799. Glama is the largest single directory; many servers appear across multiple registries.

What's interesting is how the ecosystem fractured. Instead of one canonical registry the way npm is the canonical registry for JavaScript packages, you have five-plus independent directories that crawl GitHub, accept community submissions, and occasionally crawl each other. For a developer publishing an MCP server today, getting listed means submitting to each one separately. And there's no guarantee that any specific AI assistant queries any specific registry when looking for relevant tools.

This fragmentation also makes the "73,799" number harder to interpret. Is it 73,799 distinct tools? Or 30,000 real servers with significant duplication across directories? Nobody tracks deduplication across registries in a consistent way.

Does an AI agent actually know your server exists?

This is the uncomfortable question, and the short answer right now is: probably not, unless a user explicitly pastes your server URL into their agent's configuration settings.

The mechanism that would change this is a draft specification called SEP-1649, which proposes that servers publish a JSON file at /.well-known/mcp/server-card.json. An AI assistant could then crawl this path on any website and automatically discover that a site has an MCP server, what tools it exposes, and how to connect. It's the MCP equivalent of robots.txt — a lightweight machine-readable signal that agents can use without human intervention.

As of early July 2026, that specification was still an open discussion thread on GitHub. No major AI assistant had shipped production support for automatic server card discovery. That means every active MCP connection today goes through a manual step: a human finds a server URL somewhere, copies it into their assistant's tool settings, and the agent calls it from there.

For site owners, this creates a real adoption ceiling. You can publish the most useful MCP server imaginable, get it listed in every registry, and still have near-zero agent traffic if your target users haven't heard of you.

What happens once an agent does find your server?

Tool call volumes have shifted significantly over the past two years. In late 2024, a typical AI agent conversation involved 2-3 tool calls. By mid-2026, that number is closer to 8-15, driven by agents tackling longer, multi-step tasks that chain tools together in sequences.

Average AI Agent Tool Calls per Conversation (2024 vs 2026)
Tool call volumes have grown roughly 4-5x as agents handle more complex multi-step tasks — making rate limiting the #1 production failure mode for MCP servers.

That growth is directionally positive — more calls per conversation means each registered tool gets exercised more. But it has also made rate limiting the most common production failure mode for MCP servers. If you sized your rate limits when typical usage was 2-3 calls per conversation, you're probably seeing 429s regularly now from agents making 10-plus calls per session, often in rapid succession.

Peliqan's operations guide found that 73% of MCP server outages happen at the transport layer — connection limits, 429 rate limit responses, and timeout configurations — rather than from application logic errors. The servers aren't fundamentally broken. They're calibrated for a traffic pattern that no longer exists.

What can you actually see about your MCP traffic?

Not much, in most cases. A conventional API would give you dashboards: endpoint breakdown, p95 response times, error rates by status code, caller breakdown by user-agent. Most MCP servers have none of that instrumentation.

A Bloomberry analysis of 1,400+ MCP servers found the majority had no published rate limit documentation, no error taxonomy in their tool schemas, and no guidance on retry behavior for callers. When an agent hits a 429 from an undocumented server, it has to guess whether to wait 1 second, 60 seconds, or give up entirely. The spec includes no standard for retry-after semantics in MCP responses, so each server's behavior is effectively a black box to the agents calling it.

What this means for site owners

If you're operating an MCP server today, the single most valuable thing you can do before optimizing anything else is add logging. Capture every tool call with the user-agent string, request latency, input payload size, and response status. You need a baseline to know whether changes to your rate limits or tool descriptions are actually improving things.

On rate limiting specifically: calibrate your limits to match how agents actually use tools, not how humans use APIs. Per-conversation budgets are more useful than per-minute counts. An agent making 12 calls in a 45-second window isn't a bot abuse pattern — that might be a user asking it to do something genuinely complex. Standard per-IP rate limits copied from REST API designs will fire constantly under normal agent load.

On discovery: the /.well-known/mcp/server-card.json specification isn't shipped yet, but publishing the file today costs almost nothing. When AI assistants do add support for automatic discovery, you'll already be there. Include your tool list, plain-language descriptions of what each tool does, and contact information for partners who want to negotiate higher rate limits.

Sources

  1. MCP Toplist — MCP server rankings
  2. MCP Rate Limits: A Practical Guide for Agent Builders
  3. I analyzed 1400 MCP servers — here's what I learned
  4. SEP-1649: MCP Server Cards - HTTP Server Discovery via .well-known