eventOS over WebMCP

Inspiration

The events industry runs on real-time chaos — vendor SLA breaches at 2am, exhibitor no-shows, P&L that shifts by the hour. eventOS already had a five-agent AI fleet handling this: BookingAgent, InsightAgent, CommsAgent, VendorAgent, ComplianceAgent — running on Cloud Run for IMEX America (October 2026, 6,100+ buyers, 3,700+ exhibitors).

The question was: what if any AI assistant could drive that fleet directly from the browser, with zero integration work? No API key, no OAuth flow, no server the agent has to be configured with. Browser-native MCP (WebMCP) makes that possible. The page the agent is already looking at tells it what it can do.

What it does

eventOS over WebMCP publishes six event-operations tools directly on document.modelContext — discoverable by any AI assistant driving the browser the moment the page loads:

Open the live page in ChatGPT's in-app browser or Chrome with WebMCP enabled. Ask: "What tools does this page offer?" — the agent discovers all six. Ask: "What's at risk for IMEX?" — it calls check_vendor_status and get_event_sentiment and tells you. No credentials. No setup.

Every result carries a source field — live:eventos-agent-fleet, venueSource, or catalog — so an agent can distinguish a number measured by the live fleet from one produced by a model.

How we built it

WebMCP surface layer (web/lib/webmcp.ts): The hardest part. document.modelContext is new enough that Chrome 146 shipped it on navigator.modelContext, the W3C explainer writes it as document.modelContext, and earlier drafts used window.agent. Our code registers against every surface that exists and deduplicates by object identity — a browser that aliases one object onto both would otherwise get two registration passes and throw on every duplicate tool name.

For browsers with no WebMCP host, a branded shim goes on document.modelContext so the page's own inline runner still works and the detector never mistakes our stand-in for a real host. The page reports native: false and "shim active" rather than claiming support it doesn't have.

The host can also attach after mount — agentic browsers may inject modelContext well after React renders. The page watches for 60 seconds post-load, polling twice a second plus on visibilitychange and focus, and registers the moment it appears.

The fleet underneath (api/mcp_server.py): Five Google ADK agents, 12 tools, already running on Cloud Run. The MCP server is a protocol skin over their existing Python functions — no agent logic reimplemented. An MCP server is not a rewrite; it's a way to let any model in any client drive software you already shipped.

MCP console (/console): A genuine MCP client — not a REST wrapper. On load it runs initialize, discovers tools with tools/list, and renders argument forms generated from each tool's JSON Schema. Every button issues a real tools/call. Every message is recorded in a JSON-RPC wire log with method, latency, and full request/response envelopes.

Stack: Python 3.12 · FastAPI · Google ADK · Gemini · Cloud Run · Next.js 16 · React 19 · TypeScript · Vercel · WebMCP (document.modelContext)

Challenges we ran into

The WebMCP surface fragmentation was the core engineering challenge. Three different object paths across browser versions, all claiming to be the standard, with no event for when a modelContext appears after mount. We had to build a detection loop, deduplicate registrations by object identity, and design a shim that is honest about its own limitations.

Tool schema design mattered more than expected. Tools returning isError: true in the result (not a thrown exception) let agents recover instead of dead-ending. The source field on every result lets an agent tell live data from catalog data and say so. readOnlyHint: true annotations on all six tools let a host call them without a confirmation prompt — critical for a snappy demo.

Accomplishments that we're proud of

• 6 WebMCP tools live and registered on a production event-operations platform
• 5-agent fleet on Cloud Run with 12 tools, accessible over Streamable HTTP MCP
• 42-test conformance suite — all passing — covering handshake, version negotiation, all 12 tools, every JSON-RPC error code, SSE framing, CORS, and session teardown
• Surface detection that works in Chrome 146 today and the standardized browser later, without a code change
• A genuine MCP client (/console) with full wire-log visibility — the entire protocol lifecycle inspectable, not just claimed

What we learned

Browser-native MCP inverts the integration model in a way that matters. The agent doesn't need to be configured with anything — it discovers what the page can do by looking at it. That makes WebMCP a better fit for high-stakes, session-scoped contexts like live events than server MCP: tools are automatically scoped to the event currently loaded, credentials stay in the user's session, and an AI assistant gains live operational access to a running event with zero setup.

Gemini-backed tools (fleet_architect_design) inside a WebMCP surface work naturally — the AI driving the browser can ask the page to design a bespoke agent roster, and the page reaches back into the fleet to do it.

What's next for eventOS over WebMCP

The WebMCP bridge layer (web/lib/webmcp.ts + webmcp-tools.ts) is designed to be lifted out as a standalone library — any Next.js or React app should be able to register MCP tools in a few lines. We'll open that as a separate package.

For eventOS: more live tools, tighter integration between the fleet and the page, and WebMCP as the primary interface for on-site AI assistance at IMEX America, October 12–15 2026. The goal is an event operations room where any AI assistant a planner is already using can walk up to the dashboard and immediately know what's happening and what to do about it.

Built With

• fastapi
• javascript
• model-context-protocol
• next.js
• python
• react
• typescript
• vercel
• webmcp