Symbiote.js & WebMCP

The web has always been built for humans. Every interaction model we know - buttons, forms, navigation - was designed around eyes, hands, and cognitive habits of people sitting at a screen. But a shift is underway. AI agents are becoming first-class users of web applications, and they don't read pixels. It's time the web learned to speak their language.

WebMCP is a step toward that future. And Symbiote.js is already fluent in it.

What is WebMCP?

MCP (Model Context Protocol) is an open standard for connecting AI agents to tools, data sources, and services. It defines a common interface that agents use to discover capabilities and invoke them - structured, typed, and machine-readable.

WebMCP brings this protocol into the browser itself. Instead of routing every agent interaction through a server-side adapter or browser automation, WebMCP lets a web page expose its own UI capabilities as native MCP tools - directly accessible to any MCP-compatible AI agent with access to the tab context.

Think of it as a structured API that lives inside the page. An agent doesn't have to guess what a button does or simulate a click and hope for the best. It can call submitOrder_in_checkout-form with a typed input schema, get a structured response, and move on. The page tells the agent what it can do, what the preconditions are, and what to expect back.

This is not a workaround. This is the web learning to communicate with a new class of user.

Why it matters

Web agents are already here. Users delegate tasks to AI assistants that browse, fill forms, and take actions on their behalf. Today those agents rely on DOM traversal, heuristic element detection, and screenshot analysis - brittle approaches that break with every redesign.

WebMCP gives agents a stable, semantic contract with the UI. It decouples agent capability from visual layout. It means:

• Reliability: agents call named, typed tools instead of clicking coordinates
• Transparency: tools carry descriptions and input schemas agents can reason about
• Adaptability: tools can expose their availability dynamically, so agents only see what's actually actionable right now
• Safety: execution goes through the same JavaScript handlers the user would trigger - no injection, no simulation
• Performance & Efficience: less heavy and expensive operations and steps for the agent, lower token consumption

The browser is the most widely deployed application runtime in the world. Making it natively agent-capable is not a niche concern. It is the next layer of the web platform.

How Symbiote.js integrates WebMCP

Symbiote.js exposes a first-class WebMCP integration that turns your existing component architecture into a live MCP tool surface - with almost no extra code.

Automatic tools from event bindings

Enable mcpToolMode on the class or globally, and Symbiote will automatically generate MCP tools from every bound event handler in the template:

class CheckoutPanel extends Symbiote {
  mcpToolMode = true;
  submitOrder() {
    // your existing logic
  }
}

CheckoutPanel.template = html`
  <button ${{onclick: 'submitOrder'}}>Place Order</button>
`;

That's it. The agent now has a submitOrder_in_checkout-panel tool. No adapter, no separate registration, no schema file to maintain. The tool name is component-scoped and semantically grounded in your element naming.

The same applies to list items, keyed itemize data, and popup bindings up the component tree - each gets a properly namespaced tool with item context embedded in the name.

Explicit descriptors for full control

When you need descriptions, input schemas, conditional visibility, or custom execution logic, ToolDescriptor gives you everything:

import { ToolDescriptor } from '@symbiotejs/symbiote/webmcp';

class OrderForm extends Symbiote {
  init$ = {
    canSubmit: false,
    submit_order: new ToolDescriptor({
      description: 'Submit the currently visible order.',
      deps: ['canSubmit'],
      when: () => this.$.canSubmit,
      inputSchema: {
        type: 'object',
        properties: { note: { type: 'string' } },
      },
      execute: ({ note = '' }) => this.submitOrder(note),
    }),
  };
}

The when() condition means the tool only appears in the agent's context when it's actually meaningful. The agent sees a submit_order tool only when the order is ready to submit - not as a permanently registered stub that may fail silently.

Shared context tools

For tools that belong to application-level state rather than a single component instance, ToolDescriptor values inside any PubSub context are registered once and shared across all components connected to that context:

PubSub.registerCtx({
  search_docs: new ToolDescriptor({
    description: 'Search the current documentation context.',
    inputSchema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] },
    execute: ({ query }) => searchDocs(query),
  }),
}, 'DOCS');

