How an MCP server actually exposes your site to agents — and how a solo builder can implement one safely

# How an MCP server actually exposes your site to agents — and how a solo builder can implement one safely?

An MCP server exposes your site to agents by publishing a machine-readable “capabilities surface” (what content and tools exist, and how to call them) and then answering structured JSON-RPC 2.0 requests from agent hosts; llms.txt is the discoverability shim that tells agents where that surface lives and what parts of the site are intended for agent consumption.

Quick answer: what you’re really building

At minimum, you’re building an interface contract between (1) an LLM host’s connector code and (2) your site’s read-only, agent-friendly resources. MCP (Model Context Protocol) standardizes the connector/server conversation using JSON-RPC 2.0, with authoritative requirements expressed in a TypeScript schema (schema.ts) and an official spec snapshot (e.g., 2025-03-26). llms.txt is the “site manifest” that points an agent to those resources (including an MCP Server Card, and often Markdown-friendly content endpoints).

For a solo builder, the core practical goal is: make it easy for agents to discover and fetch the right context—without accidentally advertising actions you can’t safely allow.

What MCP and llms.txt actually do (plain terms)

Think of llms.txt as a small, predictable file at the site level that answers: “What is this site, and where are the machine-readable entry points?” It’s commonly described as analogous to robots.txt, but geared toward LLM/agent consumption rather than crawler directives. In the agent-ready ecosystem, llms.txt typically points to one or more of:

• An MCP endpoint (the server that speaks JSON-RPC 2.0)
• A Server Card / API catalog (a machine-readable descriptor of what’s available)
• Clean content endpoints (often Markdown, including .md pages)

MCP then covers the “do the actual talking” part. Once a host’s connector knows where your MCP server is, it can request structured information and invoke the capabilities you chose to expose. The key constraint is that MCP is not “an agent runtime.” Your server does not run an agent; it provides context and tools in a standardized format so an agent host can do useful work.

Architecture and roles: who talks to whom

MCP is explicitly client-server, with three roles defined in the spec:

• Hosts: LLM applications that orchestrate agents and initiate connections.
• Clients: connector code inside the host that implements MCP’s client behavior.
• Servers: your service that exposes context, tools, and capabilities.

The important builder consequence: your “MCP integration” is mostly about shaping server behavior to match a schema-driven contract. The spec uses normative language (MUST/SHOULD/etc.) per RFC 2119/8174, which matters because connector implementations will assume those requirements when they decide what to call and how to parse your responses.

Mechanically, MCP uses JSON-RPC 2.0 message framing: the host-side client sends JSON-RPC requests; your server replies with JSON-RPC responses (or errors) that match the schema expectations.

How discoverability and content accessibility work together

Most agent failures on the open web aren’t “model problems”; they’re input-shape problems. Agent-ready guidance emphasizes four layers: Discoverability, Content Accessibility, Bot Access Control, and Protocol Discovery.

In practice, llms.txt and Markdown delivery carry a lot of the load:

• Discovery: llms.txt gives a stable, low-cost way for agents to find machine-readable entry points.
• Content accessibility: Markdown content negotiation (or dedicated .md endpoints) gives agents clean text without UI noise, reducing token waste and retrieval ambiguity.

That’s not theoretical. Cloudflare reported that after optimizing docs for agent consumption (using llms.txt and Markdown negotiation), its docs implementation consumed 31% fewer tokens and produced 66% faster response times. Whether your site is docs-heavy or API-heavy, that’s the mechanism: less irrelevant markup → fewer tokens → faster agent turns.

Security and spoofing risks MCP introduces

Once you create a “capabilities surface,” you also create a new place for things to go wrong. The risks below aren’t MCP-specific in the sense of “new vulnerabilities in JSON,” but MCP makes certain classes of mistakes easier to operationalize at scale.

• Endpoint spoofing: If an agent trusts a malicious llms.txt or Server Card, it can be routed to an adversarial server that returns poisoned context or attempts data exfiltration. The protocol’s job is to standardize calling; it doesn’t guarantee the right server is being called.
• Unauthorized capability exposure: The fastest way to get hurt is to advertise something you didn’t mean to expose (admin, billing, destructive endpoints). Once advertised, a host may try to call it—repeatedly.
• Privacy leaks: Agents fetching content or calling endpoints can unintentionally pass along identifiers or secrets if your implementation relies on ambient browser-style auth assumptions (cookies, session tokens) rather than explicit controls.
• Traffic amplification and probing: Publishing a clear machine interface can increase automated probing. Even if every call is “read-only,” it’s still load and still an attack surface.

