What Is WebMCP? The Agentic Web and Websites That Work With AI Agents

What is WebMCP and why should website owners care?

WebMCP is a proposed browser standard that lets a website expose its forms and JavaScript functions to AI agents as named "tools" with plain-language descriptions and input schemas. Instead of guessing from screenshots, an agent calls the exact action your site defines, inside the user's own browser session.

In short, WebMCP gives your site and the agent a shared contract. Authors from Google and Microsoft started the proposal, and it now lives as a draft in the W3C Web Machine Learning Community Group. That means it is not a finished W3C standard yet. Still, the direction is clear, and Chrome already lets developers test it.

I have watched search, ads and user behavior shift on client sites since 2012, and I try not to chase every new acronym. WebMCP deserves attention for a practical reason: it changes how software agents complete tasks on your pages. In this guide I cover what it is, how it differs from MCP servers and browser automation agents, what the "agentic web" really means, and what you can prepare today without betting the budget on a draft.

What does the term "agentic web" actually mean?

The agentic web describes a web where AI agents act on behalf of people: they browse, compare, fill in forms and start transactions. So far, websites have served two kinds of visitors, humans and search crawlers. Agents add a third kind, and they behave differently from both.

For example, someone might tell an assistant, "Book a table for two next Tuesday evening." The assistant opens the restaurant's site, finds the booking form, enters the date and party size, and then asks the person to confirm. In that flow, the visual design matters less than whether a machine can understand what each field does.

• Human visitors respond to layout, trust signals and persuasion.
• Search crawlers read, index and rank content.
• AI agents take actions to complete a goal the user gave them.

Bookings are only one case. Quote requests, product comparisons, adding items to a cart, rescheduling appointments and opening support tickets all fit the same pattern. Therefore the old question, "Can people use my site?", now comes with a second one: "Can an agent use my site correctly, and only in the ways I allow?"

Why did Google and Microsoft propose WebMCP?

WebMCP answers a real weakness in how agents use websites today. Many browser agents take a screenshot or read the DOM tree, then infer which button to press and what to type. The approach works surprisingly often, but it stays fragile.

For instance, a redesign moves a button and the agent loses its way. Cookie banners, pop-ups and multi-step forms add more guesses to the chain. In addition, every guess usually means another model call, which adds cost and latency. As a result, nobody in that loop, including the site owner, has a clear picture of what the agent will do next.

The Chrome team frames the fix simply: instead of an agent guessing the purpose of an interface element, you declare it. In other words, the site says "here is an action, here are its parameters, here is what it returns," and the agent uses that contract.

There is also a governance angle that I think gets overlooked. With WebMCP, you decide which actions an agent may perform on your site. As a result, the standard is not only a convenience for developers; it also hands a measure of control back to the business that owns the page.

How does WebMCP work under the hood?

At its core, WebMCP adds a "model context" interface to the page. The current draft places it at document.modelContext. You may still see navigator.modelContext in older articles and early builds; the editors moved the API to the document to reflect that tools belong to a specific page.

1. Registration: the page registers a tool with registerTool(), giving it a name, a natural language description and an input schema.
2. Discovery: the agent asks the browser which tools the page offers.
3. Execution: the agent calls a tool with arguments, and the browser runs it in the page's own context before returning the result.

That said, the key detail is where this happens. The call runs inside the browser, in the session the user already has open. So the agent acts through the account the person is signed in to, without a separate API key or backend integration. That is a big convenience, and it is also a responsibility you need to manage carefully.

WebMCP offers two paths. The declarative API turns existing HTML forms into tools with a few attributes. The imperative API lets you define richer tools in JavaScript. In practice, most sites will start with the first and grow into the second.

How does the declarative API turn a form into a tool?

The declarative API annotates a normal HTML form so agents can understand it. According to the official explainer, the form-level attributes toolname and tooldescription provide the tool's name and description. On individual fields, toolparamdescription describes each parameter in the generated input schema.

In addition, there is a boolean attribute called toolautosubmit. It lets the agent submit the form on the user's behalf after filling it in. For that reason I would reserve it for low-risk, reversible forms. A newsletter signup might qualify; a checkout step should not.

The draft also extends the submit event. The agentInvoked flag tells your code whether an agent triggered the submission. Meanwhile, the respondWith() method lets you hand the agent a meaningful result rather than a bare "form sent" signal.