This mirrors how MCP servers work in the server-side world - a single tool surface for a bounded domain, independent of which components happen to be rendered.

Component context for richer agent understanding

componentDescription lets each component tell agents something about what it represents in the current page context - including live data fetched at call time:

class UserDashboard extends Symbiote {
  componentDescription = async () => {
    return fetch('/api/current-user-context').then(r => r.text());
  };
}

The returned text is appended to every tool description owned by that component, giving agents the situational awareness to make better decisions about which tool to call and when.

Why this integration is better than manual WebMCP

The raw WebMCP browser API requires you to write tool registration and unregistration code yourself, manage tool visibility manually, define input schemas separately from your component logic, and wire tool execution back to your UI state by hand.

With Symbiote.js, you write a component. The framework handles the rest.

• Lifecycle is automatic: tools register when the component mounts, unregister when it unmounts. No memory leaks, no stale tools pointing at destroyed component instances.
• Naming is consistent: tool names are derived from your handler names and custom element tags - the same names already readable in your source and in DevTools.
• State binding is native: ToolDescriptor values live inside component's state`, the same reactive data container your templates already use. Reactivity and tool visibility share the same engine.
• Gradual adoption: mcpToolMode is opt-in per component or globally. Existing apps can adopt WebMCP incrementally without rewriting anything.

Symbiote templates are already built for the agentic era

Here is something worth saying plainly: Symbiote's template model is unusually well-suited for AI-driven UI analysis, and that was true before WebMCP existed.

Most modern component frameworks compile templates into a virtual DOM or opaque render functions. The binding logic disappears into the JavaScript bundle. By the time an agent inspects the live DOM, it sees <div class="btn"> with no indication of what happens when you interact with it.

Symbiote keeps that information in the DOM.

The bind attribute is preserved in the rendered HTML as a regular HTML-attribute on the element. An agent or dev tool inspecting the document can see exactly which handlers are bound to which elements, right in the markup, without source-mapping into a bundle.

Custom element tags add another layer of semantic grounding. <checkout-panel>, <user-card>, <task-list> are meaningful identifiers in the DOM tree - not anonymous <div>s. They tell agents where component boundaries are, what the purpose of a subtree is, and how to navigate a complex page by intent rather than by position.

Combined with WebMCP tool names that embed the custom element tag, this creates a consistent semantic chain from the DOM structure down to the callable tool surface. An agent reading the DOM and an agent browsing available tools are looking at the same conceptual map of the page.

This is what the semantic web promised decades ago, delivered through the mechanics of web components and a reactive template system that respects the document.

About browser support - and why it's the wrong question

WebMCP is an experimental API, available today in Chrome Canary. Broad cross-browser rollout will take time. But limited browser support is not a blocker, and here is why:

WebMCP is not a feature for people. Human users don't see tool names or input schemas. They don't open the browser's MCP tool surface. A page with WebMCP enabled looks and behaves exactly the same to a human as a page without it.

WebMCP is for agents - and agents are not subject to the same adoption curve as human users. An enterprise deploying an AI assistant on top of their web app controls both the agent runtime and the browser environment. MCP support in that toolchain is a deployment decision, not a browser market share question.

The relevant question is not "what percentage of users have a WebMCP-capable browser?" The relevant question is "when my agent needs to operate this UI, does it have a structured interface to work with?" Symbiote gives you that interface today, for the agents and tooling contexts that already support it.

The bigger picture

AI-native UI is not a coming trend - it's a current deployment reality for anyone building enterprise tooling, internal platforms, or AI-assisted workflows. The gap between "this app has an AI assistant" and "this app is deeply navigable by an AI agent" is exactly the gap that WebMCP closes.

Symbiote.js was already aligned with this direction: custom elements as semantic boundaries, bind attributes as visible contracts, reactive state as a single source of truth. WebMCP adds the final layer - a protocol that lets agents interact with that structure using the same vocabulary you used to build it.

Install the experimental release:

npm i @symbiotejs/symbiote@webmcp

WebMCP support is experimental. Browser APIs and tool metadata shape may change as the specification evolves.