The thesis: treat discoverability (llms.txt) as metadata, not authorization, and treat Server Cards as a public contract you should assume will be scraped.

Why It Matters Now

Two concrete signals from the current agent-ready ecosystem create a timing window for solo builders.

First, adoption is still extremely low. Cloudflare’s April 2026 data point: while 78% of sites implement robots.txt, only 4% declare AI usage preferences—and fewer than 15 sites worldwide had implemented MCP Server Cards at that time. If agents increasingly prefer “known-good, machine-readable” entry points, then being early makes you easier to use than the baseline web.

Second, the performance upside is already measurable in real deployments. The Cloudflare docs numbers (31% fewer tokens, 66% faster responses) are exactly the kind of advantage that compounds in agent workflows, where cost and latency stack across multiple tool calls. If you’re building agent-facing features, this also pairs naturally with routing/orchestration choices inside the host—see Can a solo builder run an OpenRouter‑style model router this month? for how “better inputs” and “better model selection” interact in practice.

A minimal, safe MCP server you can implement this month (checklist)

A safe “month-one” MCP server is small, schema-compliant, and intentionally boring.

1. Publish llms.txt as discoverability only

Point to the MCP entry point and any agent-friendly docs. Keep it descriptive; don’t imply it grants permission.

1. Serve a minimal Server Card / API catalog

Expose only read-only, non-sensitive capabilities (public docs, public API spec, public metadata). Assume it’s public.

1. Implement a strict JSON-RPC 2.0 allowlist

Only accept method names you explicitly support. For everything else, return JSON-RPC errors rather than “best effort” behavior. This is where schema-driven development matters: validate requests and responses against the spec’s TypeScript schema expectations.

1. Gate anything sensitive behind explicit auth—and don’t advertise it publicly

If you later add write operations, require explicit credentials per request. Keep those operations out of the public Server Card until you have a threat model and revocation/rotation story.

1. Make content agent-friendly via Markdown negotiation or .md endpoints

Separate “pretty UI pages” from “clean context.” Ensure the agent-facing version is scrubbed of user-specific or session-derived data.

1. Add basic abuse controls (rate limits + logging)

MCP makes automation easier. You should be able to answer: who called what, how often, and what you can block.

If your product moat is “domain expertise + orchestration,” MCP is one of the cleanest ways to externalize the domain layer safely while keeping agent logic inside the host you control—aligned with Domain expertise + agent orchestration is the practical moat solo builders should be coding for.

Minimal code & hosting pattern (one-paragraph sketch)

Host two public resources: llms.txt, and a small machine-readable Server Card (or equivalent catalog). Host one MCP JSON-RPC endpoint over HTTPS. Your handler should parse JSON-RPC 2.0, verify the method against an allowlist, validate payload shapes against the MCP schema-driven expectations, and return structured JSON-RPC errors for unknown or malformed calls. Keep the public card read-only; put anything account-scoped behind explicit authentication, and assume the public endpoints will be discovered and exercised by automated clients.

Operational checklist before going public

• Re-audit what you advertise: remove write/admin operations from any public descriptor.
• Verify your Markdown endpoints don’t include user-specific data (or anything that could become user-specific under some rendering path).
• Test against known implementations and examples: Microsoft’s MCP GitHub catalog and Remote MCP Servers provide concrete reference points for how connectors and registries expect endpoints to behave.
• Monitor traffic patterns and be able to revoke access quickly (even for “read-only” surfaces).

What to Watch

• Adoption signals: whether llms.txt and Server Cards remain rare (they were: fewer than 15 MCP Server Cards worldwide as of Cloudflare’s April 2026 snapshot), or whether they become default infrastructure.
• Spec churn: updates to the MCP TypeScript schema and spec snapshots (the schema is the authoritative contract many implementations will code against).
• Registry gravity: whether catalogs like Microsoft’s and registries like Remote MCP Servers become the default “app store” discovery path for agents.
• Adjacent access-control standards: AgentReady guidance references complementary protocols (A2A, x402, Web Bot Auth). If those harden, expect hosts to demand stronger proofs before calling anything beyond public read-only endpoints.

Sources: github.com, remote-mcp-servers.com, modelcontextprotocol.io, luismori.dev, agentready.org, isitagentready.com