MCP and WebMCP: giving AI agents a direct way into your site

Most AI agents use your website the way a person does: they read pages, click links and fill in forms. That works, but it's slow and it breaks easily. MCP and WebMCP give agents a second way in, a set of named actions such as "search products" or "check order status" that they can call directly. This guide explains both, what they mean for your business, and how to start small.

Two ways an agent can use your site

Today, an AI agent asked to find a waterproof jacket in a medium on your store has to work your pages. It loads the home page, finds the search box, reads the results, opens a product, works out the size picker, and reads the price. Every step depends on your page layout. A redesigned menu or a new pop-up can stop it.

The alternative is to tell the agent what it can do and let it ask directly. Instead of driving the search box, it calls a search_products action with "waterproof jacket, medium" and gets back a clean list of products, prices and stock. That's the idea behind both MCP and WebMCP.

• Faster. One request instead of a dozen page loads and clicks.
• More reliable. Actions don't change when you redesign the page.
• More accurate. You decide exactly what data comes back, so agents quote the right price and stock.

It doesn't replace a usable website. Many agents will keep using your pages for a long time, and the people they hand back to always will. Think of MCP and WebMCP as an extra, faster lane for the agents that support them.

What MCP is

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to outside tools and data. Anthropic introduced it in late 2024, and it has since been adopted by many AI assistants, developer tools and software companies.

An MCP server is a small service that describes a set of tools (actions an agent can call, each with a name, a plain-language description and the inputs it expects) and can also offer resources (data it can read, such as a catalog or a policy). An AI application connects to the server, reads the list, and calls the tools it needs to complete a person's request.

For a website, a remote MCP server runs alongside your site, usually on your own domain, and talks to the same systems your site does. Typical tools for an online store:

Tool	What it does	Risk
search_products	Finds products by keyword, category, size or price	Read-only
get_product	Returns price, variants, stock and delivery estimate for one product	Read-only
get_policy	Returns shipping, returns or warranty terms	Read-only
get_order_status	Looks up an order for a signed-in customer	Needs sign-in
add_to_cart	Builds a cart and returns a link for the person to check out	Changes state

Software companies might offer tools to look up plans and pricing or search documentation. Service businesses might offer tools to check availability and request a booking.

Commerce platforms are starting to offer MCP servers for the stores they host, so check with yours before building one. If you have a developer team and an existing API, a read-only server is often a small project, because it wraps calls you already make.

What WebMCP is

WebMCP is an early proposal for bringing the same idea into the web page itself. Instead of running a separate server, your page registers tools with the browser through a new JavaScript API, navigator.modelContext. An agent working in that browser can then call the page's tools directly instead of clicking through it.

It's being developed in the open at the W3C's Web Machine Learning Community Group, with engineers from Google and Microsoft among those working on it. Community group work is incubation, not a finished standard, and browsers don't ship WebMCP by default yet. Expect the details to change.

Two features make it interesting for websites:

• It reuses your page code. The tool can call the same functions your search box or add-to-cart button already calls.
• It works with the person's session. Because it runs in the page, it can use the cart and sign-in the person already has, without separate API credentials.

A tool registered in a page looks roughly like this, guarded so it does nothing in browsers without the API:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search Northwind Outdoor products by keyword, size and maximum price.",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string" },
        size: { type: "string" },
        maxPrice: { type: "number" }
      },
      required: ["query"]
    },
    async execute({ query, size, maxPrice }) {
      const results = await searchCatalog({ query, size, maxPrice }); // your existing search
      return { content: [{ type: "text", text: JSON.stringify(results) }] };
    }
  });
}

The proposal also describes a declarative form: adding a toolname attribute (with a description) to an existing <form>, so a search or contact form becomes a tool without new JavaScript. Attribute names may change as the proposal develops.

MCP or WebMCP?

	MCP server	WebMCP
Where it runs	A service on your domain	Inside your web pages
Who can use it	AI applications that connect to MCP servers	Agents working in a browser that supports it
Maturity	Published specification, widely used	Early proposal, not shipped by default
Sign-in	Needs its own authorization for personal data	Uses the person's existing session
Best first step	Read-only catalog, pricing and policy tools	Mark up your search form, then experiment

For most businesses, an MCP server is the practical choice today, and WebMCP is worth a small experiment so you're ready if browsers adopt it.

What AgentScore looks for

The AgentScore check "Agents can use your site through MCP or WebMCP" is part of the Access category. It passes if it finds any of these:

• An MCP server description at /.well-known/mcp.json or /.well-known/mcp. There's no settled standard for advertising an MCP server yet, and proposals for a well-known server description are still being discussed, so we look in the most likely places.
• A link in your home page: a <link> or <a> whose rel or type mentions MCP.
• An MCP server listed in your llms.txt, with its URL. See how to write an llms.txt file.
• WebMCP tools registered in your home page. Because browsers don't ship WebMCP yet, the scanner provides a stand-in navigator.modelContext before your scripts run, so pages that check for the API register their tools as they would in a supporting browser. We record the tool names.
• Forms marked up as WebMCP tools with a toolname attribute.

If none is found, the check is a warning rather than a failure. Agents can still use your pages; they just have to do it the slow way. It carries less weight than the checks that decide whether agents can get in at all, such as bot protection and robots.txt.

How to start, safely

1. Ask your platform first. If your commerce platform or CMS offers an MCP server or WebMCP support, turning it on is far cheaper than building one.
2. Start read-only. Search, product details, pricing, stock and policies. These answer most agent questions and can't change anything.
3. Write tool descriptions for a reader who has never seen your site. The description is how an agent decides which tool to call. "Search products by keyword, size and maximum price; returns name, price, stock and URL" beats "Search".
4. Return the same facts your pages show. Prices, stock and policies must match the website exactly, or agents will quote figures your checkout won't honor.
5. Keep people in charge of money. For anything that changes state, such as building a cart, return a link the person opens to review and pay. Leave fully agent-led checkout to the agentic commerce protocols designed for it.
6. Protect it like an API. Rate limits, logging and authorization for anything personal. See rate limits for AI agents.
7. Advertise it. List the server in llms.txt with a link to its documentation, and add a well-known description or a <link> in your page head.

What it means for the business

An MCP server or WebMCP tools won't bring traffic on their own. They make each agent visit more likely to end well: the right product found, the right price quoted, the cart built. Because support among AI applications is still growing, the best order of work is the usual one. Make sure agents can get in and read your pages first, then add a direct lane for the agents that can use it.

Not sure where you stand on the basics? Start with what agent readiness means, then run AgentScore to see every Access check, including this one.