ext-apps/examples/basic-host
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Olivier Chafik 8a877b36b4
feat(debug-server): add interactive debug server example (#321)
* feat(examples): add debug-server example

A comprehensive debug/development server for testing MCP Apps SDK features:
- Vanilla TypeScript UI with collapsible panels
- Message visualization (sent, received, errors)
- Server tool calling interface
- Multiple tool endpoints for testing

* refactor(debug-server): convert to React

- Replace vanilla TypeScript with React components
- Add comprehensive Host Styles panel showing all CSS variables grouped by category
- Use React hooks (useApp, useHostStyles, useAutoResize)
- Cleaner state management with useReducer for event log
- Collapsible sections for better organization
- CSS modules for scoped styling

* fix(debug-server): correct server name in main.ts

* Revert "refactor(debug-server): convert to React"

This reverts commit 5d22d2daa9a98ba412892447202ef10fbdb62f5b.

* fix(debug-server): update default values for multipleBlocks and includeMeta

* fix(debug-server): correct serve script and server name

- serve script now runs main.ts instead of server.ts
- Updated server name to 'Debug Server'
- Fixed npx command in comment

* fix: increase maxHeight to 6000px and add tools capability to debug app

- basic-host: Increase maxHeight from 600 to 6000px
- debug-server: Add tools capability to enable oncalltool/onlisttools handlers

* fix(debug-server): use consistent callback names for event tracking

Event types now match callback names (ontoolinput, ontoolresult, etc.)
so the Callback Status panel shows correct counts and payloads.

* feat(debug-server): add Update (Image) button for model context

* feat(debug-server): add expandable event log entries

- Click on any event log row to expand/collapse
- Arrow indicator rotates when expanded
- Full JSON payload shown indented in pre block
- Max height with scroll for large payloads

* style(debug-server): format long line in fullPayload function

* test(debug-server): add to E2E tests and screenshot specs

* chore: regenerate package-lock.json for cross-platform compatibility

* update dep
2026-01-23 12:39:40 +00:00
..
src feat(debug-server): add interactive debug server example (#321) 2026-01-23 12:39:40 +00:00
.gitignore Improve consistency and organization of examples for AI learning 2026-01-13 20:48:02 -06:00
index.html Add color-scheme meta tag to all example apps 2025-12-15 11:42:18 -08:00
package.json chore: bump version to 0.4.1 (#282) 2026-01-15 16:11:53 +00:00
README.md Smoothen the process of getting started (#103) 2025-12-09 16:15:32 +01:00
sandbox.html fix: proper CSP handling in basic-host sandboxing (HTTP headers, worker-src, document.write) (#234) 2026-01-11 14:32:48 +00:00
serve.ts fix: proper CSP handling in basic-host sandboxing (HTTP headers, worker-src, document.write) (#234) 2026-01-11 14:32:48 +00:00
tsconfig.json Add basic-host and basic-server-react examples 2025-12-04 14:28:27 -06:00
vite.config.ts Add basic-host and basic-server-react examples 2025-12-04 14:28:27 -06:00

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

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 srcdoc and 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.