The Problem With Traditional Integrations
Before Char, connecting applications required:- Building API integrations between each pair of systems
- Managing service accounts with elevated permissions
- Handling authentication flows for each connection
- Maintaining synchronization between systems
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
“Find the invoice for Acme Corp and add the status to their CRM record, then email their account manager.”The agent can now:
- Call
erp.lookupInvoice({ customer: "Acme Corp" }) - Call
crm.updateLead({ company: "Acme Corp", invoiceStatus: "Paid" }) - Call
mail.sendEmail({ to: "[email protected]", subject: "Acme update" })
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 Message Flow
When an agent invokes a cross-app tool, the request traverses multiple boundaries:- Agent sends tool call to the Tool Hub
- Hub routes via WebSocket to the correct browser tab
- The embedded iframe forwards via
postMessageto the host page - The host page executes the tool with the user’s session
- Results return up the chain
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
Namespace Collision Prevention
Tools from different domains are namespaced automatically:| Source Domain | Tool Name | In Registry |
|---|---|---|
| crm.company.com | search | crm.search |
| erp.company.com | search | erp.search |
| docs.company.com | search | docs.search |
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
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 samesub 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

