- Three layers, not three competitors
- llms.txt: discovery and reading
- MCP server: backend tools and data
- WebMCP: in-browser actions
- Side by side comparison
- How they fit together
- Where each one stands in 2026
- FAQs
- Build for all three, in order
Search for "WebMCP" and you will find it described, wrongly, as a replacement for llms.txt, or as a competitor to MCP servers, or as the same thing as both. It is none of those. WebMCP, llms.txt, and MCP servers are three different layers of how AI systems interact with your business, and confusing them leads teams to skip the one they actually need.
The short version: llms.txt helps an AI system find and understand your content. An MCP server lets a backend AI model call tools and pull data from your infrastructure. WebMCP lets an in-browser agent take actions on your live page with the user's own session. Discovery, backend tools, in-browser actions. You can and should have all three, and each makes the others more useful. This article walks through what each one actually does, where it runs, and how they reinforce each other.
---
Three layers, not three competitors
The reason these three get conflated is that they all involve AI agents and they all use similar vocabulary, especially the word "tools." But they sit at completely different points in the stack.
Think of it as a progression. First an AI system has to find you and understand what you offer. That is discovery, and it is what llms.txt addresses. Then a backend model needs a way to actually do things with your systems, query a database, trigger a workflow, check inventory. That is what an MCP server provides. Finally, an agent running inside the user's browser needs to act on the page in front of them with their live session and permissions. That is WebMCP.
None of these replaces another. A site with a great llms.txt but no MCP server is discoverable but not operable by backend agents. An MCP server with no in-browser layer cannot help an agent that is acting on behalf of a logged-in user on your actual page. They are complementary, and the strongest posture is to have all three.
---
llms.txt: discovery and reading
llms.txt is a plain-text file you publish at the root of your domain. Its job is discovery and comprehension. It gives AI systems a clean, structured map of your most important content so they can find it and understand what your business does, without wading through navigation menus, marketing fluff, and rendering quirks.
Here is the critical limitation that people miss: llms.txt does not let an agent do anything. It is read-only by nature. It cannot book an appointment, submit a form, or query your database. It is a pointer and a summary, not an action surface. Its entire value is making you legible to machines so you get found and cited accurately.
CloudNSite already publishes an llms.txt file, because being discoverable and correctly understood by AI assistants is table stakes now. But discovery is only the first layer. Once a system knows you exist and what you offer, the next question is whether it can actually use any of it. That is where the other two layers come in.
---
MCP server: backend tools and data
An MCP server is a backend service that exposes tools and data to an AI model over the Model Context Protocol, the broader open protocol for connecting AI models to tools and data, documented at modelcontextprotocol.io. Where llms.txt is a static file an agent reads, an MCP server is a live service an agent calls.
This is the layer where real work happens on the server side. An MCP server might expose tools to search a product catalog, create a support ticket, pull a customer record, or run a report. The AI model connects to the server, sees the available tools and their input schemas, and calls them with structured arguments. The server runs the logic on your own infrastructure and returns a structured result.
The key distinction from WebMCP is location. An MCP server typically runs on your servers, not in the user's browser. It is built for backend and assistant-side integrations, the kind of thing that powers an AI assistant, an internal copilot, or an automated workflow that needs trusted access to your systems. CloudNSite builds these. They are how you make your data and operations callable by AI models in a controlled, auditable way.
---
WebMCP: in-browser actions
WebMCP, short for Web Model Context Protocol, takes the tool concept and moves it into the web page itself. It lets a website expose its own functionality, either JavaScript functions or plain HTML <form> elements, as callable tools that an AI agent can discover and invoke directly through the browser. The browser-native API is called navigator.modelContext.
The difference that matters is whose session the agent acts with. Because the tool is just your existing client-side code, the action runs in the browser with the permissions the user already has. An in-browser agent can search your inventory, add an item to the cart, or start a booking, acting on behalf of the logged-in user, on the actual page they are viewing. An MCP server cannot do that, because it lives on the backend and has no concept of this particular user's live browser session.
WebMCP also inverts control. Instead of an agent taking a screenshot and reverse-engineering where to click, the site tells the agent exactly what is possible and what inputs each action needs. That is far more reliable than screen-scraping, especially on dynamic, JavaScript-heavy pages. We cover the mechanics, the standards path, and what to do about it in our pillar guide, What Is WebMCP.
---
Side by side comparison
| llms.txt | MCP server | WebMCP | |
|---|---|---|---|
| What it is | A plain-text file mapping your key content | A backend service exposing tools and data | A browser API exposing page actions as tools |
| Where it runs | A static file at your domain root | On your own servers or infrastructure | Inside the web page, in the user's browser |
| What it enables | Discovery and reading of your content | Backend agents calling tools and pulling data | In-browser agents taking actions on the live page |
| Maturity | Established convention, widely adopted | Open protocol, in active production use | W3C Draft Community Group Report, in preview |
| Who calls it | AI assistants and crawlers finding you | AI models and assistant-side integrations | An agent in the browser, iframe, or extension |
---
How they fit together
The three layers form a natural sequence: be found, be usable by backend agents, be actionable in the browser. Each one reinforces the others.
Start with llms.txt so AI systems discover and correctly understand what you do. That is the front door. Add an MCP server so backend AI models and assistants can actually call your tools and work with your data in a controlled way. That turns "they know you exist" into "they can do business with your systems." Then add WebMCP so an agent acting inside a user's browser can complete actions on your real page with that user's session.
Discovery feeds the backend, and the backend feeds the in-browser experience. A site that nails all three is legible to machines at every level: found through content, operable through backend tools, and actionable in the browser. The discipline that gets you there, clear actions, semantic HTML, structured schemas, and predictable inputs and outputs, is the same discipline that helps with AI-assistant citations and accessibility. None of it is wasted.
---
Where each one stands in 2026
Maturity differs a lot across the three, and that should shape how you sequence the work.
llms.txt is the most mature and the easiest to adopt. It is a simple convention you can implement today with no dependency on browser support or backend services. There is no reason not to have one.
MCP servers are built on the Model Context Protocol, the broader open protocol for connecting AI models to tools and data, and they are already in active production use across many real integrations. If you want AI models or assistants to work with your systems, this is proven and available now.
WebMCP is the newest and least settled. It is a proposal being incubated in the W3C Web Machine Learning Community Group, created by engineers at Google and Microsoft, and published as a W3C Draft Community Group Report on February 10, 2026. It is not yet an official W3C Recommendation. On the browser side it shipped as an early preview in Chrome 146 Canary behind a flag, and Chrome opened a developer origin trial in a later release so sites can experiment with real users. So you can build against WebMCP today, but it is not yet supported in every visitor's browser. Prepare for it, do not bet your conversion funnel on it yet.
---
FAQs
Is WebMCP a replacement for llms.txt? No. They do different jobs at different layers. llms.txt helps AI systems discover and read your content, and it is read-only. WebMCP lets an in-browser AI agent take actions on your live page through the navigator.modelContext API. One is about being found and understood, the other is about being used. You should have both.
What is the difference between an MCP server and WebMCP? Location and session. An MCP server is a backend service that exposes tools and data to an AI model, typically running on your own infrastructure. WebMCP exposes tools inside the web page through the browser, so an in-browser agent acts with the user's live session and permissions. They are complementary, not competing.
Does llms.txt let an AI agent take actions on my site? No. llms.txt is a plain-text file for discovery and reading only. It helps AI systems find and understand your content. It cannot book, submit, query, or trigger anything. For actions you need an MCP server on the backend or WebMCP in the browser.
Do I need all three? For most businesses that want to be ready for the agentic web, yes. llms.txt makes you discoverable, an MCP server makes your systems callable by backend AI models, and WebMCP makes your page actionable by in-browser agents. They reinforce each other, so the value compounds when you have all three rather than just one.
Which one should I implement first? llms.txt, because it is the most mature, the easiest to add, and it has no dependency on browser support or backend services. Then an MCP server if you want AI models to work with your data and tools, since that protocol is already in production use. WebMCP comes last, since it is still in preview and origin-trial stages.
Is WebMCP an official W3C standard yet? No. WebMCP is a proposal incubated in the W3C Web Machine Learning Community Group and published as a W3C Draft Community Group Report on February 10, 2026. It is on a standards path but is not a finalized W3C Recommendation, and browser support is still in preview and origin-trial stages.
---
Sources
- W3C Web Machine Learning Community Group, WebMCP specification (Draft Community Group Report) (2026): defines WebMCP as a way for websites to expose JavaScript functions or HTML form elements as tools, with natural language descriptions and structured schemas, for AI agents to discover and invoke; created by engineers at Google and Microsoft.
- Chrome for Developers, Join the WebMCP origin trial (2026): documents the
navigator.modelContextbrowser API and the Chrome preview and origin trial that let sites expose page actions to in-browser agents. - Anthropic, Model Context Protocol: the broader open protocol for connecting AI models to tools and data, the standard that MCP servers implement and that WebMCP brings into the browser.
---
Build for all three, in order
WebMCP, llms.txt, and MCP servers are not a choice you make between options. They are three layers of the same goal: being legible and useful to AI systems at every level, from discovery to backend tools to in-browser actions. The teams that win the agentic web will treat all three as one connected strategy, built in the order that matches their maturity: discoverable first, operable second, actionable in the browser third.
CloudNSite builds the full stack: structured, discoverable content, production MCP servers, and the agent-ready interfaces this shift demands. If you want a clear read on which layers your business needs and in what order, book a free 30-minute call. No obligation, just a straight answer.