Should you add WebMCP to your website?

01 First find out why the agent gets stuck

Take a spare-parts search as an illustrative example. A customer knows which machine they use and needs a compatible part that is available. On your website, that means choosing the model, setting filters and checking stock. Before deciding what to build, watch an agent attempt this task. Where does it stop, lose the selected model or return a part that does not fit?

The answer gives the team a starting point. An unclear label calls for a different repair from a filter that forgets the selected model. And if the catalog does not record which parts fit, that information has to come first. You can investigate these causes without committing to a WebMCP integration. The point of the first attempt is to understand what needs fixing.

02 WebMCP could give the agent a direct way to search the catalog

WebMCP lets a website offer an agent a function it can call through the browser. A site can define that function in JavaScript or describe it in an HTML form. In our example, the agent could send the machine model and part requirement to a combined catalog search, rather than carrying those details through several controls. Chrome documents an origin trial, a limited test programme, from version 149.[S1] The specification checked on 9 October 2026 is a draft, not a finished W3C Standard.[S2]

For your team, the practical question is whether the browser and agent you intend to test can use that function. Establish this before building the pilot. Chrome describes WebMCP primarily for local browser workflows with a person involved; it is not a promise that every customer agent can use your site this way.[S1] Our Agent Experience definition puts this experiment in the wider customer journey.

03 Fix the existing search when that is enough

The graphic and table work through three possible findings from this example. They help the team choose its next piece of work. Several causes can occur together, so check the data and access first, then compare ways to complete the lookup. These are proposed steps, not customer results.

If the agent cannot identify the model selector, start with its label and the feedback it gives. Semantic HTML and accessible labels help agents interpret an interface.[S3] Try the same search after the repair. If it works, the team has addressed that problem without adding a tool. If the model still gets lost between filters, a combined lookup is worth testing. Keep it focused on the customer’s request and validate the values in code; an input schema alone does not enforce valid inputs.[S4]

04 Decide separately whether the agent may search or place an order

For this example, we would start with a read-only lookup. The result should identify the matching catalog record, the checked conditions and whether availability is known. A missing machine variant should trigger clarification, not a confident substitute. An unavailable part should remain unavailable rather than becoming a successful-looking answer.

Keep order placement outside that first experiment. Chrome’s tool-security guidance points out that even a read-only function can reveal information about users.[S7] We therefore recommend enforcing access and business rules in the underlying system, keeping consequential actions behind their actual authorization process, and preserving the human route. A reassuring tool name is no substitute for those controls.

05 Check whether the agent now finds the correct spare part

To decide whether the pilot helps, the team needs to know what a correct answer looks like. Use a small set of approved test requests and have someone check the expected results against the catalog. Include a matching part, an unclear model, an unavailable part and a request the user is not allowed to make. Record the browser, agent and request wording so the comparison can be repeated.

Run the existing interface, any repaired interface and the bounded tool against those tasks. Chrome’s evaluation guidance covers tool choice, arguments, outputs and the complete task, including failures between steps.[S5] For our decision, record accepted results, incorrect results, unresolved attempts, necessary human interventions and elapsed time where measured. Keep attempts as the denominator. A successful function call is not enough if it returns the wrong part.

Use those results to decide what deserves more work. Compare any observed improvement with the effort of building and maintaining the integration, and agree who owns the catalog rules and who maintains the tool. A promising test gives you a reason to address the next identified weakness. It does not tell you how many customers will adopt it. Repeat the comparison before expanding to orders.

06 Bring one failed lookup to the first conversation

Start with one request an agent cannot complete today. Bring the attempted search, the catalog result you would accept and the person responsible for those data to a conversation with MING . That gives us a concrete task to assess together. Our Agent Experience work connects existing business capabilities to the ways agents can use them.[S6] From there, we can discuss whether the next step is a repair, a bounded pilot or better underlying information.