How AI Clients Find and Connect to MCP Servers

MCP (Model Context Protocol) is how AI clients like Claude Desktop and Cursor get access to external tools. You configure a server, the client connects, and the model can call its tools during a conversation. But how does the client actually know what tools are available? And beyond manual config, how do autonomous agents find MCP servers they've never been told about?

There are a few different answers depending on the context.


Manual Config: How Most People Start

The most common path is explicit configuration. You add a server to a JSON config file, the client connects at startup, and downloads the tool list via the MCP protocol:

Client → POST /mcp/   {"method": "tools/list"}
Server → {"tools": [{"name": "check_email", ...}, {"name": "check_emails_batch", ...}]}

For a remote server (hosted at a URL), the config looks like:

{
  "mcpServers": {
    "emailyze": {
      "url": "https://api.emailyze.xyz/mcp/",
      "headers": { "x-api-key": "YOUR_KEY" }
    }
  }
}

Claude Desktop and Cursor both support this pattern. The client caches the tool list and makes tools available to the model. When you ask a question, the model decides whether to call a tool — it doesn't need you to explicitly ask it to use the MCP server.

This works well for personal tooling. But it requires someone to already know the server exists and manually add it. For autonomous agents that discover and use tools at runtime, that's a problem.


`llms.txt`: Plain-Text Discovery for Agents

llms.txt is an emerging convention (proposed at llmstxt.org) where a server exposes a plain-text file at /llms.txt describing what it does, how to use it, and how to connect.

Emailyze publishes one at https://api.emailyze.xyz/llms.txt. It includes:

Some agent frameworks and AI crawlers fetch llms.txt when they encounter a new domain. An agent building a tool suite for email validation might discover the Emailyze MCP endpoint this way without any manual configuration.

The file is intentionally human-readable too — useful when you want to quickly understand what an API offers without reading through structured documentation.


OpenAPI: Machine-Readable Tool Discovery

OpenAPI 3.1 is the standard machine-readable format for HTTP APIs. Emailyze publishes an OpenAPI spec at https://api.emailyze.xyz/v1/openapi.json.

Agent frameworks that support OpenAPI — LangChain, CrewAI, AutoGen, OpenAgents — can read this spec and automatically generate tool wrappers. Each operation in the spec becomes a callable tool with typed parameters and documented return values.

The Emailyze OpenAPI spec includes a custom x-payment-info extension:

{
  "x-payment-info": {
    "protocol": "x402",
    "price": "$0.001",
    "asset": "USDC",
    "endpoint": "https://api.emailyze.xyz/v1/x402/check/",
    "networks": [
      {"id": "eip155:84532", "name": "Base Sepolia", "status": "live"},
      {"id": "eip155:8453",  "name": "Base",         "status": "coming-soon"}
    ]
  }
}

This tells a capable agent not just how to call the API, but how to pay for it — useful for agents that operate autonomously without pre-provisioned API keys.


`/.well-known/x402.json`: Payment-Gated Endpoint Discovery

x402 is a protocol for pay-per-request API access. An agent sends a request, receives a 402 with payment requirements, signs a USDC micropayment, and resends to get the result. No API key, no account — just a wallet.

The /.well-known/x402.json manifest at https://api.emailyze.xyz/.well-known/x402.json lists every x402-protected endpoint:

{
  "name": "Emailyze",
  "x402": {
    "enabled": true,
    "resources": [{
      "url": "https://api.emailyze.xyz/v1/x402/check/",
      "method": "GET",
      "paymentOptions": [
        {"network": "eip155:84532", "price": "$0.001", "status": "live"},
        {"network": "eip155:8453",  "price": "$0.001", "status": "coming-soon"}
      ]
    }]
  }
}

Agent frameworks that implement x402 (like the official x402 Python and TypeScript SDKs) can index this manifest and discover the email check endpoint automatically. The agent knows what it costs, which network to pay on, and where to send the payment — all from a single well-known URL.


How These Three Layers Work Together

For a human developer setting up Claude Desktop or Cursor, manual config is fastest: add the URL, add the key, restart. Two minutes.

For an autonomous agent that needs email validation and doesn't have a pre-configured tool:

1. It might fetch /llms.txt to understand what Emailyze does 2. It loads the OpenAPI spec to get typed tool definitions 3. If it has a wallet but no API key, it uses the x402 endpoint from /.well-known/x402.json

In practice, most current agent frameworks rely on manual tool registration. But the discovery infrastructure is in place so that as frameworks evolve toward more autonomous tool acquisition, Emailyze is discoverable without any additional configuration.


Setting Up in Claude Desktop or Cursor

If you want email verification available as a native tool right now:

{
  "mcpServers": {
    "emailyze": {
      "url": "https://api.emailyze.xyz/mcp/",
      "headers": { "x-api-key": "YOUR_EMAILYZE_API_KEY" }
    }
  }
}

Add this to ~/Library/Application Support/Claude/claude_desktop_config.json (Claude Desktop) or ~/.cursor/mcp.json (Cursor). Restart. Done.

Full setup guide: [MCP Setup Guide](/blog/mcp-guide)

Get an API key: [emailyze.xyz](https://emailyze.xyz)