Aeion WebMCP vs Legacy Integrations
Discover why enterprise engineers are abandoning brittle Chrome extensions and vulnerable server-side API keys for natively embedded, session-aware browser agents.
Calculate Your Development Savings
Decisive Architectural Advantages
The End of Hardcoded Secrets
Building a traditional server-side agent requires issuing the LLM an API key. If the LLM provider is compromised or the prompt is manipulated, your entire backend is exposed. Aeion WebMCP executes entirely client-side. The agent uses `aeionFetch`, piggybacking on the user's active JWT token. The agent can literally only do what the user looking at the screen is authorized to do. No secrets are ever stored.
Context is Everything
A Chrome extension relies on scraping the DOM to understand what the user is looking at—a fragile process that breaks on every UI update. With `useAeionTool`, tools are bound to React lifecycles. When a user opens a specific invoice, the component mounts and registers the `pay_invoice` tool with the explicit `invoiceId` trapped in a closure. The agent has mathematically perfect context.
Unified Governance
Trying to rate-limit a rogue Chrome extension requires complex firewall rules. WebMCP enforces rules natively. Intercepts the W3C `navigator.modelContext` pipeline. It checks the user's entitlement array, applies sliding-window `sessionStorage` rate limits, and fires an immutable audit log payload before a single API call is ever made.
Universal Backend Integration
You don't have to sacrifice backend power for frontend safety. The `aeion_backend_mcp_call` proxy acts as an intelligent bridge. It forwards complex JSON-RPC payloads directly from the browser agent to the server-side MCP tools, preserving the user's session identity seamlessly.
Where Server-Side MCP Still Wins — And When to Choose It
WebMCP is the right tool when a human is in the loop with a browser tab open. It is the wrong tool when nobody is. Being honest about that boundary is the whole point:
- No browser, no session. WebMCP inherits the user's live JWT — which means there has to be a live user. Scheduled jobs, backend batch pipelines, server-to-server automation, and anything triggered by a cron or a webhook run with no tab open and no session to inherit. That is server-side MCP's home turf, and Aeion ships a full server MCP surface for exactly this.
- Work that must outlive the tab. A long-running export or a multi-hour reconciliation shouldn't depend on a person keeping a browser window open. Server MCP executes on infrastructure that stays up regardless of who's looking at the screen.
- Heavy compute. Some operations are simply too large to run client-side. Aeion's own answer here isn't "pick one" — the
aeion_backend_mcp_callbridge lets a browser agent forward a JSON-RPC payload to the identical server-side tool, preserving the user's session identity. The two layers are designed to compose, not compete.
And Chrome extensions? They still make sense when you need to act across sites you don't control — automating a third-party SaaS that has no MCP surface of its own. WebMCP is native to _your_ application; it deliberately doesn't reach into other people's pages. If cross-site scraping is the job, an extension is the honest tool for it.
The takeaway isn't that server MCP or extensions are obsolete — it's that pushing in-app, user-scoped actions into the browser removes the standing liability of extruding backend API keys to an LLM for the large class of work where a user is already authenticated and watching.
Frequently Asked Questions
No. WebMCP utilizes the W3C `navigator.modelContext` polyfill. Any modern browser supporting the specification connects directly to the embedded tools via standard URLs.
Absolutely not. WebMCP tools execute inside the browser sandbox. They can only issue standard HTTP requests to your defined `/api/v1/` endpoints, meaning all server-side validation, business logic, and security rules apply perfectly.
No — and it isn't meant to. WebMCP covers in-app actions where a user is authenticated and present; server-side MCP covers headless, scheduled, and heavy-compute work with no browser in the loop. When a browser agent needs backend muscle, the `aeion_backend_mcp_call` bridge forwards the request to the same server-side tool under the user's identity, so you get one consistent tool surface across both.
It's gone from the agent's toolset. Tools are bound to React component lifecycles via `useAeionTool` — a tool registers when its component mounts and unregisters when it unmounts. That's why the agent's context is exact rather than scraped: the `pay_invoice` tool only exists while the invoice it's scoped to is actually on screen, with that `invoiceId` trapped in a closure.
The same authorization layer that stops the user. Every call is intercepted by the `AeionToolRegistry`, which checks the user's entitlement array before dispatch — an agent can't invoke a `finance:write` tool the logged-in user isn't entitled to, no matter what a malicious prompt asks for. Because no API key is ever handed to the LLM, a manipulated agent can only ever do what the person at the keyboard could already do.