mcp-handler now exposes selected MCP tools inside the browser
Vercel announced experimental WebMCP support in mcp-handler on September 18, 2026. Teams using the package can opt selected MCP tools into an experimental_webMcp configuration, then load a script from their MCP endpoint. That script registers the tools with the page and proxies calls to the existing server as the signed-in user. Vercel says the feature is available in mcp-handler@2.2.0.
The practical change is reuse. A product with an MCP server can expose a controlled subset of the same tool contracts to an in-browser agent without building a second browser-side OAuth flow. It is not a general launch of autonomous web access, and it does not make every existing tool appropriate for the page.
The release is small, but the integration boundary is important
The Vercel changelog shows two deliberate controls. Tools are selected by name rather than exposed wholesale, and calls return to the server-side MCP handler. Existing authentication and business logic can therefore remain behind the application boundary while the page publishes a machine-readable way to invoke them.
That is different from an agent inferring buttons, fields, and success states from pixels or the DOM. A named tool has a description, input schema, and defined handler. The contract can make a task more reliable and easier to evaluate. It can also make a badly chosen capability easier to call, so the quality of the tool boundary matters more than the convenience of the script tag.
For teams already evaluating an AI product development partner, this is a useful procurement question: can the team design narrow, observable tool contracts, or does it merely connect a model to a large API surface?
WebMCP remains a proposed standard and Vercel labels the support experimental
The status needs precision. The WebMCP document dated September 17 is a Draft Community Group Report from the W3C Web Machine Learning Community Group. Its own status section says it is not a W3C Standard and is not on the W3C Standards Track. Vercel also calls its package support experimental.
Chrome’s WebMCP documentation presents the API as a proposed standard and a progressive enhancement for structured agent interaction. Product teams should therefore keep the ordinary interface working, detect capability rather than assume it, and avoid making a business-critical journey depend on one experimental path.
This is the main limit on the announcement. It provides an implementation route for a developing interface. It does not establish universal browser support, interoperability across every agent, or a finished security model.
Seuil analysis: choose tools by user outcome and consequence
The best first tool is not the most impressive action. It is a frequent task with clear inputs, a deterministic result, low consequence, and an obvious fallback. Reading an order status, explaining a configuration, or validating draft data is easier to bound than deleting records, publishing content, or committing a purchase.
Start from the user outcome, then decide whether a tool improves it. Exposing every backend action because it already exists reverses that sequence. The page should still explain what will happen, show relevant state, and recover when the agent is absent or wrong. Seuil’s AI Builder work treats those states as product design, because a callable function is infrastructure, not a complete experience.
A hypothetical support portal could begin with get_case_status, a read-only tool returning the current state and next permitted step. It should not begin with close_case. The first teaches the team about discovery, schema quality, authentication, latency, and fallback without making an incorrect call hard to reverse.
The signed-in session removes friction and raises the stakes
Vercel’s proxy uses the signed-in user, which is valuable because the server can apply the product’s existing authorization. It also means the experiment touches real account context. Authentication answers who the user is; it does not decide whether the agent should invoke a particular action now. Authorization, confirmation, rate limits, audit logs, idempotency, and rollback still belong to the product.
The WebMCP draft discusses security and privacy risks including untrusted content, over-parameterized tools, and high-privilege operations. Those sections are evolving, which is another reason to keep initial capabilities narrow. Tool descriptions should not be treated as security boundaries, and sensitive data should not be requested merely because an agent might know it.
For state-changing actions, preserve a human decision at the moment of consequence and ensure the agent cannot silently satisfy its own approval. That control needs testing across the actual browser, agent, page, and server combination rather than confidence borrowed from a diagram.
A useful pilot tests discovery, execution, recovery, and trust
- Expose one read-only tool with a small schema and a documented user outcome.
- Create examples where the agent should call it, should ask for missing information, and should not call it.
- Verify account and object authorization on the server for every invocation.
- Log tool selection, validated inputs, latency, result class, refusal, fallback, and user-visible outcome without collecting unnecessary personal data.
- Keep the normal interface complete and test what happens when WebMCP is unavailable, the tool fails, or the result is stale.
Chrome’s guide to testing WebMCP with evals recommends checking whether agents understand when to call a tool, how to execute it, and which answers are acceptable. Those are product acceptance criteria, not a demo script. The test set should include ambiguous requests, hostile page content, expired sessions, forbidden objects, repeated calls, and degraded server responses.
Watch the standard status, supported user agents, confirmation semantics, and package changes before widening the surface. If your team wants to explore the feature now, the sensible next step is one read-only pilot with a reversible rollout. Seuil Digital can help define the tool contract, fallback interface, and evaluation set before the experiment reaches a consequential workflow.
The opportunity is a better contract, not an invisible interface
Vercel’s release makes a narrow integration materially easier for teams already using mcp-handler. The durable product idea is broader: agent interaction improves when a site exposes intentional, typed capabilities instead of forcing every task through visual guesswork.
The interface should not disappear. People still need visible state, understandable consequences, accessible controls, and a way to take over. If a WebMCP path is more capable than the human path, or harder to inspect than the underlying action, the implementation has optimized the agent demo at the expense of the product.