WebMCP vs Public Endpoint vs llms.txt: 3 Ways to Serve AI Agents on Your Site (2026)

llms.txt tells agents what you offer, a public endpoint lets any agent ask your business a question and get an answer, and WebMCP lets browser agents call tools registered on your page. Most businesses need at least two of the three, because each one reaches a different set of agents and does a different job.

The question usually arrives framed as "WebMCP or a public API?", and the honest answer is that it's the wrong fork. They sit at different layers. llms.txt is a static file for reading. A public endpoint is a conversation any HTTP client can hold. WebMCP is a browser feature that only works where a browser or agent supports it. If personal agents are already researching, comparing and contacting your business on your customers' behalf (the shift we call B2A, or business to agent), the practical question is which combination covers the agents you actually see, with the controls you need.

Below: a side-by-side table, one section per method (what it is, how it works, pros, limits, when to use it, an example), a decision list, how we run all three on lorikeetcx.ai, and the security and rate-limit notes that apply to each.

Key takeaways

• llms.txt is a proposed convention: a markdown file at your site root that summarizes what you do and links to clean pages. Cheap to publish, read-only, and only as current as your last edit.

• A public endpoint is a plain HTTP URL an agent can call with a question. Any agent that can make a web request can use it today. It can hand off to your real support system, so it can end in an answer, a booking or a resolution.

• WebMCP is a proposed web standard drafted in a W3C community group. Pages register JavaScript tools that browser agents can call. Support is early: origin trials and a handful of agents, per the proposal's own implementation status page.

• They stack. llms.txt points agents to the endpoint, the endpoint serves every agent, and WebMCP gives supported browser agents a faster, more reliable path on the page itself.

• Whatever you pick, the agent should get the customer's authority and no more, and it should be told how often it may ask.

WebMCP vs public endpoint vs llms.txt at a glance

The maturity column matters more than it looks. A method only helps you if the agents hitting your site can use it. Today that means the plain endpoint and readable pages carry most of the load, and WebMCP is where you get ahead of a shift that's coming but not yet universal.

1. llms.txt: tell agents what you offer

What it is

llms.txt is a proposal, authored by Jeremy Howard and published on llmstxt.org, to add a markdown file at /llms.txt that gives language models "brief background information, guidance, and links to detailed markdown files". The proposal was first published in September 2024 and revised as v2 in August 2026. It's a convention, not a ratified standard: nobody is obliged to read it, and no agent is obliged to follow what it says.

How it works

The format is deliberately simple. Per the proposal, the file contains, in order: an H1 with the name of the site (the only required part), a blockquote summary, optional paragraphs of detail, and zero or more H2 sections that list links, each written as a markdown link with optional notes. A section called "Optional" is, by convention, the stuff an agent can skip when it's short on context. The v2 proposal also suggests publishing clean markdown versions of key pages and pointing to them with standard link relations, so agents don't have to strip navigation and scripts out of your HTML.

An agent reads the file, finds the section relevant to its task and follows the links. That's the whole mechanism. There's no request, no response, no state.

Pros

• Cheap. One file, and many documentation and site platforms can generate it.

• Readable by any agent that can fetch a URL, with or without a browser.

• A good place for instructions: you can tell agents, in plain language, where to ask questions and how to book, which is how most of them will discover your endpoint in the first place.

• It has momentum. The v2 proposal notes that thousands of sites publish one and that Chrome's Lighthouse checks for it as part of its agentic browsing audits.

Limits

• Read-only. It can't answer a question it didn't anticipate, check an account or take an action.

• It goes stale. Pricing, policies and eligibility rules change; the file only changes when someone edits it. An agent quoting last quarter's fee from your llms.txt is a support ticket waiting to happen.

• No guarantee it's read. Agents that ignore it will scrape your pages instead.

• Public by nature. Everything in it is visible to everyone, so it can only carry general information.

When to use it

Always, as the front page for agents. It costs almost nothing, and its best use is as a signpost: a short description of what you do, links to your clean policy and pricing pages, and explicit instructions pointing to whatever can actually answer questions or complete tasks.

Example

A minimal llms.txt for a lender might look like this:

# Example Lending> Car finance with pre-approved budgets, managed in-app.## Ask our support agent (for AI assistants)- [Public endpoint](https://example.com/agents): how to ask questions over HTTP## Policies- [Fees and rates](https://example.com/fees.md): current fee schedule- [Hardship](https://example.com/hardship.md): how to request help with repayments## Optional- [Blog](https://example.com/blog.md)

