ONCHAINSITE
Back to Blog

WebMCP: Chrome 146's Early Preview of Agent-Ready Websites

DevelopmentAI

WebMCP is a proposed web standard shipping in Chrome 146 Canary preview that lets websites expose structured tools to in-browser AI agents—ending brittle button-clicking automation.

Summarize this post with
ChatGPTClaudeClaudePerplexityPerplexityGrok

Introduction: The End of Agents Clicking Buttons

AI agents are getting better at "using" websites…but the way they do it today is fundamentally cursed: they look at pixels/DOM, guess what a button does, and then try to click/type like a human.

It works—until a class name changes, a modal appears, or a multi-step flow takes one extra second to load.

WebMCP is a serious attempt to fix this at the platform level.

In Chrome 146 (Canary, behind a flag), WebMCP is showing up as an early preview that lets websites expose structured tools directly to in-browser AI agents.

Instead of "click the blue button," an agent can call:

searchFlights({ from: "YVR", to: "SFO", date: "2026-03-01" })

That's the shift: publish tools, not pixels.

What is WebMCP?

WebMCP is a proposed web standard from folks across the browser ecosystem (spec repo: webmachinelearning/webmcp) that lets a web page define tools—JavaScript functions with:

  • a name and natural-language description (so an agent can decide when to use it)
  • an input schema (typically JSON Schema) to make parameters unambiguous
  • a structured output (so results can be consumed reliably)

You can think of a WebMCP-enabled page as "MCP, but inside the browser tab."

That phrasing matters:

  • MCP (Model Context Protocol) usually means server-side tools you run on your own infrastructure.
  • WebMCP brings the tool surface into the page, reusing frontend logic and keeping the user in the loop.

The spec is explicit about the intended workflow: collaborative, human-in-the-loop browsing, where the agent and user share the same UI context—a natural fit for Web3 experiences where users need to maintain control over signing and approvals.

Why it matters: the end of brittle "agents clicking buttons"

Most agent automation right now is a form of UI actuation:

  • find element
  • click
  • wait
  • type
  • hope it didn't break

That's fragile for normal web apps; it's especially fragile for onchain apps, where:

  • flows are multi-step (connect → select → review → sign → confirm)
  • the UI is dynamic (quotes refresh, slippage changes, chain switches)
  • the cost of failure is real (wrong network, wrong token, wrong tx)

WebMCP's promise is that websites can expose safe, high-level actions directly:

  • "build a swap quote"
  • "prepare claim transaction"
  • "filter governance proposals by status"

…without an agent needing to reverse-engineer your interface.

You still have a UI for humans. You just also have a contract for agents.

The two WebMCP APIs: Imperative and Declarative

WebMCP is interesting because it isn't "one way to do it." It offers two surfaces that map to how web apps are already built.

1) Imperative API: register tools in JavaScript (navigator.modelContext)

For app teams that want full control, the imperative API lets you register tools programmatically.

In early preview writeups, this shows up under navigator.modelContext, with methods along the lines of:

  • registerTool() / unregisterTool()
  • provideContext() (replace the toolset when state changes)
  • clearContext()

A tool looks like "a function with a schema." Conceptually:

// Pseudocode sketch (API surface is evolving in preview)
navigator.modelContext.registerTool({
  name: "getSwapQuote",
  description: "Return a swap quote for a token pair on Base.",
  inputSchema: {
    type: "object",
    properties: {
      fromToken: { type: "string" },
      toToken: { type: "string" },
      amount: { type: "string", description: "Human-readable amount" },
      slippageBps: { type: "integer" },
    },
    required: ["fromToken", "toToken", "amount"],
  },
  async execute(input) {
    return await quoteEngine.getQuote(input);
  },
});

This approach is ideal when your app already has a clean internal API layer (data fetching, validation, state machines) you can expose safely.

2) Declarative API: turn HTML forms into tools

The declarative API is the "make the web agent-ready by default" path.

You annotate a normal HTML <form> with metadata like:

  • toolname
  • tooldescription
  • optional toolautosubmit

…and the browser can translate the form fields into a structured schema that an agent can invoke.

That's powerful because a huge slice of the web is still…forms.

