Skip to main content
Char’s defining capability is cross-application tool access. Tools registered in one application are available to agents in every other application—all scoped to the authenticated user.

The Problem With Traditional Integrations

Before Char, connecting applications required:
  1. Building API integrations between each pair of systems
  2. Managing service accounts with elevated permissions
  3. Handling authentication flows for each connection
  4. Maintaining synchronization between systems
Adding N applications meant O(N²) integration work.

Char’s Approach

With Char, each application registers tools with the user’s Tool Hub. The Hub aggregates tools into a unified registry: Now any agent connected to the Hub can invoke tools from any source.

Example: Cross-App Workflow

A user has three tabs open:
  • CRM — with updateLead(), getContact() tools
  • ERP — with lookupInvoice(), createOrder() tools
  • Email — with sendEmail(), searchInbox() tools
The user asks the embedded agent:
“Find the invoice for Acme Corp and add the status to their CRM record, then email their account manager.”
The agent can now:
  1. Call erp.lookupInvoice({ customer: "Acme Corp" })
  2. Call crm.updateLead({ company: "Acme Corp", invoiceStatus: "Paid" })
  3. Call mail.sendEmail({ to: "[email protected]", subject: "Acme update" })
This is cross-site RPC—previously impossible without building custom integrations.

Architecture

Why Browser-Based Execution?

A key design decision: tools execute in the browser, not on a server. This means:
  • No credential storage — The browser already has the user’s session
  • No proxy layer — Direct API calls with existing cookies
  • Instant permission reflection — If the user loses access, so does the agent
The alternative—server-side execution—would require storing credentials, managing token refresh, and building an OAuth layer for each integration.

The Message Flow

When an agent invokes a cross-app tool, the request traverses multiple boundaries:
  1. Agent sends tool call to the Tool Hub
  2. Hub routes via WebSocket to the correct browser tab
  3. The embedded iframe forwards via postMessage to the host page
  4. The host page executes the tool with the user’s session
  5. Results return up the chain
This architecture means the Tool Hub never sees sensitive data—it only routes messages. The actual API calls happen in the browser with the user’s credentials.
For implementation details, see the WebMCP Tools guide.

User Scoping

Tools are scoped to the authenticated user, not the application:
  • User A’s tools are isolated from User B’s tools
  • Tools execute with User A’s permissions
  • If User A logs out, their tools are no longer available
This means agents inherit the user’s existing access—no elevated service accounts needed.

Namespace Collision Prevention

Tools from different domains are namespaced automatically:
Source DomainTool NameIn Registry
crm.company.comsearchcrm.search
erp.company.comsearcherp.search
docs.company.comsearchdocs.search
The agent sees distinct tools and can choose which to invoke.

External MCP Clients

The same cross-app tool surface is available to any MCP client:
  • Claude Desktop can invoke browser tools
  • VS Code extensions can access the unified registry
  • Cloud automation workers can execute workflows
All clients connect to the same Tool Hub and see the same aggregated tools.

Prerequisites

Cross-app tools depend on two architectural elements: Identity continuity — All applications must authenticate the same user identity. The Tool Hub is scoped to a user ID, so tools from app A are only available to app B if both recognize the same sub claim. This is why Char uses your existing identity provider rather than creating a separate identity system. Hub connectivity — The embedded agent must connect to the Tool Hub, which requires Tier 1+ deployment. Page-scoped mode (Tier 0) operates without network connectivity and cannot participate in cross-app workflows.

Security Considerations

Cross-app access is governed by policy enforcement:
  • Tools are classified (read/write/exfil)
  • Approval workflows can require user confirmation
  • Role-based visibility controls which tools agents can see
  • All invocations are logged in decision traces

Further Reading