For visual feedback, the explainer defines two CSS pseudo-classes: :tool-form-active and :tool-submit-active. You can use them to show people that an agent is filling in a form right now. It sounds like a small detail, but it matters because visible activity builds trust; users should always see what happens on their screen.

In practice, the declarative path is the shortest route for sites with well-built forms. If your labels, field names and validation rules already make sense, adding WebMCP support takes only a few lines of markup.

When do you need the imperative API instead?

You need the imperative API when an action does not fit into a single form. With JavaScript you register a tool, give it a name, a description, an input definition in JSON Schema and the function to run. Chrome's documentation lists form input, navigation, state management and custom functions as typical uses.

Take an online store as an example. A tool like "filter in-stock products by size and color" touches filter state, pagination and the results list at once. With the imperative API you wrap that logic in one tool, and the agent receives structured results instead of scraping a grid of product cards.

Likewise, a SaaS dashboard might expose "list invoices from the last 30 days" or "get the status of a support ticket." These tools mostly read data, so their risk stays low. Tools that change data, on the other hand, need extra safeguards, which I cover in the security section.

The draft also lets the page limit who may call a tool. With the exposedTo option you can restrict a tool to origins you trust. Keep that option in mind, because it becomes important once tools can reveal account data.

My rule of thumb is simple. If a human completes the task with a form today, start declarative. If the task goes beyond a form, move to the imperative API. That way you avoid complexity you do not need.

What is the difference between WebMCP and an MCP server?

The names cause confusion, so let me draw the line clearly. The Model Context Protocol describes itself as an open-source standard for connecting AI applications to external systems. An MCP server usually runs on your infrastructure and offers data and tools to clients such as Claude or ChatGPT.

WebMCP carries a similar idea into the browser. The tools live in the open page, not on a server. Consequently, authentication rides on the user's existing browser session, and you do not need to build a separate authorization flow.

So the two are complementary, not rivals. Back-office automation fits an MCP server well. When a customer works on your site together with an assistant, WebMCP is the more natural fit. Many businesses will eventually run both.

How is WebMCP different from browser automation agents?

Browser automation agents try to use a site the way a person would. They look at the page, locate elements, click and type. Their main strength is that the site needs no preparation at all. However, everything rests on inference.

WebMCP, by contrast, needs the site owner to participate. If you define no tools, the agent falls back to the old approach. Once you do define them, though, the agent calls something like "create_booking" directly instead of hunting for a button.

• Speed: one tool call replaces a chain of screenshots and clicks.
• Resilience: the tool contract stays stable when the design changes.
• Control: you decide what an agent may and may not do.
• Measurement: you can tell agent submissions apart from human ones.

There is an important limit, too. Chrome's documentation states that the API mainly targets local browser workflows with a human in the loop and that headless browsing is not its focus. In other words, WebMCP is a bridge for assistants that work alongside a person, not a tool for unattended bulk automation.

For a business, "which approach wins?" is the wrong question. The better one: when an agent arrives, will you make it guess, or will you give it a clearly labeled door?

Can you use WebMCP in Chrome today?

Yes, with caveats. On June 9, the Chrome team announced a WebMCP origin trial starting with Chrome 149. An origin trial is a time-limited program that lets sites test an experimental feature with real traffic before it ships by default.

For local development, Chrome's documentation points to the chrome://flags/#enable-webmcp-testing flag. There is also the Model Context Tool Inspector extension, which shows the tools a page registers and lets you invoke them manually. That combination is the fastest way to check whether your tool descriptions make sense.

Honesty matters here. WebMCP is not switched on for every user by default, and the draft keeps changing; the move from navigator to document is proof of that. Therefore any code you write now may need updates later.

Chrome's docs also note experimental WebMCP support in Angular. For other frameworks and browsers, follow official announcements rather than blog rumors. The two most reliable references are the Web Machine Learning group's WebMCP explainer on GitHub and Chrome's own developer documentation.

Which businesses benefit from WebMCP first?

Urgency, however, varies. In my view, the first winners are sites where people come to complete a task, not just to read. On the other hand, a brochure site that only describes a company can wait.