# Example Lending> Car finance with pre-approved budgets, managed in-app.## Ask our support agent (for AI assistants)- [Public endpoint](https://example.com/agents): how to ask questions over HTTP## Policies- [Fees and rates](https://example.com/fees.md): current fee schedule- [Hardship](https://example.com/hardship.md): how to request help with repayments## Optional- [Blog](https://example.com/blog.md)

# Example Lending> Car finance with pre-approved budgets, managed in-app.## Ask our support agent (for AI assistants)- [Public endpoint](https://example.com/agents): how to ask questions over HTTP## Policies- [Fees and rates](https://example.com/fees.md): current fee schedule- [Hardship](https://example.com/hardship.md): how to request help with repayments## Optional- [Blog](https://example.com/blog.md)

# Example Lending> Car finance with pre-approved budgets, managed in-app.## Ask our support agent (for AI assistants)- [Public endpoint](https://example.com/agents): how to ask questions over HTTP## Policies- [Fees and rates](https://example.com/fees.md): current fee schedule- [Hardship](https://example.com/hardship.md): how to request help with repayments## Optional- [Blog](https://example.com/blog.md)

2. A public endpoint: let any agent ask and get an answer

What it is

A public endpoint is a URL an agent can call with a question and get an answer back, over plain HTTP, with no browser, login or API key. It's the lowest common denominator for agent traffic: if an agent can make a web request, it can use it. That includes agents that never render your page at all, such as assistants working from a server, or personal agents that move between email, chat and phone on their user's behalf.

The design question is what sits behind the URL. A thin wrapper around an FAQ can answer "what are your opening hours?" and not much else. An endpoint connected to the same concierge that serves your human customers can answer from your knowledge, run your workflows and follow your policies, so a conversation that starts with a question can end in a booking, a sale or a resolved ticket.

How it works

The simplest useful shape is a GET request with the question in the query string and a JSON response. Because a good answer can take a few seconds to produce, the better endpoints are asynchronous: the first call returns a pending status and a conversation ID, and the agent checks back for the answer. Each response carries instructions for the next call, so an agent can follow the protocol without anyone hardcoding it.

On lorikeetcx.ai, the footer notice reads: "It is available to people via this site's support channels, and to AI assistants via a public endpoint: GET https://api.lorikeetcx.ai/v1/ask/<public key>?q={your question, URL-encoded}. Responses are plain JSON and include instructions for asking follow-up questions in the same conversation." Our llms.txt spells out the loop: the first request returns a pending status with a conversation ID, a turn number and a poll URL; the agent waits about 10 seconds and repeats the request with those IDs; a follow-up question reuses the same conversation ID with the next turn number, and the concierge keeps the earlier context.

Pros

• Universal. It works for every agent that can make a request, which today is nearly all of them.

• It answers the question the agent actually has, from current knowledge, instead of hoping the answer is somewhere in a static file.

• It can take actions, because it can be wired into the same workflows, identity checks and action policies as your other channels.

• It's measurable. Every call is a conversation you can log, read and sort by topic, which tells you what agents are asking for.

• It gives you a place to set the rules: how often to ask, when to check back and what the agent may do.

Limits

• Agents have to find it. That's what llms.txt, a footer notice and clear instructions are for.

• It's anonymous by default. A question arrives without a verified customer attached, so anything account-specific needs the same identity verification you'd apply to a person on chat or phone before the agent gets anything private.

• It invites volume. An open URL needs rate limits and a check-back pattern, or an eager agent will poll it the way it polls everything else.

• If you build it yourself, it's real work: conversation state, retries that don't duplicate tickets, logging, abuse handling and keeping answers consistent with your other channels. See our notes on secure API and webhook integrations for AI support if you're going that route.

When to use it

Whenever you want agents to get accurate answers or complete tasks, and you can't predict which agent your customer uses. It's the method that reaches the most agents today, and it's the one that turns agent traffic into outcomes rather than page views.

Example

A customer asks their personal agent to find out whether they can pause their car loan repayments for a month. The agent reads the lender's llms.txt, finds the endpoint, and asks the general question. The concierge answers from the lender's hardship policy and explains that applying needs the customer to verify their identity. The agent passes that back to its user, who verifies, and the application proceeds under the same policy a person on chat would get. The whole exchange lands in the support queue as one ticket.

3. WebMCP: let browser agents call tools on your page

What it is

WebMCP is a proposal from the W3C Web Machine Learning Community Group, edited by engineers from Microsoft and Google. The explainer describes it as a way for developers to "expose web application functionality, either JavaScript functions or HTML <form> elements, as 'tools' with natural language descriptions and structured schemas" that AI agents can call, including agents built into the browser, running in extensions or hosted in iframes. The specification is a Community Group draft, which is an early stage. It's a proposed web standard, not a ratified one.

