MCP and tool discovery The Model Context Protocol (MCP), an open standard proposed by Anthropic in late 2024, enables websites to expose queryable tools directly to AI agents via JSON-RPC, replacing UI scraping with structured, typed calls. For structured content sites like documentation sets, knowledge bases, and specifications, an MCP server lets agents retrieve filtered data — such as "list all required SEO topics" — in a single call instead of crawling and parsing HTML. The protocol is gaining adoption across platforms including Claude and ChatGPT, with discoverability through server cards at `/.well-known/mcp/server-card.json` and HTTP Link headers, though it remains overkill for simple static sites. MCP and tool discovery The Model Context Protocol is an emerging way for sites to expose queryable tools to agents over JSON-RPC. Relevant whenever your content has structure worth filtering — even for a static reference site like this one. What it is The Model Context Protocol MCP is an open protocol, originally proposed by Anthropic in late 2024, that defines how language-model clients talk to external tools and data sources. Instead of an agent scraping your UI, you expose an MCP server that declares a set of tools, resources, and prompts; the agent calls them directly. MCP is built on JSON-RPC over a few transports — stdio for local servers, HTTP plus Server-Sent Events for remote ones. A tool definition includes a name, a description, and a JSON Schema for inputs. This is relevant when your site exposes actions a user might want an agent to take: search a catalogue, create a ticket, book an appointment, query an account. For static content sites and blogs, MCP often adds little — well-cached HTML and a feed are enough. The exception is structured content sites where the data is filterable: a documentation set, a spec, a knowledge base. There an MCP server lets an agent ask “list all required SEO topics” or “give me the canonical CSP page” in a single typed call, instead of crawling and parsing. This site ships such a server as a worked example. See mcp.specification.website https://mcp.specification.website/ for the live endpoint, /.well-known/mcp/server-card.json /.well-known/mcp/server-card.json for the discovery document, and the for a ~300-line Cloudflare Worker implementation. Every tool it exposes is annotated https://github.com/jdevalk/specification.website/tree/main/mcp mcp/ directory of the source repo readOnlyHint and declares an outputSchema , so clients get typed results alongside the human-readable text. Why it matters - Agents call your functionality through a defined contract instead of guessing from a UI. Behaviour is predictable and auditable. - One MCP server can be reused across Claude, ChatGPT via connectors , and any other MCP-aware client. No per-vendor integration. - Authorisation is explicit. Tools declare what they do; the agent and the user consents before calling. - The same server is useful for your own internal automation, not just public agents. Adoption is real but uneven. Treat it as an emerging convention worth investing in if your product is API-shaped, and as overkill if it is not. How to implement - Decide what you want agents to do. Read-only tools search products , get order status are a safe first step; write tools create ticket , update address come with stronger auth requirements. - Build an MCP server. The reference SDKs cover TypeScript, Python, and others; see modelcontextprotocol.io https://modelcontextprotocol.io/ . - Host it at a discoverable URL such as /mcp or a subdomain like mcp.example.com . Document the endpoint in your developer docs and link it from /llms.txt /spec/agent-readiness/llms-txt/ . Publish a server card. Ship /.well-known/mcp/server-card.json describing the server’s name, version, transport, endpoint URL, capabilities, tools, and prompts. Add a Link: