Ninety-seven million installs. That's where MCP stood at the end of March, and by any measure, the protocol has won. Every major IDE integrates it. Every AI lab ships an SDK that speaks it. But go ask a platform team how they onboard a new MCP server and you'll hear the same story: someone digs up a URL from a Notion doc, copies a JSON snippet into a config file, and prays the endpoint hasn't moved since last sprint.

MCP solved tool integration. It forgot about tool discovery.

The Ghost Server Problem

HTTP APIs learned this lesson twenty years ago. You publish an OpenAPI spec at a predictable path. Service meshes register endpoints automatically. Health checks run before traffic routes. Kubernetes has service discovery baked into its DNA.

MCP servers have none of this. They're invisible until someone manually configures a client to connect. You can't crawl them, can't query what they offer, can't even tell what auth they require without attempting a handshake. At 97 million installs, that's not a missing feature — it's an architectural gap that keeps the protocol stuck in the "works on my machine" tier of infrastructure maturity.

Server Cards Give MCP a Front Door

SEP-1649, now moving through the MCP review process, introduces Server Cards — a JSON document served at /.well-known/mcp/server-card.json. Hit that endpoint and you get everything you need before opening a connection:

{
  "protocolVersion": "2025-06-18",
  "serverInfo": {
    "name": "acme-data-server",
    "title": "Acme Data Server",
    "version": "1.2.0"
  },
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  "capabilities": {
    "tools": { "listChanged": true },
    "resources": { "subscribe": true }
  },
  "authentication": {
    "required": true,
    "schemes": ["oauth2"]
  },
  "tools": [
    {
      "name": "query_inventory",
      "description": "Query product inventory by SKU",
      "inputSchema": {
        "type": "object",
        "properties": {
          "sku": { "type": "string" }
        }
      }
    }
  ]
}

The design mirrors what OAuth did with .well-known/openid-configuration — a predictable location that turns "connect and find out" into "look before you connect." Clients can hydrate their UI, validate security posture, and build registries without ever establishing a protocol session.

One subtle but important decision in the spec: primitives can be declared as "dynamic" (discover them after connecting) or listed statically in the card. A server with three stable tools can enumerate them upfront. A server backed by a dynamic data catalog declares "dynamic" — and clients know to expect a heavier initialization sequence. This distinction matters for registry builders and security scanners that need to index thousands of servers without connecting to each one.

Meanwhile, at the IETF

In parallel, an Internet-Draft by Marco Serra (draft-serra-mcp-discovery-uri) proposes something more ambitious: a dedicated mcp:// URI scheme with DNS-backed discovery. Two modes:

Base mode fetches https://{domain}/.well-known/mcp-server directly — works anywhere, no DNS changes needed. Fast mode checks a _mcp.{host} DNS TXT record first, confirming the server exists in milliseconds before retrieving the full manifest. The fast path is built for crawlers scanning thousands of potential endpoints.

The draft also introduces trust classes — public, sandbox, enterprise, regulated — that signal authentication and compliance requirements before any bytes flow. Optional JWS signatures, verified against DNS-published keys (think DKIM for MCP), let clients validate server identity cryptographically.

This is the protocol reaching beyond IDEs and into addressable internet infrastructure. Whether the IETF community takes it seriously remains open — the draft explicitly notes it has no formal standing. But the ambition tells you where the pressure is coming from: organizations that need identity verification and compliance signaling baked into the discovery layer, not bolted on after the fact.

The Thin-Core Bet

Here's the architectural tension worth watching. The 2026 MCP roadmap explicitly states that enterprise readiness features — audit trails, SSO-integrated auth, gateway behavior — will land as extensions, not core spec changes. The reasoning: enterprise requirements shouldn't bloat the base protocol for a developer running a local tool server.

Defensible position. HTTP didn't bake OAuth into the spec. DNS didn't define service mesh behavior. Successful protocols stay thin and let the ecosystem build layers on top.

But it's also a gamble. If Server Cards ship as a loosely-adopted optional feature while every enterprise rolls their own discovery wrapper, MCP ends up with the worst outcome: a standard that everyone extends differently. We've seen this with SOAP. We've seen it with GraphQL federation. Half the W3C specs that got ignored in favor of vendor-specific implementations followed the same arc.

The governance bottleneck makes this riskier than it should be. Every SEP still requires full Core Maintainer review regardless of domain. The roadmap promises delegated authority to Working Groups, but the Enterprise Working Group doesn't exist yet. A protocol with 97 million installs running a single-threaded review pipeline for multi-threaded adoption is leaving decisions on the table.

What Comes Next

Discovery looks optional until it isn't. Right now, configuring MCP servers is something a single developer handles in their IDE settings. When organizations manage fifty servers across three environments with different auth requirements, discovery becomes load-bearing infrastructure — the kind where "just copy the config from Slack" stops being charming and starts being a production incident.

Server Cards are the minimum viable answer. The IETF draft is the maximum viable answer. Somewhere between the two, MCP either builds the discovery layer its install base demands or it remains a protocol that conquered developer laptops without ever reaching the data center.