The Model Context Protocol (MCP) is an open standard, released by Anthropic in November 2024, for connecting AI applications to tools and data sources. For public websites, it means you can expose your site's functionality as typed tools and resources that AI clients can invoke or read through an explicit protocol.

What MCP adds beyond crawling

When an AI agent crawls your site, it reads HTML and infers what your product does. When it connects to an MCP server, it can list available tools, resources, and prompts through JSON-RPC methods and then call supported tools with typed arguments. The agent should still have docs for product semantics, but it no longer has to infer the callable surface from prose alone.

The protocol uses a client-server model. An AI application acts as the host, creates MCP clients, and connects those clients to MCP servers. Your MCP server exposes tools, resources, and prompts. A tool is a callable function (search_docs(query: string)); a resource is a read-only context endpoint that returns structured content rather than raw HTML.

Tools vs. resources

The distinction matters for how you decide what to expose:

  • Tools suit interactive, stateful operations — search, form submission, transaction initiation, any action with side effects. They have typed inputs and outputs.

  • Resources suit read-only content access — pulling a product page, fetching API reference content, retrieving a changelog entry. They let agents get structured page content without rendering HTML.

For developer tool and API product sites, a search_docs tool is usually the highest-value starting point. For content-heavy sites, a resource endpoint for each major content section often provides more value than a tool.

Discovery: how agents find your MCP server

MCP discovery is still evolving. The official ecosystem includes an MCP Registry, and many sites also document remote MCP endpoints in developer docs, API catalogs, or agent-readable files. Treat .well-known MCP cards as an additional discovery signal only if your client ecosystem expects them; do not assume every MCP client will look there.

The most portable approach today is to document the MCP server endpoint in your /llms.txt file under a dedicated ## MCP section:

# example.com

> Example: the tool that does X.

## Tools
- [API Reference](https://example.com/docs/api)

## MCP
- [MCP Server](https://mcp.example.com) — typed tool access for AI agents

This works for agents or coding tools that already read llms.txt as part of their discovery flow, without waiting for a registry to index your domain.

Practical steps for a public site

Standing up an MCP server doesn't require touching your existing site architecture. The work breaks into four steps:

  1. Identify which of your site's tools or data an agent would want programmatic access to — search, content retrieval, and account-level read operations are the common starting points.

  2. Build an MCP server that exposes those surfaces as typed tools and resources. The MCP SDK (available for TypeScript and Python) handles the protocol wire format; you implement the handler functions.

  3. Document the MCP endpoint URL in your /llms.txt under ## MCP and in the human documentation that already explains your API.

  4. Register the server with an MCP registry if one covers your domain and distribution model — this broadens discoverability to clients that use registry lookup rather than direct documentation scanning.

Current adoption

MCP support ships in Claude products, IDEs, coding agents, and a growing set of developer tools. Public indexing is still early, so the practical move is to expose a correct server, document the endpoint, and register it where your target clients actually look.

Verify before shipping

isitready.dev checks for MCP discoverability signals including llms.txt tool references and well-known MCP metadata where present. Run the scan on your canonical origin to see where your site stands and what agents can discover today.