llms.txt and MCP Endpoints
Does having llms.txt mean a company is shipping AI?
No. An llms.txt file is a publishing convention, not proof of AI in production, and a standard human-facing one costs nothing to add. Bassethound classifies llms.txt as standard or technical, then weighs it against model providers, SDKs, vector stores, and MCP endpoints in one call, where a standard file counts as an experimenting signal at best. Only the technical, machine-facing variant tips a domain toward the shipping verdict.
Best move: classify the llms.txt before you trust it, because a standard documentation index is not proof of production AI.
Why it works: publishing a standard llms.txt costs an afternoon and signals intent, not infrastructure. Only a machine-facing (technical) file, or corroborating stack signals, moves the verdict.
Key takeaways
- llms.txt is a publishing convention from llmstxt.org, not evidence of AI infrastructure. It is cheap to add and easy to game.
- Bassethound classifies llms.txt as standard (a documentation index) or technical (a machine-facing endpoint). Only the technical variant is a shipping signal on its own.
- A standard llms.txt counts as one signal group, which lands a domain in the experimenting verdict, not shipping.
- The shipping verdict needs a machine-facing endpoint (MCP, a .well-known AI file, or a technical llms.txt) or at least three distinct signal groups firing together.
- Bassethound returns the llms.txt classification alongside model providers, SDKs, vector stores, and MCP endpoints in one correlated dossier.
What does an llms.txt file tell you?
llms.txt is a proposal from llmstxt.org: a markdown file at your domain root that gives language models a curated map of your site. It points to clean markdown versions of key pages so an LLM answering a question about you does not have to wade through navigation, ads, and script tags. That is its whole job. It tells you a company wants to be read well by AI. It does not tell you the company builds with AI. Those are different claims. The file is authored by hand, ships as static text, and takes an afternoon to write. A marketing team can add one after reading a single blog post. So the presence of llms.txt is real information (someone thought about AI consumers) but it is weak information about production AI. Bassethound treats it as a starting question, not an answer. It fetches the file at the fixed path, confirms it parses, and then classifies it: is this a documentation index (standard), or does it expose a machine-facing surface (technical)? The classification is the part that carries weight. The raw presence, on its own, sits close to noise.
Why doesn’t a standard llms.txt count as shipping AI?
Because shipping AI means a model runs in your product path, and a documentation index says nothing about that path. Bassethound’s verdict has three states: none, experimenting, shipping. A domain earns shipping one of two ways. Either a machine-facing endpoint is present (an MCP server, a .well-known AI file, or a technical llms.txt), or at least three distinct signal groups fire (say a model provider, an AI SDK, and a vector store together). A lone standard llms.txt is one signal group. One group lands you in experimenting, the floor above none. It hints that someone on the team is paying attention, not that a model is in production. This matters because publishing a standard llms.txt costs almost nothing and looking AI-forward pays off, so the file is exactly the kind of signal that gets gamed. Scoring a domain as AI-ready because it has llms.txt rewards the gesture over the engineering. Bassethound counts distinct signal groups so one cheap file cannot carry a verdict it did not earn. If the standard llms.txt sits next to Anthropic’s SDK and a Pinecone client, the verdict moves. On its own, it holds still.
When does an llms.txt file signal real AI in production?
When it is the technical variant, or when it travels with corroborating signals. A technical llms.txt is machine-facing: it points at or exposes operational surface an agent can act on, not just docs a reader can browse. Bassethound treats that as an endpoint in the same class as an MCP server or a .well-known AI file, and an endpoint like that is enough to trigger the shipping verdict on its own, because someone had to build and host it. The second path is corroboration. A standard llms.txt beside a model provider, an AI SDK (Anthropic SDK, OpenAI SDK, Vercel AI SDK), an orchestration framework (LangChain, LlamaIndex, CrewAI), and a vector store is a different picture than the file alone. Three distinct groups firing crosses into shipping regardless of how the file is classified. So the honest read is conditional. llms.txt can be part of a shipping signal, but it is rarely the deciding one unless it is technical. Bassethound gives you the classification and the surrounding signals in the same dossier, so you are not guessing which case you are in. You see the file, its class, the endpoints, and the count of groups that fired.
How does Bassethound weigh llms.txt against the rest of the stack?
It folds the classification into a single AI-readiness layer, then scores. The ai_readiness score is the count of distinct signal groups a domain hits, out of six, capped at 1.0. Signal groups span model providers, AI SDKs, orchestration, vector stores, LLM observability (Helicone, LangSmith, Langfuse), and machine-facing endpoints (MCP, .well-known files, technical llms.txt). A standard llms.txt informs the read but does not, by itself, count as the machine-facing endpoint that a technical file or an MCP server would. Alongside the score sit two labels. The verdict (none, experimenting, shipping) reads the groups and the presence of any machine-facing endpoint. The icp_signal (hot, warm, cold) translates that into whether the domain is worth your outreach. A domain with a technical llms.txt, a vector store, and an observability tool reads hot. A domain with a lone standard llms.txt reads warm at most, often cold. The point of the layer is to stop any single file from dominating. You get a number you can sort on and two labels you can filter on, all correlated with the other four layers (tech stack, infrastructure, firmographics, security) in one keyless call.
What can llms.txt detection miss?
Plenty, and pretending otherwise would be dishonest. Bassethound reads llms.txt with a static crawl at the fixed path, with optional JavaScript rendering for the rest of the signals. A static file is easy to fetch, so the classification is reliable when the file exists. The gaps are elsewhere. A company can run heavy AI in production and publish no llms.txt at all, in which case this signal stays silent and the verdict leans on SDKs, vector stores, and endpoints instead. A company can proxy its AI calls entirely server-side, so no client library or API hostname ever reaches the browser, and that stack stays invisible from the outside. A technical llms.txt behind auth, or served only to specific agents, may not be reachable on an anonymous crawl. Bassethound reports these gaps rather than papering over them. The dossier tells you what it saw and what it could not reach, so a low AI-readiness score reads as absence of external evidence, not as proof of absence. That distinction is the whole ethic of outside-in detection. You act on what you can verify, and you flag what you cannot.
Bassethound perspective
Most AI-readiness tools treat llms.txt as a green checkmark. They grep for a file with “llm” in the name, find it, and score the company as AI-ready. That is a category error. A standard llms.txt is a documentation index. It means someone read a post about being friendly to language models and spent an afternoon writing markdown. It does not mean a model runs anywhere near their product. We classify llms.txt as standard or technical so the cheap gesture cannot buy the expensive verdict. The technical variant, a real machine-facing endpoint, earns shipping. The standard variant earns a shrug and a warm-at-best label until something in the actual stack corroborates it. The competitors who count file presence are selling you a metric any marketing team can farm in an hour. We count distinct signal groups, and we weight machine-facing endpoints over published intentions, because intentions are free and infrastructure is not. If a domain wants us to call it shipping, it has to show us the plumbing, not the sign on the door.
Sources
- llms.txt proposal: https://llmstxt.org
- Model Context Protocol: https://modelcontextprotocol.io
- Anthropic documentation: https://docs.anthropic.com
- Pinecone documentation: https://docs.pinecone.io
Frequently asked questions
Can a company publish llms.txt without shipping any AI?
Yes. A standard llms.txt is a documentation index anyone can add in an afternoon. It signals that a team wants to be read well by language models, not that a model runs in their product. Bassethound classifies the file and, on its own, treats a standard one as an experimenting signal at most.
What is the difference between a standard and a technical llms.txt?
A standard llms.txt is a human-authored map of your docs for LLMs to read. A technical llms.txt is machine-facing, exposing operational surface an agent can act on. Bassethound counts the technical variant as an endpoint in the same class as MCP, so it can trigger the shipping verdict. The standard variant cannot do that alone.
Does having llms.txt alone trigger a shipping verdict?
No. A standard llms.txt is one signal group, which lands a domain in experimenting. Shipping needs a machine-facing endpoint (MCP, a .well-known AI file, or a technical llms.txt) or at least three distinct signal groups firing together.
Can you classify llms.txt without rendering JavaScript?
Yes. llms.txt is a static file at a fixed path, so a plain fetch reads and classifies it. JavaScript rendering matters for the client-side signals around it (SDK initialization, API calls), not for the file itself. Bassethound reports anything it could not reach.
Does Bassethound treat an MCP endpoint and an llms.txt the same?
No. An MCP endpoint is machine-facing and counts toward the shipping verdict on its own. A standard llms.txt does not. A technical llms.txt sits in the machine-facing class with MCP, which is why the classification matters more than the file name.