| 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 | ||
| grid-cell.png | ||
| main.ts | ||
| mcp-app.html | ||
| package.json | ||
| README.md | ||
| screenshot.png | ||
| server.ts | ||
| tsconfig.json | ||
| tsconfig.server.json | ||
| vite.config.ts | ||
Example: Basic Server (React)
An MCP App example with a React UI.
Tip
Looking for a vanilla JavaScript example? See
basic-server-vanillajs!
MCP Client Configuration
Add to your MCP client configuration (stdio transport):
{
"mcpServers": {
"basic-react": {
"command": "npx",
"args": [
"-y",
"--silent",
"--registry=https://registry.npmjs.org/",
"@modelcontextprotocol/server-basic-react",
"--stdio"
]
}
}
}
Local Development
To test local modifications, use this configuration (replace ~/code/ext-apps with your clone path):
{
"mcpServers": {
"basic-react": {
"command": "bash",
"args": [
"-c",
"cd ~/code/ext-apps/examples/basic-server-react && npm run build >&2 && node dist/index.js --stdio"
]
}
}
}
Overview
- Tool registration with a linked UI resource
- React UI using the
useApp()hook - App communication APIs:
callServerTool,sendMessage,sendLog,openLink
Key Files
server.ts- MCP server with tool and resource registrationmcp-app.html/src/mcp-app.tsx- React UI usinguseApp()hook
Getting Started
npm install
npm run dev
How It Works
- The server registers a
get-timetool with metadata linking it to a UI HTML resource (ui://get-time/mcp-app.html). - When the tool is invoked, the Host renders the UI from the resource.
- The UI uses the MCP App SDK API to communicate with the host and call server tools.
Build System
This example bundles into a single HTML file using Vite with vite-plugin-singlefile — see vite.config.ts. This allows all UI content to be served as a single MCP resource. Alternatively, MCP apps can load external resources by defining _meta.ui.csp.resourceDomains in the UI resource metadata.