Skip to main content
MCP Protocol Guide — April 2026

MCP Discoverability
How AI Agents Find Your API

The Model Context Protocol (MCP) is how AI agents connect to your tools. But connection requires discovery first. This guide covers how to make your MCP server findable by agents, IDEs, and orchestration platforms.

What is MCP?

The Model Context Protocol (MCP) is an open standard (created by Anthropic, now widely adopted) that defines how AI agents connect to external tools and data sources. Instead of building custom integrations for each AI platform, you build one MCP server and every compatible agent can use it.

MCP defines three primitives: Tools (functions the agent can call), Resources (data the agent can read), and Prompts (templates the agent can use). An MCP server exposes these via a standardized JSON-RPC transport — either over stdio (for local tools) or HTTP with Server-Sent Events (for remote APIs).

As of MCP v2.1, the protocol includes a server card specification for discovery. This is the piece most teams overlook — they build a working MCP server but never publish the metadata that lets agents find it.

The Discovery Problem

Building an MCP server solves the "how do agents interact with my API" problem. But it does not solve the "how do agents findmy API" problem. Without discovery, your MCP server only works when someone manually configures it in their IDE or agent platform.

Discovery is the difference between an API that requires a developer to read docs and manually set up, versus one that an agent can find, evaluate, and connect to autonomously. In the agentic web, discovery is distribution.

There are three layers of MCP discovery, each targeting a different audience:

Well-Known Endpoint

Publish a server card at /.well-known/mcp.json so agents crawling your domain can find your MCP server automatically.

Registry Listing

Register on MCP directories (npm, ClawHub, Smithery) so agents and developers searching for tools in your category can find you.

llms.txt Reference

Link to your MCP server from your llms.txt file so agents already reading your site context discover your tools.

The .well-known/mcp.json Format

The MCP server card is a JSON file that describes your server before an agent connects to it. It tells agents what tools are available, how to authenticate, and what transport to use.

{
  "name": "your-company-mcp",
  "version": "1.0.0",
  "description": "MCP server for Your Company API",
  "transport": {
    "type": "sse",
    "url": "https://api.example.com/mcp/sse"
  },
  "authentication": {
    "type": "bearer",
    "token_url": "https://example.com/oauth/token"
  },
  "tools": [
    {
      "name": "search_products",
      "description": "Search product catalog by query",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": { "type": "string" },
          "limit": { "type": "integer", "default": 10 }
        },
        "required": ["query"]
      }
    }
  ],
  "resources": [
    {
      "uri": "products://catalog",
      "name": "Product Catalog",
      "description": "Full product listing with prices"
    }
  ]
}

Critical fields: The transport object tells agents how to connect (stdio, SSE, or streamable HTTP). The tools array lets agents evaluate whether your server is useful before establishing a connection — saving time and tokens.

The authentication field is optional but important. If your MCP server requires auth, declaring it in the server card lets agents handle credentials proactively rather than failing on the first request.

How Agents Discover MCP Servers

When an agent needs a capability (e.g., "search for flights" or "create a Jira ticket"), it follows a discovery chain. First, it checks its pre-configured MCP servers. If none match, it searches registries. If the agent is browsing a specific website, it checks /.well-known/mcp.json to see if the site has tools available.

IDE-based agents (like Claude Code or Cursor) typically discover MCP servers through project configuration files (.mcp.json in the repo root). Autonomous web agents discover them through the well-known endpoint or llms.txt references. Platform agents discover them through registry search.

The pattern mirrors DNS: there is no single discovery mechanism, but a hierarchy of lookups that agents traverse until they find what they need. Publishing your server card at all three layers maximizes your reach.

MCP Hosting on AINative

Building an MCP server is the first step. Hosting it reliably with low latency, proper auth, and automatic scaling is the second. AINative offers managed MCP hosting that handles the infrastructure so you can focus on defining your tools.

Our hosted MCP servers run on the same infrastructure as ZeroDB — globally distributed, with SSE transport, bearer token auth, and automatic server card publishing at your custom domain. We also list your server on ClawHub, our MCP registry, so agents across the ecosystem can discover it.

Whether you build your own MCP server or use one of our 69+ pre-built tools via the ZeroDB MCP server, making your API agent-accessible starts with discoverability.

MCP and Your AX Score

MCP discoverability contributes to the API Surface dimension (15% of AX score) and Discoverability dimension (20% of AX score). Having a valid .well-known/mcp.json can add 5-8 points to your overall score. Combined with a working MCP server that agents can connect to, API Surface scores jump significantly.

Check Your MCP Discovery Score

The AX Audit checks for .well-known/mcp.json, validates your server card format, and tests whether agents can actually discover and connect to your MCP server.

Check Your MCP Discovery Score

Free audit. No signup required.