MCP endpoints and llms.txt solve different discovery problems

When teams ask whether to publish an llms.txt file or build a Model Context Protocol (MCP) server, they are often comparing two different jobs. A text file can point agents toward useful information. An MCP endpoint can give compatible clients a structured way to request information or invoke tools. One is a signpost; the other is an interface.

For many sites, the practical choice is not either-or. It is whether the application needs an interactive agent interface at all, and whether the team can operate one without exposing data or creating a maintenance burden.

What a static llms.txt file does well

An llms.txt file is plain text, typically used to identify important site content and provide links or context for systems that choose to read it. It is straightforward to publish and inspect. A documentation site, brochure site or public knowledge base with mostly stable pages may have little reason to serve anything more dynamic.

Its main advantage is simplicity. The file can be updated with the site content process and delivered like any other static asset. It does not need to query a database, manage a live connection or define a set of callable operations. That makes it a reasonable starting point when the goal is to help agents find public material, not to let them ask an application for current, tailored results.

There is a limit: a manifest is not a search engine, access-control system or guarantee that an agent will read the listed pages. The content itself still needs to be accessible, clear and maintained. A stale list of links is a small file with a large potential to mislead.

What an MCP server adds

MCP gives compatible clients a protocol for interacting with a server that exposes resources or tools. That interaction can support requests whose answers depend on current application data or a defined operation. A product catalog that changes often, for example, may benefit from an interface that can return current records rather than relying only on a manually curated description.

That capability comes with operational work. A team has to decide what the server can expose, how requests are authorized, how errors are handled and how the endpoint is monitored. Database-backed applications need particular care: a useful query surface should return only intended records and fields. The practical concerns behind adding AI discovery routes to a custom PHP database app safely apply whether the route serves Markdown or implements MCP.

MCP is not automatically a public directory listing. Clients need a way to learn that an endpoint exists and how to connect to it. A site may still need documentation or a static manifest to explain the service. Publishing an endpoint alone does not make every agent aware of it.

Choose by the job, not the label

For a mostly static public site, start with well-organized pages and a maintained manifest if it helps describe them. For an application where agents need current, structured answers or controlled actions, evaluate MCP. Some systems will need both: a static file can explain what is available, while an MCP server handles supported interactive requests.

• Choose a static manifest when the content is public, changes infrequently and the main need is orientation.
• Consider MCP when a compatible client needs live data, structured responses or a specific application operation.
• Use both cautiously when discovery information and interactive access serve distinct purposes; keep their descriptions and permissions aligned.

Before implementing either option, test the actual paths. Can an unauthenticated visitor fetch the intended public content? Does the manifest point to current pages? If an MCP endpoint exists, does it expose only the operations and records the team intends? Treat these as separate checks. A file being reachable says nothing about whether a live endpoint is safe, and an endpoint responding correctly says nothing about whether an agent can discover it.

Measure readiness without confusing it with reach

Evaluation tools can help teams inspect multiple aspects of a site, but a score is a diagnostic signal, not proof that agents will find or cite the content. BuiltToWinWeb’s WebAgentScan is a hosted SaaS product that evaluates website readiness for AI agents across multiple performance metrics and provides a score out of 100. That kind of assessment can sit alongside direct checks of manifests, endpoints, access boundaries and the content agents are meant to use.

The most maintainable design is usually the smallest one that serves a real need. A static llms.txt file is not a lesser version of MCP; it is a different, simpler tool. An MCP server is worth the added complexity when an application needs an interactive contract that static text cannot provide. Neither format replaces clear public content, deliberate permissions or ongoing maintenance.