ext-apps/examples/basic-host
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Olivier Chafik 2dd223b611
refactor: rename request methods to remove send prefix (#161)
* refactor: rename request methods to remove send prefix

Following the MCP TS SDK convention where request methods don't have
the "send" prefix (reserved for notifications):

- App.sendMessage() → App.message()
- App.sendOpenLink() → App.openLink()
- AppBridge.sendResourceTeardown() → AppBridge.resourceTeardown()

The old method names are kept as deprecated aliases for backwards
compatibility.

Updated all examples to use the new method names.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* test: add tests for deprecated method aliases

- Update existing tests to use new method names (message, openLink)
- Add tests verifying deprecated aliases are same reference as new methods
- Add tests verifying deprecated aliases still work functionally

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* refactor: rename message→sendMessage, resourceTeardown→teardownResource

- App.message() → App.sendMessage() (with deprecated message alias)
- AppBridge.resourceTeardown() → AppBridge.teardownResource() (with deprecated aliases)

This better follows the pattern where methods that send data have 'send' or action verb prefix.

* fix: update examples to use sendMessage instead of message

* fix: update basic-host to use teardownResource

* fix: update threejs-server to use sendMessage

* refactor: remove deprecated app.message alias

The app.message alias was removed since sendMessage is the correct name.
sendResourceTeardown already exists in AppBridge.

* refactor: remove resourceTeardown alias, keep only sendResourceTeardown

---------

Co-authored-by: Claude <noreply@anthropic.com>
2025-12-16 22:07:06 +00:00
..
src refactor: rename request methods to remove send prefix (#161) 2025-12-16 22:07:06 +00:00
index.html Add color-scheme meta tag to all example apps 2025-12-15 11:42:18 -08:00
package.json fix: Windows compatibility - bun as optional dep, cross-env for examples (#145) 2025-12-16 14:07:38 +00:00
README.md Smoothen the process of getting started (#103) 2025-12-09 16:15:32 +01:00
sandbox.html Add color-scheme meta tag to all example apps 2025-12-15 11:42:18 -08:00
serve.ts Smoothen the process of getting started (#103) 2025-12-09 16:15:32 +01: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.