The name borrows from Model Context Protocol, Anthropic's protocol for connecting AI applications to tools and data. The explainer frames a WebMCP page as something like an in-page MCP server: the tools run in the browser, in your page's own code, instead of on a separate backend.

How it works

Your page calls document.modelContext.registerTool() with a tool name, a description, an input schema and an execute function. The explainer lays out the lifecycle: the page registers tools, a connected agent asks the browser which tools are available, the agent calls one with structured arguments, the browser mediates the call and runs your code on the page, and the result goes back to the agent. Tools can be registered and removed as the page state changes. For simple cases, a declarative version lets the browser build tools from existing HTML forms.

The point, per the explainer, is to replace "brittle UI actuation (DOM scraping, simulated clicks)" with well-defined tools. An agent trying to book a table by clicking through a calendar widget is slow and error-prone. An agent calling a book_table tool with a date and party size is neither. Because the tool runs in the user's own browser session, it can reuse the page's existing logic and keep the visible page in sync, without you replicating state and authentication on a separate server.

Pros

• Fast and reliable for the agents that support it: no guessing what a button does.

• Reuses your front-end code instead of requiring a new backend integration.

• Keeps the human in the loop. The explainer's stated goal is cooperative workflows where users can see and control what the agent does on the page.

• Security controls are part of the design: the browser mediates calls, and tools are not exposed to other origins unless you allow it.

Limits

• Coverage. According to the proposal's implementation status page, as of late September 2026 there's an origin trial in Chrome 149 and one in Edge 150, support in ChatGPT Desktop and experimental support in Brave's Leo. Firefox and Safari have open standards-position requests. Chrome's origin trial announcement describes origin trials as "time-limited programs that offer early access to experimental platform features".

• Browser-only by design. The explainer lists fully autonomous, headless-only workflows where no browser UI is present as a non-goal. Agents that never open your page, such as those working over email or phone, won't use it.

• The API can still change. Drafts evolve, and code written against today's shape may need updating.

• Tools are an attack surface. Chrome's own WebMCP tool security guidance warns that it's "impossible to guarantee safety inside of a large language model" and that prompt injection attacks against agentic systems are repeatable.

When to use it

When browser agents are part of your traffic and you want them to complete tasks on your site reliably: answering questions in context, filling complex forms, booking, checking status. Add it alongside a public endpoint, not instead of one, so agents without WebMCP support still have a sanctioned way in.

Example

On lorikeetcx.ai, our footer notice tells agents that when WebMCP is available on the page, they can use two browser tools: lorikeet_ask_concierge and lorikeet_get_concierge_response. The pair mirrors the endpoint's ask-then-check-back pattern: one tool sends the question, the other collects the answer. A browser agent on our site can call those tools directly instead of finding and typing into the chat widget.

Which should you use? A decision list

1. Publish llms.txt regardless. It's the cheapest step and it's how agents learn the other two exist. Put your endpoint and any agent instructions near the top.

2. If agents only need public facts (pricing, opening hours, what you do), llms.txt plus clean, current pages may be enough for now. Keep the facts in one place so the file and the pages don't drift apart.

3. If agents ask questions your pages don't answer directly, add a public endpoint. This is the usual trigger: support starts seeing agent-shaped contacts (the signs are fairly consistent) and the answers need judgment or current data.

4. If agents need to take actions (book, cancel, update details, apply), the endpoint has to sit on top of your real workflows with identity verification before anything account-specific. A static file can't do this at all.

5. If browser agents are a meaningful share of your traffic, or your key journeys are complex forms and multi-step flows, add WebMCP tools for those journeys. Keep the endpoint as the fallback.

6. If you're in a regulated industry, decide the action policy before the method. What an unverified agent may be told, what needs step-up verification and what always needs a human matter more than the transport. We cover this for fintech and healthcare under HIPAA.

7. If you're tempted to block everything instead, read blocking vs serving AI agents first. Blanket blocking bans your own customers along with the bad bots.

Most businesses end up at "llms.txt plus endpoint" now, and "llms.txt plus endpoint plus WebMCP" as browser support grows. For the full implementation sequence, including robots.txt choices, disclosure and analytics, work through the 12-point agent-ready website checklist.

How the three compare on the things support teams care about

How lorikeetcx.ai runs all three

We publish all three on our own site, and anyone can inspect them.