• Booking and scheduling: clinics, restaurants, salons, hotels.
• Ecommerce: product search, filtering, add to cart, order tracking.
• B2B quote requests: forms that ask for product, quantity and delivery date.
• SaaS dashboards: reports, record creation, settings.
• Customer support: opening tickets and checking their status.

Consider a manufacturer's quote form. These forms tend to be long and technical. If an agent can fill one in correctly, a procurement manager can request a quote in two sentences. However, mistakes here cost real money, so field descriptions must leave no room for doubt.

My advice: list the three most valuable actions on your site. In practice, they usually match the conversions you already track. Start WebMCP preparation there and your effort lands where it pays back.

How should you prepare your forms for WebMCP?

Most WebMCP readiness is simply good form design. A form that makes sense to a person is already close to making sense to an agent. So begin with cleanup, not with new technology.

1. Give every field a visible label; do not rely on placeholder text alone.
2. Use meaningful field names, such as "delivery_date" instead of "f3."
3. Pick the right input types: date for dates, email for email, number for quantities.
4. Define required fields and format rules in HTML, not only in scripts.
5. Write clear error messages that explain what went wrong and how to fix it.
6. In multi-step forms, summarize the purpose of each step in one sentence.

These steps also improve accessibility. A screen reader user and an agent interpret a page through similar signals. Consequently, every fix pays off twice.

I covered the conversion side of this in my guide to lead form design for bookings, quotes and demos. From a WebMCP perspective, I would add one point: the simpler the form, the shorter and more reliable the tool definition.

How do you write a good WebMCP tool description?

The tool description is the text an agent reads to decide when and how to use a tool. Write it like a work instruction, not like marketing copy. Specifically, it should be short, concrete and clear about its limits.

Chrome's secure tools guide suggests character budgets: about 500 characters for a tool description, 150 for a parameter description, 30 for tool and parameter names, and roughly 1.5K characters per tool output. The guide adds that limits vary between agents. Even so, they give you a practical frame.

• Name: start with a verb and describe one job, for example "create_booking."
• Description: say what it does, when to use it and when not to.
• Parameters: state units and formats, such as "date in YYYY-MM-DD."
• Output: return a short, structured result the agent can relay.

Still, a common mistake is loading one tool with too many jobs. A "do everything" tool raises the chance of misuse. Instead, define small, focused tools; search, add to cart and order status should be three separate tools.

Also, put your business rules into the description. A line like "same-day appointments are unavailable" stops the agent from making pointless attempts, and the user sees fewer error messages.

Does structured data replace WebMCP, or the other way round?

Neither replaces the other; they work on different layers. Structured data describes what your content is: this is a product, this is its price, this is its stock status. WebMCP describes what someone can do on the page: add this product to the cart, with these parameters.

Think of Schema.org markup as the labels in a shop window, while WebMCP is the list of things the clerk at the counter can do for you. Therefore an agent needs both to act well. First it understands what you sell, then it completes the action.

So keep your structured data in good shape. Product, service, local business, FAQ and event markup all help agents interpret your content. If you want the fundamentals, read my explainer on what schema markup is. For a quick start, our schema generator produces valid JSON-LD in minutes.

Consistency matters as well. If the price in your markup differs from the price a tool returns, the agent gets confused and the customer loses trust. Therefore feed both layers from the same data source.

What security risks come with WebMCP?

Security is the most important WebMCP topic. The explainer itself says that interacting with AI agents crosses traditional trust boundaries. Because the agent works with the user's session, a poorly designed tool can do real damage.

According to Chrome's documentation, WebMCP works only in origin-isolated documents, and a permissions policy called tools gates it. By default that policy allows only the same origin. Otherwise, a cross-origin iframe cannot register tools; it needs explicit permission before it can register tools.

The secure tools guide also recommends three annotation hints:

• readOnlyHint: marks tools that do not change state.
• consequentialHint: marks tools with significant effects, such as booking travel or moving money.
• untrustedContentHint: marks tools that return user-generated or external content.

That last hint deserves special attention. Text hidden inside a product review could try to give the agent instructions it should not follow; security people call this prompt injection. So flag tools that return user content and keep their output short. For the broader foundations, my website data security and encryption guide is a good starting point.

How should you handle user consent and privacy?

When an agent acts for a user, responsibility still sits with you and that user. For that reason, leave the final word on important actions to the person. Chrome's documentation mentions a command that requests user interaction through a confirmation dialog for sensitive actions such as purchases.

In practice, my team and I use a three-level split. Tools that only fetch information can run without confirmation. Actions that send data but can be undone get a short confirmation. Payments, cancellations and account deletions always require explicit consent.

Privacy law applies just as before. An agent that fills in a form still delivers personal data to your form, so your privacy notice, consent checkboxes and data minimization rules stay in force. Never let an agent tick a consent box automatically; consent has to come from the person.

Keep records, too, because disputes happen. Using the agentInvoked flag, you can tag agent submissions separately, which helps if a dispute ever arises. For the general framework, see my guide on how to build a GDPR-compliant website.

Will WebMCP change SEO and AI visibility?

No, WebMCP is not a ranking factor, and it does not change how search engines index you. Visibility inside AI answers belongs to generative engine optimization, which I cover in what is GEO.

Still, the two connect. An agent recommending you is a GEO outcome; the agent completing a task on your site afterwards is a WebMCP outcome. Visibility opens the door, and WebMCP lets the agent finish the job. If either half is missing, the agent may simply choose another site.

Meanwhile, an llms.txt file serves yet another purpose: it summarizes your content for language models. You can draft one quickly with our llms.txt generator. For the technical basics, read technical SEO after AI.

Put simply, treat WebMCP as the next step after SEO, not a replacement for it. Be findable first, then be usable.

A 30-day WebMCP readiness plan

You do not need to write code on day one. The plan below lets a small or mid-sized business prepare while keeping risk low. We recommend the same order for client projects.

1. First week, inventory: list every form and key action on the site, and note the business value of each.
2. Second week, cleanup: fix labels, field names, input types and error messages.
3. Third week, pilot: convert one low-risk form, such as contact or newsletter, into a declarative tool on a staging site.
4. Final week, security and measurement: add the hints, tag agent submissions separately, and review what you learned.

The most valuable output of this plan is often not WebMCP itself but cleaner forms. Conversion rates and accessibility usually improve at this stage. Then, as the standard matures, the decision to go live becomes much easier.

Remember that origin trials expire and drafts change. So if you experiment on a live site, build it in a way that lets you switch the feature off quickly.

What should you ask your developers or agency?

You do not need deep technical knowledge to raise WebMCP with your team. Asking the right questions is enough, and the answers also reveal the general health of your site.

• Do our forms meet accessibility standards, and does every field have a label?
• Do our critical actions draw on a single source of truth for prices and stock?
• Can we add an origin trial token to test a new feature safely?
• Can we see agent submissions separately in analytics?
• Are our Content Security Policy and permissions policies up to date?

If the answer is "I don't know," that is fine; you have found your starting point. If you want to explore other AI uses on a website, my guide on how to use AI on your website covers chatbots, content and analytics.

My team and I plan this readiness from the start on new builds. If you are considering a new site or a redesign, our web design service includes a form architecture that agents can work with.

What are the most common WebMCP mistakes?

With any new technology, the biggest risk is rushing and skipping the basics. Likewise, the mistakes I see in WebMCP experiments mostly fall into that category.

• Turning everything into a tool: dozens of tools confuse the agent; pick the valuable actions first.
• Vague descriptions: "submits the form" tells the agent nothing useful.
• Skipping confirmation: using toolautosubmit on risky forms is a serious error.
• Assuming stability: the draft can change, so keep the code isolated and easy to disable.
• Not measuring: without separate tagging, you will never see the effect.

There is also an expectations trap. Agent traffic will not explode the day you add WebMCP, because people need time to adopt these assistants. Treat preparation as an investment rather than a short-term sales lever.

Finally, if you want to plan SEO and paid media together with this new layer, our SEO consulting engagements include an agentic web readiness review.

Where should you start with WebMCP today?

WebMCP moves the conversation between websites and agents from guessing to agreement. The draft, started by authors from Google and Microsoft, sits in a W3C community group, and Chrome lets you test it through an origin trial. Still, it is not a final standard yet.

That is why I recommend a balanced approach. Clean up your forms, make your structured data consistent and review your security policies now. Those steps pay off even if WebMCP changes shape. After that, pilot one low-risk form and follow the standard as it develops.

The agentic web will not arrive overnight. When it does, prepared sites will stand out, because an agent that does not have to guess finishes the user's task faster.