If a customer wants an agent to configure something while they watch and make corrections, I’d consider WebMCP. If they want a scheduled process to retrieve records while nobody has the application open, I’d start with a service API or an MCP server.
The distinction is where the work happens and what context it needs. The similar names can make that decision harder than it should be.
When the page is part of the workflow
WebMCP exposes application actions from a web page as tools. The agent can use the page’s current state, and the application can update its interface as the work proceeds. The WebMCP explainer describes this as a collaborative workflow between the user, the page, and the agent.
Consider a product configurator. The customer has already selected a model, chosen some options, and signed in. They ask an agent to find a compatible alternative. Keeping that interaction in the application lets the customer inspect the changed configuration and keep working from it.
Useful tools might search compatible parts or prepare a configuration for review. I’d give those tools the same compatibility checks used by the interface. Reimplementing those rules for the agent would create another place for them to drift.
The brief planner on this site is a smaller version of that pattern. An agent prepares the brief; the visitor sees it and can edit the form. The shared state is the point of the example.
When the service should be usable independently
A server integration makes sense when the agent needs direct access to a system without depending on an open page. Think of retrieving yesterday’s orders, looking up an issue, or creating a report as part of a scheduled job.
The WebMCP proposal distinguishes its page-based approach from MCP’s client-server communication and transport layers. They’re related approaches, with different execution contexts. WebMCP’s protocol discussion explains the relationship.
For that background reporting job, I would put the business operation behind an authenticated service boundary. The integration needs scoped access, clear errors, and a way to avoid duplicate work if the caller retries. Whether an MCP server is worthwhile depends on which clients need to use it; an existing API may already be sufficient.
Some applications need both
A support product might offer WebMCP tools for helping a customer prepare a request in the portal, alongside an MCP server that lets an internal assistant search authorized tickets.
Those are different users and different tasks. They can share the underlying validation and business logic while exposing different operations and permission scopes.
I would avoid committing to both interfaces before identifying those tasks. Two integrations mean two contracts to test and maintain.
| Question | WebMCP is a candidate when… | A service integration is a candidate when… |
|---|---|---|
| Where is the user? | In the application, reviewing or editing the result. | The task can run independently of an open page. |
| Which context matters? | Current selections, visible filters, and page state. | Records and operations exposed by the service. |
| What is the handoff? | The user continues from the updated interface. | Another system consumes the result. |
| What must be supported? | Named browsers and agent clients. | Named API or MCP clients and their authentication flows. |
Check the environment before promising the outcome
As of September 8, 2026, the project’s implementation tracker lists Chrome and Edge origin trials and support in ChatGPT Desktop. Firefox and Safari have standards-position tracking links. That’s a reason to specify supported environments in a pilot, rather than assume every visitor has the same capabilities. Current implementation status
There is also a discovery limit: clients need to visit a site to discover its WebMCP tools. Adding tools does not itself establish a distribution channel. Chrome’s limitations are worth reading before treating the integration as a marketing investment.
The first deliverable is a testable task
Before building either integration, I’d write down what a correct result looks like. For a report, that includes filters and account permissions. For a booking, it includes the slot, attendees, price, and the point where the user confirms.
Then choose the smallest integration that supports that task and measure it. Record failed attempts and human corrections alongside successful runs. That gives the team a useful basis for deciding whether to expand.
My WebMCP pilots start with that assessment. If you already have a workflow in mind, the planner will turn a short description into a draft we can discuss.