Technical One-Pager: Identity‑Scoped Tool Hub
Browser-native WebMCP tools + remote MCP interop, routed through an identity-scoped hub with governance, decision traces, and auditability.
One‑sentence summary
We provide an identity‑scoped Tool Hub that aggregates browser‑native WebMCP tools (deterministic JavaScript functions, not RPA) and remote MCP servers, enabling governed cross‑app workflows without multi‑month backend rewrites.
What we provide
At the edge, we provide an identity‑scoped Tool Hub that keeps policy, routing, and decision traces in one place (with auditability built in). In the session, we provide browser‑native tool execution (WebMCP) so agents can act through the same UI, permissions, and validation users already rely on. Between the two, we provide transports that turn ephemeral browser tabs into stable, routable tool providers.
This is standards‑first by design: MCP for interoperability, WebMCP/Web Model Context for browser‑native tool surfaces, and a clean path to BYO inference.
Terms (quick definitions)
MCP
The Model Context Protocol (MCP) is the interoperability surface: “tools over a transport.” We expose an MCP server surface so customers can bring their own agent host.
Web Model Context API + “WebMCP”
The Web Model Context API is the emerging browser surface for registering tools. WebMCP (our term) is MCP‑style tool registration and execution in the browser where tools are real JavaScript functions inside the host application.
Key point: no eval. Tool invocation is “parse → validate → call a known function.”
MCP‑B runtime (polyfill + interop)
We maintain the runtime + adapters that make browser tool calling usable today across real apps and environments.
Tool Hub (identity‑scoped Durable Object)
A per‑Org/per‑User stateful hub that aggregates tools from connected browser providers and remote MCP servers, exposes a unified MCP endpoint to allowed clients, routes tool calls to the correct execution environment (tab/domain, remote server, etc.), and enforces policy while capturing decision traces.
Embedded agent UI
A user‑facing copilot surface (sidebar/pill/thread UI) that runs at the session boundary, streams chat and tool traces, supports approvals for sensitive actions, and bridges between local tools and the Tool Hub.
AG‑UI
AG‑UI standardizes the event stream between an agent and its UI (messages, tool activity, approvals, UI state), keeping the UI and agent backend cleanly decoupled.
Architecture (mental model)
Design principles
Tool execution lives with the software: deterministic tools in the host app (not DOM scraping). State and governance live in the Tool Hub, scoped per identity rather than per tab. Interoperability is a first‑class requirement—MCP in and out, plus browser‑native tool calling. There are no “eval agents”: tools are declared, schema‑validated, and invoked as function calls. And we build standards‑first to avoid lock‑in in a fast‑moving ecosystem.
Core flows
Tool registration
Tool registration starts in the host app, where tools are defined with a name, schema, and handler. The embedded runtime then discovers the tool surface in the current session and publishes tools and provider metadata to the Tool Hub. The hub merges these into a unified registry for the user, including source selection when the same tool exists in multiple connected contexts.
Tool invocation (remote agent calls a browser tool)
When an MCP client calls a tool, it calls the Tool Hub MCP interface—not a specific tab. The hub selects the correct tool provider (specific tab/domain/source), routes the invocation to that provider, and receives a structured result. That result propagates back through the hub to the caller, with decision trace metadata governed by policy.
Cross‑app interoperability (Tab A uses Tab B tools)
Cross‑app interoperability uses the same mechanism, except the caller can be an embedded copilot in one app while the tool provider is a different app/tab. Identity is the tunnel that makes cross‑domain routing possible without forcing the apps to integrate with each other directly.
Security + governance (enterprise posture)
Security starts with deterministic execution: there is no code-injection requirement, no eval, and tool inputs are schema-validated. We assume a hostile web (XSS, compromised scripts, prompt injection) and focus on limiting blast radius and making unsafe outcomes hard to execute.
Trust boundaries (who executes vs who orchestrates)
The host app is the privileged executor that can touch the DOM and session state. The embedded runtime is a bridge that requests actions over an explicit RPC channel and should not inherit host privileges. The Tool Hub is the policy and state authority; remote MCP servers are external dependencies that must be explicitly authorized. Inference endpoints are treated as potential exfil paths unless policy allows them.
Controls by layer
Host tool surface: deterministic JS handlers with explicit schemas, no eval, and reuse of UI validation for writes.
Host ↔ runtime: hardened postMessage RPC with origin allowlists, targetOrigin, message schema validation, and a per-session handshake.
Runtime ↔ hub: authenticated WebSocket bound to org/user identity, provider IDs for routing, and rate limits.
Tool Hub: identity-scoped isolation, policy gating (read/write/exfil), approvals for sensitive actions, decision traces, and a kill switch.
Remote MCP OAuth: auth code with PKCE, minimal scopes mapped to tools, refresh tokens stored only in the hub, and revocation/rotation support.
Inference boundary: policy-controlled data flow, redaction when required, and support for customer-hosted inference.
Decision traces are not just trajectory logs. They are meant to preserve why something happened at decision time, not only that it happened, so teams can replay, debug, and learn from real operations.
DecisionTrace (simple shape)
Identifying intent to call refund.create for order #123.
Refund amount ($450.00) exceeds the auto-approval threshold of $100.00. Escalating to human reviewer.
Reviewer granted a one-time exception for this transaction.
Tool execution completed successfully. Side effect recorded in ledger.
Deployment + inference options
Enterprises can roll out via an SDK/snippet for production hardening, use a browser extension for fast pilots, or combine both. Inference can be hosted or bring‑your‑own (cloud, VPC, on‑prem), with routing governed by policy so sensitive contexts can remain inside approved boundaries.
What’s implemented vs roadmap
Implemented (today)
Today, WebMCP tools can be registered and executed inside the browser session, and the identity‑scoped Tool Hub can aggregate tools across tabs/domains and remote MCP servers into a single ToolList. Tool calls can be routed back to the right provider (tab or remote server), with human‑in‑loop approvals for sensitive actions. Remote MCP interop works over Streamable HTTP (with SSE fallback).
Near‑term roadmap
Next, the focus is a policy editor and approval workflows, hardened decision trace exports (SIEM) and redaction rules, and an unattended execution mode (“cloud browser worker”) built around re‑authentication instead of cookie copying.