Even better, WebMCP introduces agent-aware hooks for submission flows:

  • SubmitEvent.agentInvoked to detect when an agent invoked the form
  • SubmitEvent.respondWith(Promise) so your handler can return structured output back to the agent

So you can keep your human UX, but also give agents a reliable response format (including validation errors they can self-correct from).

Try it today (early preview): Chrome 146 Canary + a flag

WebMCP is currently an early preview in Chrome 146 Canary behind a flag.

A typical setup (per community deep dives):

  1. Install Chrome Canary
  2. Open chrome://flags
  3. Search for WebMCP and enable the testing flag
  4. Relaunch

There are also references to a "Model Context Tool Inspector" extension used to inspect and manually execute registered tools while testing.

Resources:

What WebMCP means for Base ecosystem builders (and why you should care)

If you're building on Base, you're probably already feeling this:

  • users want "do the thing for me" experiences
  • agents are becoming the default interface for power users
  • onchain actions still require user review + signing

WebMCP matches the security reality of crypto:

  • agents can help (fill forms, fetch data, build transactions, simulate outcomes)
  • users keep control (they're in the browser, they see what's happening, they still approve)

This aligns perfectly with the evolution of onchain UX toward seamless, user-controlled experiences.

Concrete onchain use cases that map cleanly to "tools"

  • Token claims: checkEligibility() → prepareClaim() → user signs
  • Swaps/bridges: getQuote() → buildTx() → user signs
  • NFT mints: getMintStatus() → buildMintTx() → user signs
  • Governance: listProposals({ status }) → summarizeProposal({ id })
  • Support + debugging: runDiagnostics() that returns structured output

The theme: WebMCP turns your most valuable workflows into invokable, schema'd capabilities instead of brittle UI sequences.

The opportunity: "agent-ready websites" as a new baseline

If WebMCP (or something close to it) lands broadly, we should expect a new baseline:

  • Every serious product has a UI for humans.
  • The best products also expose an agent tool surface.

That doesn't replace APIs. It doesn't replace MCP.

It's a third lane:

  • backend integrations for headless/server agents
  • UI for humans
  • WebMCP tools for in-browser, human-in-the-loop agents

Where Onchainsite fits

Onchainsite exists to help Base teams ship sites and product surfaces faster—especially the parts that convert:

  • landing pages
  • docs
  • dashboards
  • claim/mint/swap pages

WebMCP is a natural extension of that mission. Just as OnchainKit integration helps teams build wallet-connected experiences faster, WebMCP support will help teams build agent-ready experiences.

Near-term: ship WebMCP-ready UX patterns

Even before WebMCP is "stable," teams can start designing flows that map cleanly to tools:

  • atomic actions (one intent per tool)
  • schemas that accept human-friendly inputs (avoid forcing models to do brittle math)
  • strict server/client validation with structured errors

Future: auto-generate WebMCP tool surfaces from your site

This is the exciting part:

Onchainsite could help projects auto-generate WebMCP support in two ways:

  1. Declarative-first: generate forms with toolname/tooldescription, consistent field naming, and agent-friendly validation.
  2. Imperative hooks: generate a safe tool registry layer that exposes only audited actions (quotes, eligibility checks, tx building), with clear schemas.

For onchain apps, "tool exposure" should be treated like an API surface:

  • versioned
  • permissioned
  • observable
  • safe by default

That's exactly the kind of scaffolding Onchainsite can standardize.

Practical advice if you want to be early

If you're a Base builder and want to get ahead of this wave:

  1. Inventory your key flows (claim, swap, mint, governance) and identify the minimum set of high-level actions.
  2. Define schemas for those actions (inputs + outputs). Treat them like product contracts.
  3. Separate "prepare" from "execute." In crypto, most tools should build a transaction and return it—execution is user signing.
  4. Design for human-in-the-loop: the UI should always reflect state changes whether initiated by user or tool.

Closing

WebMCP is still early. But it's a clear signal: the browser is moving toward a world where agents are first-class users—and websites that expose structured capabilities will win.

For the Base ecosystem, this is an opportunity to build onchain experiences that are:

  • faster to use
  • safer to automate
  • easier to integrate into the agent-native internet

If you're building something on Base and want to make it agent-ready, Onchainsite can help you design the tool surface and the UX around it.

Further Reading