| Filename | Latest commit message | Latest commit date |
|---|---|---|
a0dcf16843
The Windows WSL job is the critical path of every CI run (589 to 752 s). Its checkout sits on the Windows drive, which WSL reaches over 9P, and writing node_modules there is what makes npm ci take about three minutes where the Linux job takes 23 s. The step now copies the tree onto the distro's ext4 filesystem before installing and building, as Microsoft's WSL guidance recommends for I/O-heavy work. The e2e job downloaded the full Chromium build (about 165 MB) on every run, but a headless run with no channel launches chromium-headless-shell and never opens it. `--only-shell` skips that download. Every tsconfig now lists the @types packages it uses (node, bun, vite/client, dom-speech-recognition) instead of relying on TypeScript auto-including everything under node_modules/@types. On TypeScript 5.9 this is a no-op: identical diagnostics across all 48 projects and byte-identical emitted .d.ts files. It is a prerequisite for TypeScript 7, which drops the auto-inclusion; with these lists the Go compiler passes all 48 projects, so that upgrade becomes a version bump once TypeDoc supports it. Two cache-based approaches were evaluated and rejected: an npm cache for the WSL job (npm ci is slow there because of 9P, not downloads, and a prefix-restored cache grows without bound) and a Playwright browser cache (Playwright's docs advise against it; the download is under 10 s). |
||
| .. | ||
| src | ||
| .gitignore | ||
| index.html | ||
| package.json | ||
| README.md | ||
| sandbox.html | ||
| serve.ts | ||
| tsconfig.json | ||
| vite.config.ts | ||
Example: Basic Host
A reference implementation showing how to build an MCP host application that connects to MCP servers and renders tool UIs in a secure sandbox.
This basic host can also be used to test MCP Apps during local development.
Key Files
index.html/src/index.tsx- React UI host with tool selection, parameter input, and iframe managementsandbox.html/src/sandbox.ts- Outer iframe proxy with security validation and bidirectional message relaysrc/implementation.ts- Core logic: server connection, tool calling, and AppBridge setup
Getting Started
npm install
npm run start
# Open http://localhost:8080
By default, the host application will try to connect to an MCP server at http://localhost:3001/mcp. You can configure this behavior by setting the SERVERS environment variable with a JSON array of server URLs:
SERVERS='["http://localhost:1234/mcp", "http://localhost:5678/mcp"]' npm run start
Architecture
This example uses a double-iframe sandbox pattern for secure UI isolation:
Host (port 8080)
└── Outer iframe (port 8081) - sandbox proxy
└── Inner iframe (srcdoc) - untrusted tool UI
Why two iframes?
- The outer iframe runs on a separate origin (port 8081) preventing direct access to the host
- The inner iframe receives HTML via
srcdocand is restricted by sandbox attributes - Messages flow through the outer iframe which validates and relays them bidirectionally
This architecture ensures that even if tool UI code is malicious, it cannot access the host application's DOM, cookies, or JavaScript context.