• llms.txt. Our llms.txt opens with a one-line summary, then puts agent instructions first, under the headings "Book a demo (for AI agents)" and "Ask our support agent (for AI assistants)". A "B2A (business to agent)" section follows, then "Main Pages", "Industries" and "Integrations". The agent-facing sections are at the top on purpose: an agent that reads the first screen knows how to ask a question and how to book.

• Public endpoint. The footer on every page carries the endpoint notice quoted above, including a usage policy: "query this endpoint only with your user's knowledge and consent, and send only the question itself, with no personal or sensitive information unless the user explicitly asks you to include it." Behind it is the same concierge that answers our website chat.

• WebMCP. The same footer notice names the browser tools lorikeet_ask_concierge and lorikeet_get_concierge_response, available when WebMCP is available on the page.

All three lead to one place. There's no separate "bot FAQ" that can drift out of sync with what a human customer is told.

How Lorikeet B2A gives you the endpoint and WebMCP without backend work

Lorikeet B2A is built for businesses that receive agent traffic and want to serve it rather than fight it. It gives agents two ways in to one concierge: agents that support WebMCP call tools registered on your website, and every other agent calls a public endpoint in plain HTTP. Both answer from your existing knowledge, so your team does no backend work.

• Same brain as customer service. Agents reach the concierge that serves your customers on chat, email and voice, with the same knowledge, workflows and actions. A conversation that starts as a question can end in a sale, booking or resolution.

• Built for machine traffic. An agent asks, then checks back for the answer. Rate limits cap the volume, and a retry doesn't open a second ticket.

• Governed. Agents get no more authority than the customer: the same guardrails, identity verification and action policies as a person, and they see only what a customer would see. Endpoint conversations are anonymous by default; anything account-specific goes through the identity verification the concierge already applies on other channels.

• Visible. Every agent conversation lands in Lorikeet as a normal ticket, sorted by topic, so you can see what agents want.

Setup is four steps:

1. Create an account.

2. Coach helps you build and test a concierge for your website.

3. Turn on the agent-facing endpoint.

4. Paste the snippet Coach gives you into your website.

What Lorikeet doesn't do: bot management or payments. If you need to block scrapers or process agentic checkout, those are different tools, and our comparison of platforms for AI agent traffic covers who does what. For the bigger picture of why this channel matters, start with what B2A means for customer support.

Security and rate-limit notes for each method

llms.txt

• Treat it as public. Put nothing in it you wouldn't put on your homepage.

• Generate it from the same source as your pricing and policy pages where you can, so a price change updates both.

• Decide what you allow crawlers to fetch in robots.txt (RFC 9309) separately. llms.txt describes content; it doesn't grant or deny access.

Public endpoint

• Rate-limit and tell agents when to check back. Agents poll relentlessly if nothing tells them not to. In September 2026 a personal agent called Instinct sent Resy about 200 API requests an hour for its user, polling every 10 minutes and every 0.4 seconds around the daily table release, and Resy deactivated the account as spam (it was reinstated two days later). A sanctioned endpoint that returns a pending status and a check-back time gives agents a polite path, so you don't end up banning a customer.

• Make retries idempotent. An agent that times out will ask again. The second request should find the first conversation, not open a duplicate ticket.

• Keep it anonymous until verified. General questions need no identity. Anything account-specific should trigger the same step-up verification a person would face, and the agent should get the customer's authority and no more.

• Ask for less. Publish a usage policy that tells agents to send only the question and no personal data unless their user explicitly wants it included.

• Log every conversation as a ticket. It's your audit trail and your best source of what agents want.

WebMCP

• Use the annotation hints. Chrome's tool security guidance recommends readOnlyHint for tools that don't change state, consequentialHint for high-stakes or irreversible actions such as bookings or money transfers, so the agent or browser can ask the user to confirm, and untrustedContentHint for tools that return user-generated or external content.

• Expose tools narrowly. By default, other sites and cross-origin iframes can't use your tools. Only add trusted origins with exposedTo.

• Register tools for the current page state and remove them when they no longer apply, as the explainer recommends. Fewer, well-described tools beat a large catalog.

• Enforce policy on the server too. A tool running in the browser is still client-side code. Authorization and action limits belong in the backend it calls.

The short version

llms.txt is the signpost, the public endpoint is the front door every agent can use, and WebMCP is the fast lane for browser agents that support it. Start with the signpost and the front door, add the fast lane where browser agents do real work on your site, and make all three lead to the same concierge, under the same rules you'd apply to a person.

If agents are already showing up in your queue, we should talk. Get a demo and we'll show you the endpoint and WebMCP tools running on a concierge built from your own knowledge.