mirror of
https://github.com/anthropics/claude-plugins-official.git
synced 2026-03-19 23:23:07 +00:00
add(plugin): mcp-server-dev — skills for building MCP servers
Three skills guiding developers through MCP server design: - build-mcp-server: entry-point decision guide (remote HTTP vs MCPB vs local) - build-mcp-app: interactive UI widgets rendered in chat - build-mcpb: bundled local servers with runtime Includes reference files for scaffolds, tool design, auth (DCR/CIMD), widget templates, manifest schema, and local security hardening.
This commit is contained in:
Tobin South
199
plugins/mcp-server-dev/skills/build-mcp-app/SKILL.md
Normal file
199
plugins/mcp-server-dev/skills/build-mcp-app/SKILL.md
Normal file
@@ -0,0 +1,199 @@
|
||||
---
|
||||
name: build-mcp-app
|
||||
description: This skill should be used when the user wants to build an "MCP app", add "interactive UI" or "widgets" to an MCP server, "render components in chat", build "MCP UI resources", make a tool that shows a "form", "picker", "dashboard" or "confirmation dialog" inline in the conversation, or mentions "apps SDK" in the context of MCP. Use AFTER the build-mcp-server skill has settled the deployment model, or when the user already knows they want UI widgets.
|
||||
version: 0.1.0
|
||||
---
|
||||
|
||||
# Build an MCP App (Interactive UI Widgets)
|
||||
|
||||
An MCP app is a standard MCP server that **also serves UI resources** — interactive components rendered inline in the chat surface. Build once, runs in Claude *and* ChatGPT and any other host that implements the apps surface.
|
||||
|
||||
The UI layer is **additive**. Under the hood it's still tools, resources, and the same wire protocol. If you haven't built a plain MCP server before, the `build-mcp-server` skill covers the base layer. This skill adds widgets on top.
|
||||
|
||||
---
|
||||
|
||||
## When a widget beats plain text
|
||||
|
||||
Don't add UI for its own sake — most tools are fine returning text or JSON. Add a widget when one of these is true:
|
||||
|
||||
| Signal | Widget type |
|
||||
|---|---|
|
||||
| Tool needs structured input Claude can't reliably infer | Form |
|
||||
| User must pick from a list Claude can't rank (files, contacts, records) | Picker / table |
|
||||
| Destructive or billable action needs explicit confirmation | Confirm dialog |
|
||||
| Output is spatial or visual (charts, maps, diffs, previews) | Display widget |
|
||||
| Long-running job the user wants to watch | Progress / live status |
|
||||
|
||||
If none apply, skip the widget. Text is faster to build and faster for the user.
|
||||
|
||||
---
|
||||
|
||||
## Architecture: two deployment shapes
|
||||
|
||||
### Remote MCP app (most common)
|
||||
|
||||
Hosted streamable-HTTP server. Widget templates are served as **resources**; tool results reference them. The host fetches the resource, renders it in an iframe sandbox, and brokers messages between the widget and Claude.
|
||||
|
||||
```
|
||||
┌──────────┐ tools/call ┌────────────┐
|
||||
│ Claude │─────────────> │ MCP server │
|
||||
│ host │<── result ────│ (remote) │
|
||||
│ │ + widget ref │ │
|
||||
│ │ │ │
|
||||
│ │ resources/read│ │
|
||||
│ │─────────────> │ widget │
|
||||
│ ┌──────┐ │<── template ──│ HTML/JS │
|
||||
│ │iframe│ │ └────────────┘
|
||||
│ │widget│ │
|
||||
│ └──────┘ │
|
||||
└──────────┘
|
||||
```
|
||||
|
||||
### MCPB-packaged MCP app (local + UI)
|
||||
|
||||
Same widget mechanism, but the server runs locally inside an MCPB bundle. Use this when the widget needs to drive a **local** application — e.g., a file picker that browses the actual local disk, a dialog that controls a desktop app.
|
||||
|
||||
For MCPB packaging mechanics, defer to the **`build-mcpb`** skill. Everything below applies to both shapes.
|
||||
|
||||
---
|
||||
|
||||
## How widgets attach to tools
|
||||
|
||||
A tool declares a widget by returning an **embedded resource** in its result alongside (or instead of) text content. The resource's `mimeType` tells the host to render it, and the `text` field carries the widget's HTML.
|
||||
|
||||
```typescript
|
||||
server.tool(
|
||||
"pick_contact",
|
||||
"Open an interactive contact picker. The user selects one contact; its ID is returned.",
|
||||
{
|
||||
filter: z.string().optional().describe("Optional name/email prefix filter"),
|
||||
},
|
||||
async ({ filter }) => {
|
||||
const contacts = await listContacts(filter);
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "resource",
|
||||
resource: {
|
||||
uri: "ui://widgets/contact-picker",
|
||||
mimeType: "text/html+skybridge",
|
||||
text: renderContactPicker(contacts),
|
||||
},
|
||||
},
|
||||
],
|
||||
};
|
||||
},
|
||||
);
|
||||
```
|
||||
|
||||
The host renders the resource in a sandboxed iframe. The widget posts a message back when the user picks something; the host injects that result into the conversation so Claude can continue.
|
||||
|
||||
---
|
||||
|
||||
## Widget runtime contract
|
||||
|
||||
Widgets run in a sandboxed iframe. They talk to the host via `window.parent.postMessage` with a small set of message types. The exact envelope is host-defined — the MCP apps SDK wraps it so you don't hand-roll `postMessage`.
|
||||
|
||||
**What widgets can do:**
|
||||
- Render arbitrary HTML/CSS/JS (sandboxed — no same-origin access to the host page)
|
||||
- Receive an initial `data` payload from the tool result
|
||||
- Post a **result** back (ends the interaction, value flows to Claude)
|
||||
- Post **progress** updates (for long-running widgets)
|
||||
- Request the host **call another tool** on the same server
|
||||
|
||||
**What widgets cannot do:**
|
||||
- Access the host page's DOM, cookies, or storage
|
||||
- Make network calls to origins other than your MCP server (CSP-restricted)
|
||||
- Persist state across renders (each tool call is a fresh iframe)
|
||||
|
||||
Keep widgets **small and single-purpose**. A picker picks. A form submits. Don't build a whole sub-app inside the iframe — split it into multiple tools with focused widgets.
|
||||
|
||||
---
|
||||
|
||||
## Scaffold: minimal form widget
|
||||
|
||||
**Tool (TypeScript SDK):**
|
||||
|
||||
```typescript
|
||||
import { renderWidget } from "./widgets";
|
||||
|
||||
server.tool(
|
||||
"create_ticket",
|
||||
"Open a form to create a support ticket. User fills in title, priority, and description.",
|
||||
{},
|
||||
async () => ({
|
||||
content: [
|
||||
{
|
||||
type: "resource",
|
||||
resource: {
|
||||
uri: "ui://widgets/create-ticket",
|
||||
mimeType: "text/html+skybridge",
|
||||
text: renderWidget("create-ticket", {
|
||||
priorities: ["low", "medium", "high", "urgent"],
|
||||
}),
|
||||
},
|
||||
},
|
||||
],
|
||||
}),
|
||||
);
|
||||
```
|
||||
|
||||
**Widget template (`widgets/create-ticket.html`):**
|
||||
|
||||
```html
|
||||
<!doctype html>
|
||||
<meta charset="utf-8" />
|
||||
<style>
|
||||
body { font: 14px system-ui; margin: 12px; }
|
||||
label { display: block; margin-top: 8px; font-weight: 500; }
|
||||
input, select, textarea { width: 100%; padding: 6px; margin-top: 2px; }
|
||||
button { margin-top: 12px; padding: 8px 16px; }
|
||||
</style>
|
||||
<form id="f">
|
||||
<label>Title <input name="title" required /></label>
|
||||
<label>Priority
|
||||
<select name="priority">
|
||||
{{#each priorities}}<option>{{this}}</option>{{/each}}
|
||||
</select>
|
||||
</label>
|
||||
<label>Description <textarea name="description" rows="4"></textarea></label>
|
||||
<button type="submit">Create</button>
|
||||
</form>
|
||||
<script type="module">
|
||||
import { submit } from "https://esm.sh/@modelcontextprotocol/apps-sdk";
|
||||
document.getElementById("f").addEventListener("submit", (e) => {
|
||||
e.preventDefault();
|
||||
const data = Object.fromEntries(new FormData(e.target));
|
||||
submit(data); // → flows back to Claude as the tool's result
|
||||
});
|
||||
</script>
|
||||
```
|
||||
|
||||
`renderWidget` is a ~10-line template function — see `references/widget-templates.md`.
|
||||
|
||||
---
|
||||
|
||||
## Design notes that save you a rewrite
|
||||
|
||||
**One widget per tool.** Resist the urge to build one mega-widget that does everything. One tool → one focused widget → one clear result shape. Claude reasons about these far better.
|
||||
|
||||
**Tool description must mention the widget.** Claude only sees the tool description when deciding what to call. "Opens an interactive picker" in the description is what makes Claude reach for it instead of guessing an ID.
|
||||
|
||||
**Widgets are optional at runtime.** Hosts that don't support the apps surface fall back to showing the resource as a link or raw text. Your tool should still return something sensible in `content[].text` alongside the widget for that case.
|
||||
|
||||
**Don't block on widget results for read-only tools.** A widget that just *displays* data (chart, preview) shouldn't require a user action to complete. Return the display widget *and* a text summary in the same result so Claude can continue reasoning without waiting.
|
||||
|
||||
---
|
||||
|
||||
## Testing
|
||||
|
||||
- **Local:** point Claude desktop's MCP config at `http://localhost:3000/mcp`, trigger the tool, check the widget renders and submits.
|
||||
- **Host fallback:** disable the apps surface (or use a host without it) and confirm the tool degrades gracefully.
|
||||
- **CSP:** open browser devtools on the iframe — CSP violations are the #1 reason widgets silently fail.
|
||||
|
||||
---
|
||||
|
||||
## Reference files
|
||||
|
||||
- `references/widget-templates.md` — reusable HTML scaffolds for form / picker / confirm / progress
|
||||
- `references/apps-sdk-messages.md` — the `postMessage` protocol between widget and host
|
||||
@@ -0,0 +1,99 @@
|
||||
# Apps SDK — Widget ↔ Host Message Protocol
|
||||
|
||||
Widgets communicate with the MCP host through `window.parent.postMessage`. The apps SDK wraps this in helpers so you rarely touch the raw envelope, but knowing the shape helps when debugging.
|
||||
|
||||
---
|
||||
|
||||
## Widget → host
|
||||
|
||||
### `submit(result)`
|
||||
|
||||
Ends the interaction. `result` is returned to Claude as the tool's output (serialized to JSON). The iframe is torn down after this fires.
|
||||
|
||||
```js
|
||||
import { submit } from "@modelcontextprotocol/apps-sdk";
|
||||
submit({ id: "usr_abc123", action: "selected" });
|
||||
```
|
||||
|
||||
Raw envelope:
|
||||
```json
|
||||
{ "type": "mcp:result", "result": { "id": "usr_abc123", "action": "selected" } }
|
||||
```
|
||||
|
||||
### `callTool(name, args)`
|
||||
|
||||
Ask the host to invoke **another tool on the same server** and return the result to the widget. Use for widgets that need to fetch more data after initial render (pagination, drill-down).
|
||||
|
||||
```js
|
||||
import { callTool } from "@modelcontextprotocol/apps-sdk";
|
||||
const page2 = await callTool("list_items", { offset: 20, limit: 20 });
|
||||
```
|
||||
|
||||
Round-trips through the host, so it's slower than embedding all data upfront. Only use when the full dataset is too large to ship in the initial payload.
|
||||
|
||||
### `resize(height)`
|
||||
|
||||
Tell the host the widget's content height so the iframe can be sized. The SDK auto-calls this on load via `ResizeObserver`; call manually only if your content height changes after an async operation.
|
||||
|
||||
---
|
||||
|
||||
## Host → widget
|
||||
|
||||
### Initial data
|
||||
|
||||
The widget's initial payload is **not** a message — it's baked into the HTML by the server (the `__DATA__` substitution pattern). This avoids a round-trip and works even if the message channel is slow to establish.
|
||||
|
||||
### `onMessage(handler)`
|
||||
|
||||
Subscribe to pushes from the server. Used by progress widgets and anything live-updating.
|
||||
|
||||
```js
|
||||
import { onMessage } from "@modelcontextprotocol/apps-sdk";
|
||||
onMessage((msg) => {
|
||||
if (msg.type === "progress") updateBar(msg.percent);
|
||||
});
|
||||
```
|
||||
|
||||
Server side (TypeScript SDK), push via the notification stream keyed to the tool call's request context. The SDK exposes this as a `notify` callback on the tool handler:
|
||||
|
||||
```typescript
|
||||
server.tool("long_job", "...", schema, async (args, { notify }) => {
|
||||
for (let i = 0; i <= 100; i += 10) {
|
||||
await step();
|
||||
notify({ type: "progress", percent: i, label: `Step ${i / 10}/10` });
|
||||
}
|
||||
return { content: [...] };
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Lifecycle
|
||||
|
||||
```
|
||||
1. Claude calls tool
|
||||
2. Server returns content with embedded resource (mimeType: text/html+skybridge)
|
||||
3. Host renders resource text in sandboxed iframe
|
||||
4. Widget hydrates from inline __DATA__
|
||||
5. (optional) Widget ↔ host messages: callTool, progress pushes
|
||||
6. Widget calls submit(result)
|
||||
7. Host tears down iframe, injects result into conversation
|
||||
8. Claude continues with the result
|
||||
```
|
||||
|
||||
If step 6 never happens (user closes the widget, host times out), the tool call resolves with a cancellation result. Your tool description should account for this — "Returns the selected ID, or null if the user cancels."
|
||||
|
||||
---
|
||||
|
||||
## CSP gotchas
|
||||
|
||||
The iframe sandbox enforces a strict Content Security Policy. Common failures:
|
||||
|
||||
| Symptom | Cause | Fix |
|
||||
|---|---|---|
|
||||
| Widget renders but JS doesn't run | Inline script blocked | Use `<script type="module">` with SDK import; avoid inline event handlers in HTML attributes |
|
||||
| `fetch()` fails silently | Cross-origin blocked | Route through `callTool()` instead |
|
||||
| External CSS doesn't load | `style-src` restriction | Inline your styles in a `<style>` tag |
|
||||
| Fonts don't load | `font-src` restriction | Use system fonts (`font: 14px system-ui`) |
|
||||
|
||||
When in doubt, open the iframe's devtools console — CSP violations log there.
|
||||
@@ -0,0 +1,140 @@
|
||||
# Widget Templates
|
||||
|
||||
Minimal HTML scaffolds for the common widget shapes. Copy, fill in, ship.
|
||||
|
||||
All templates assume the apps-SDK helper is available at an ESM CDN. They're intentionally framework-free — widgets render in a fresh iframe each time, so React/Vue hydration cost usually isn't worth it for something this small.
|
||||
|
||||
---
|
||||
|
||||
## The render helper
|
||||
|
||||
Ten lines of string templating. Good enough for almost every case.
|
||||
|
||||
```typescript
|
||||
import { readFileSync } from "node:fs";
|
||||
import { join } from "node:path";
|
||||
|
||||
const TEMPLATE_DIR = join(import.meta.dirname, "../widgets");
|
||||
|
||||
export function renderWidget(name: string, data: unknown): string {
|
||||
const tpl = readFileSync(join(TEMPLATE_DIR, `${name}.html`), "utf8");
|
||||
return tpl.replace(
|
||||
"__DATA__",
|
||||
JSON.stringify(data).replace(/</g, "\\u003c"),
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Every template below hydrates from `<script id="data">__DATA__</script>`. The `<` escape prevents `</script>` injection.
|
||||
|
||||
---
|
||||
|
||||
## Picker (single-select list)
|
||||
|
||||
```html
|
||||
<!doctype html>
|
||||
<meta charset="utf-8" />
|
||||
<script id="data" type="application/json">__DATA__</script>
|
||||
<style>
|
||||
body { font: 14px system-ui; margin: 0; }
|
||||
ul { list-style: none; padding: 0; margin: 0; max-height: 280px; overflow-y: auto; }
|
||||
li { padding: 10px 14px; cursor: pointer; border-bottom: 1px solid #eee; }
|
||||
li:hover { background: #f5f5f5; }
|
||||
.sub { color: #666; font-size: 12px; }
|
||||
</style>
|
||||
<ul id="list"></ul>
|
||||
<script type="module">
|
||||
import { submit } from "https://esm.sh/@modelcontextprotocol/apps-sdk";
|
||||
const { items } = JSON.parse(document.getElementById("data").textContent);
|
||||
const ul = document.getElementById("list");
|
||||
for (const it of items) {
|
||||
const li = document.createElement("li");
|
||||
li.innerHTML = `<div>${it.label}</div><div class="sub">${it.sub ?? ""}</div>`;
|
||||
li.onclick = () => submit({ id: it.id });
|
||||
ul.append(li);
|
||||
}
|
||||
</script>
|
||||
```
|
||||
|
||||
**Data shape:** `{ items: [{ id, label, sub? }] }`
|
||||
**Result shape:** `{ id }`
|
||||
|
||||
---
|
||||
|
||||
## Confirm dialog
|
||||
|
||||
```html
|
||||
<!doctype html>
|
||||
<meta charset="utf-8" />
|
||||
<script id="data" type="application/json">__DATA__</script>
|
||||
<style>
|
||||
body { font: 14px system-ui; margin: 16px; }
|
||||
.actions { display: flex; gap: 8px; margin-top: 16px; }
|
||||
button { padding: 8px 16px; cursor: pointer; }
|
||||
.danger { background: #d33; color: white; border: none; }
|
||||
</style>
|
||||
<p id="msg"></p>
|
||||
<div class="actions">
|
||||
<button id="cancel">Cancel</button>
|
||||
<button id="confirm" class="danger">Confirm</button>
|
||||
</div>
|
||||
<script type="module">
|
||||
import { submit } from "https://esm.sh/@modelcontextprotocol/apps-sdk";
|
||||
const { message, confirmLabel } = JSON.parse(document.getElementById("data").textContent);
|
||||
document.getElementById("msg").textContent = message;
|
||||
if (confirmLabel) document.getElementById("confirm").textContent = confirmLabel;
|
||||
document.getElementById("confirm").onclick = () => submit({ confirmed: true });
|
||||
document.getElementById("cancel").onclick = () => submit({ confirmed: false });
|
||||
</script>
|
||||
```
|
||||
|
||||
**Data shape:** `{ message, confirmLabel? }`
|
||||
**Result shape:** `{ confirmed: boolean }`
|
||||
|
||||
---
|
||||
|
||||
## Progress (long-running)
|
||||
|
||||
```html
|
||||
<!doctype html>
|
||||
<meta charset="utf-8" />
|
||||
<script id="data" type="application/json">__DATA__</script>
|
||||
<style>
|
||||
body { font: 14px system-ui; margin: 16px; }
|
||||
.bar { height: 8px; background: #eee; border-radius: 4px; overflow: hidden; }
|
||||
.fill { height: 100%; background: #2a7; transition: width 200ms; }
|
||||
</style>
|
||||
<p id="label">Starting…</p>
|
||||
<div class="bar"><div id="fill" class="fill" style="width:0%"></div></div>
|
||||
<script type="module">
|
||||
import { submit, onMessage } from "https://esm.sh/@modelcontextprotocol/apps-sdk";
|
||||
const { jobId } = JSON.parse(document.getElementById("data").textContent);
|
||||
const label = document.getElementById("label");
|
||||
const fill = document.getElementById("fill");
|
||||
|
||||
onMessage((msg) => {
|
||||
if (msg.type === "progress") {
|
||||
label.textContent = msg.label;
|
||||
fill.style.width = `${msg.percent}%`;
|
||||
}
|
||||
if (msg.type === "done") submit(msg.result);
|
||||
});
|
||||
</script>
|
||||
```
|
||||
|
||||
The server pushes updates via the transport's notification channel targeting this widget's session. See `apps-sdk-messages.md` for the server-side push.
|
||||
|
||||
---
|
||||
|
||||
## Display-only (chart / preview)
|
||||
|
||||
Display widgets don't need `submit()` — they render and sit there. Return a text summary **alongside** the widget so Claude can keep reasoning:
|
||||
|
||||
```typescript
|
||||
return {
|
||||
content: [
|
||||
{ type: "text", text: "Revenue is up 12% MoM. Chart rendered below." },
|
||||
{ type: "resource", resource: { uri: "ui://widgets/chart", mimeType: "text/html+skybridge", text: renderWidget("chart", data) } },
|
||||
],
|
||||
};
|
||||
```
|
||||
177
plugins/mcp-server-dev/skills/build-mcp-server/SKILL.md
Normal file
177
plugins/mcp-server-dev/skills/build-mcp-server/SKILL.md
Normal file
@@ -0,0 +1,177 @@
|
||||
---
|
||||
name: build-mcp-server
|
||||
description: This skill should be used when the user asks to "build an MCP server", "create an MCP", "make an MCP integration", "wrap an API for Claude", "expose tools to Claude", "make an MCP app", or discusses building something with the Model Context Protocol. It is the entry point for MCP server development — it interrogates the user about their use case, determines the right deployment model (remote HTTP, MCPB, local stdio), picks a tool-design pattern, and hands off to specialized skills.
|
||||
version: 0.1.0
|
||||
---
|
||||
|
||||
# Build an MCP Server
|
||||
|
||||
You are guiding a developer through designing and building an MCP server that works seamlessly with Claude. MCP servers come in many forms — picking the wrong shape early causes painful rewrites later. Your first job is **discovery, not code**.
|
||||
|
||||
Do not start scaffolding until you have answers to the questions in Phase 1. If the user's opening message already answers them, acknowledge that and skip straight to the recommendation.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — Interrogate the use case
|
||||
|
||||
Ask these questions conversationally (batch them into one message, don't interrogate one-at-a-time). Adapt wording to what the user has already told you.
|
||||
|
||||
### 1. What does it connect to?
|
||||
|
||||
| If it connects to… | Likely direction |
|
||||
|---|---|
|
||||
| A cloud API (SaaS, REST, GraphQL) | Remote HTTP server |
|
||||
| A local process, filesystem, or desktop app | MCPB or local stdio |
|
||||
| Hardware, OS-level APIs, or user-specific state | MCPB |
|
||||
| Nothing external — pure logic / computation | Either — default to remote |
|
||||
|
||||
### 2. Who will use it?
|
||||
|
||||
- **Just me / my team, on our machines** → Local stdio is acceptable (easiest to prototype)
|
||||
- **Anyone who installs it** → Remote HTTP (strongly preferred) or MCPB (if it *must* be local)
|
||||
- **Users of Claude desktop who want UI widgets** → MCP app (remote or MCPB)
|
||||
|
||||
### 3. How many distinct actions does it expose?
|
||||
|
||||
This determines the tool-design pattern — see Phase 3.
|
||||
|
||||
- **Under ~15 actions** → one tool per action
|
||||
- **Dozens to hundreds of actions** (e.g. wrapping a large API surface) → search + execute pattern
|
||||
|
||||
### 4. Does it need interactive UI in the chat?
|
||||
|
||||
Forms, pickers, dashboards, confirmation dialogs rendered inline in the conversation → **MCP app** (adds UI resources on top of a standard server).
|
||||
|
||||
### 5. What auth does the upstream service use?
|
||||
|
||||
- None / API key → straightforward
|
||||
- OAuth 2.0 → you'll need a remote server with DCR (Dynamic Client Registration) or CIMD support; see `references/auth.md`
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Recommend a deployment model
|
||||
|
||||
Based on the answers, recommend **one** path. Be opinionated. The ranked options:
|
||||
|
||||
### ⭐ Remote streamable-HTTP MCP server (default recommendation)
|
||||
|
||||
A hosted service speaking MCP over streamable HTTP. This is the **recommended path** for anything wrapping a cloud API.
|
||||
|
||||
**Why it wins:**
|
||||
- Zero install friction — users add a URL, done
|
||||
- One deployment serves all users; you control upgrades
|
||||
- OAuth flows work properly (the server can handle redirects, DCR, token storage)
|
||||
- Works across Claude desktop, Claude Code, Claude.ai, and third-party MCP hosts
|
||||
|
||||
**Choose this unless** the server *must* touch the user's local machine.
|
||||
|
||||
→ Scaffold with `references/remote-http-scaffold.md`
|
||||
|
||||
### MCP app (remote HTTP + interactive UI)
|
||||
|
||||
Same as above, plus **UI resources** — interactive widgets rendered in chat. Forms, file pickers, rich previews, confirmation dialogs. Built once, renders in Claude *and* ChatGPT.
|
||||
|
||||
**Choose this when** one or more tools benefit from structured user input or rich output that plain text can't handle.
|
||||
|
||||
Usually remote, but can be shipped as MCPB if the UI needs to drive a local app.
|
||||
|
||||
→ Hand off to the **`build-mcp-app`** skill.
|
||||
|
||||
### MCPB (bundled local server)
|
||||
|
||||
A local MCP server **packaged with its runtime** so users don't need Node/Python installed. The sanctioned way to ship local servers.
|
||||
|
||||
**Choose this when** the server *must* run on the user's machine — it reads local files, drives a desktop app, talks to localhost services, or needs OS-level access.
|
||||
|
||||
→ Hand off to the **`build-mcpb`** skill.
|
||||
|
||||
### Local stdio (npx / uvx) — *not recommended for distribution*
|
||||
|
||||
A script launched via `npx` / `uvx` on the user's machine. Fine for **personal tools and prototypes**. Painful to distribute: users need the right runtime, you can't push updates, and the only distribution channel is Claude Code plugins.
|
||||
|
||||
Recommend this only as a stepping stone. If the user insists, scaffold it but note the MCPB upgrade path.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Pick a tool-design pattern
|
||||
|
||||
Every MCP server exposes tools. How you carve them matters more than most people expect — tool schemas land directly in Claude's context window.
|
||||
|
||||
### Pattern A: One tool per action (small surface)
|
||||
|
||||
When the action space is small (< ~15 operations), give each a dedicated tool with a tight description and schema.
|
||||
|
||||
```
|
||||
create_issue — Create a new issue. Params: title, body, labels[]
|
||||
update_issue — Update an existing issue. Params: id, title?, body?, state?
|
||||
search_issues — Search issues by query string. Params: query, limit?
|
||||
add_comment — Add a comment to an issue. Params: issue_id, body
|
||||
```
|
||||
|
||||
**Why it works:** Claude reads the tool list once and knows exactly what's possible. No discovery round-trips. Each tool's schema validates inputs precisely.
|
||||
|
||||
**Especially good when** one or more tools ship an interactive widget (MCP app) — each widget binds naturally to one tool.
|
||||
|
||||
### Pattern B: Search + execute (large surface)
|
||||
|
||||
When wrapping a large API (dozens to hundreds of endpoints), listing every operation as a tool floods the context window and degrades model performance. Instead, expose **two** tools:
|
||||
|
||||
```
|
||||
search_actions — Given a natural-language intent, return matching actions
|
||||
with their IDs, descriptions, and parameter schemas.
|
||||
execute_action — Run an action by ID with a params object.
|
||||
```
|
||||
|
||||
The server holds the full catalog internally. Claude searches, picks, executes. Context stays lean.
|
||||
|
||||
**Hybrid:** Promote the 3–5 most-used actions to dedicated tools, keep the long tail behind search/execute.
|
||||
|
||||
→ See `references/tool-design.md` for schema examples and description-writing guidance.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 — Pick a framework
|
||||
|
||||
Recommend one of these two. Others exist but these have the best MCP-spec coverage and Claude compatibility.
|
||||
|
||||
| Framework | Language | Use when |
|
||||
|---|---|---|
|
||||
| **Official TypeScript SDK** (`@modelcontextprotocol/sdk`) | TS/JS | Default choice. Best spec coverage, first to get new features. |
|
||||
| **FastMCP 2.0** | Python | User prefers Python, or wrapping a Python library. Decorator-based, very low boilerplate. |
|
||||
|
||||
If the user already has a language/stack in mind, go with it — both produce identical wire protocol.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5 — Scaffold and hand off
|
||||
|
||||
Once you've settled the four decisions (deployment model, tool pattern, framework, auth), do **one** of:
|
||||
|
||||
1. **Remote HTTP, no UI** → Scaffold inline using `references/remote-http-scaffold.md`. This skill can finish the job.
|
||||
2. **MCP app (UI widgets)** → Summarize the decisions so far, then load the **`build-mcp-app`** skill.
|
||||
3. **MCPB (bundled local)** → Summarize the decisions so far, then load the **`build-mcpb`** skill.
|
||||
4. **Local stdio prototype** → Scaffold inline (simplest case), flag the MCPB upgrade path.
|
||||
|
||||
When handing off, restate the design brief in one paragraph so the next skill doesn't re-ask.
|
||||
|
||||
---
|
||||
|
||||
## Quick reference: decision matrix
|
||||
|
||||
| Scenario | Deployment | Tool pattern |
|
||||
|---|---|---|
|
||||
| Wrap a small SaaS API | Remote HTTP | One-per-action |
|
||||
| Wrap a large SaaS API (50+ endpoints) | Remote HTTP | Search + execute |
|
||||
| SaaS API with rich forms / pickers | MCP app (remote) | One-per-action |
|
||||
| Drive a local desktop app | MCPB | One-per-action |
|
||||
| Local desktop app with in-chat UI | MCP app (MCPB) | One-per-action |
|
||||
| Read/write local filesystem | MCPB | Depends on surface |
|
||||
| Personal prototype | Local stdio | Whatever's fastest |
|
||||
|
||||
---
|
||||
|
||||
## Reference files
|
||||
|
||||
- `references/remote-http-scaffold.md` — minimal remote server in TS SDK and FastMCP
|
||||
- `references/tool-design.md` — writing tool descriptions and schemas Claude understands well
|
||||
- `references/auth.md` — OAuth, DCR, CIMD, token storage patterns
|
||||
@@ -0,0 +1,73 @@
|
||||
# Auth for MCP Servers
|
||||
|
||||
Auth is the reason most people end up needing a **remote** server even when a local one would be simpler. OAuth redirects, token storage, and refresh all work cleanly when there's a real hosted endpoint to redirect back to.
|
||||
|
||||
---
|
||||
|
||||
## The three tiers
|
||||
|
||||
### Tier 1: No auth / static API key
|
||||
|
||||
Server reads a key from env. User provides it once at setup. Done.
|
||||
|
||||
```typescript
|
||||
const apiKey = process.env.UPSTREAM_API_KEY;
|
||||
if (!apiKey) throw new Error("UPSTREAM_API_KEY not set");
|
||||
```
|
||||
|
||||
Works for local stdio, MCPB, and remote servers alike. If this is all you need, stop here.
|
||||
|
||||
### Tier 2: OAuth 2.0 via Dynamic Client Registration (DCR)
|
||||
|
||||
The MCP host (Claude desktop, Claude Code, etc.) discovers your server's OAuth metadata, **registers itself as a client dynamically**, runs the auth-code flow, and stores the token. Your server never sees credentials — it just receives bearer tokens on each request.
|
||||
|
||||
This is the **recommended path** for any remote server wrapping an OAuth-protected API.
|
||||
|
||||
**Server responsibilities:**
|
||||
|
||||
1. Serve OAuth Authorization Server Metadata (RFC 8414) at `/.well-known/oauth-authorization-server`
|
||||
2. Serve an MCP-protected-resource metadata document pointing at (1)
|
||||
3. Implement (or proxy to) a DCR endpoint that hands out client IDs
|
||||
4. Validate bearer tokens on incoming `/mcp` requests
|
||||
|
||||
Most of this is boilerplate — the SDK has helpers. The real decision is whether you **proxy** to the upstream's OAuth (if they support DCR) or run your own **shim** authorization server that exchanges your tokens for upstream tokens.
|
||||
|
||||
```
|
||||
┌─────────┐ DCR + auth code ┌──────────────┐ upstream OAuth ┌──────────┐
|
||||
│ MCP host│ ──────────────────> │ Your MCP srv │ ─────────────────> │ Upstream │
|
||||
└─────────┘ <── bearer token ── └──────────────┘ <── access token ──└──────────┘
|
||||
```
|
||||
|
||||
### Tier 3: CIMD (Client ID Metadata Document)
|
||||
|
||||
An alternative to DCR for ecosystems that don't want dynamic registration. The host publishes its client metadata at a well-known URL; your server fetches it, validates it, and issues a client credential. Lower friction than DCR for the host, slightly more work for you.
|
||||
|
||||
Use CIMD when targeting hosts that advertise CIMD support in their client metadata. Otherwise default to DCR — it's more broadly implemented.
|
||||
|
||||
---
|
||||
|
||||
## Hosting providers with built-in DCR/CIMD support
|
||||
|
||||
Several MCP-focused hosting providers handle the OAuth plumbing for you — you implement tool logic, they run the authorization server. Check their docs for current capabilities. If the user doesn't have strong hosting preferences, this is usually the fastest path to a working OAuth-protected server.
|
||||
|
||||
---
|
||||
|
||||
## Local servers and OAuth
|
||||
|
||||
Local stdio servers **can** do OAuth (open a browser, catch the redirect on a localhost port, stash the token in the OS keychain). It's fragile:
|
||||
|
||||
- Breaks in headless/remote environments
|
||||
- Every user re-does the dance
|
||||
- No central token refresh or revocation
|
||||
|
||||
If OAuth is required, lean hard toward remote HTTP. If you *must* ship local + OAuth, the `@modelcontextprotocol/sdk` includes a localhost-redirect helper, and MCPB is the right packaging so at least the runtime is predictable.
|
||||
|
||||
---
|
||||
|
||||
## Token storage
|
||||
|
||||
| Deployment | Store tokens in |
|
||||
|---|---|
|
||||
| Remote, stateless | Nowhere — host sends bearer each request |
|
||||
| Remote, stateful | Session store keyed by MCP session ID (Redis, etc.) |
|
||||
| MCPB / local | OS keychain (`keytar` on Node, `keyring` on Python). **Never plaintext on disk.** |
|
||||
@@ -0,0 +1,151 @@
|
||||
# Remote Streamable-HTTP MCP Server — Scaffold
|
||||
|
||||
Minimal working servers in both recommended frameworks. Start here, then add tools.
|
||||
|
||||
---
|
||||
|
||||
## TypeScript SDK (`@modelcontextprotocol/sdk`)
|
||||
|
||||
```bash
|
||||
npm init -y
|
||||
npm install @modelcontextprotocol/sdk zod express
|
||||
npm install -D typescript @types/express @types/node tsx
|
||||
```
|
||||
|
||||
**`src/server.ts`**
|
||||
|
||||
```typescript
|
||||
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
|
||||
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
|
||||
import express from "express";
|
||||
import { z } from "zod";
|
||||
|
||||
const server = new McpServer({
|
||||
name: "my-service",
|
||||
version: "0.1.0",
|
||||
});
|
||||
|
||||
// Pattern A: one tool per action
|
||||
server.tool(
|
||||
"search_items",
|
||||
"Search items by keyword. Returns up to `limit` matches ranked by relevance.",
|
||||
{
|
||||
query: z.string().describe("Search keywords"),
|
||||
limit: z.number().int().min(1).max(50).default(10),
|
||||
},
|
||||
async ({ query, limit }) => {
|
||||
const results = await upstreamApi.search(query, limit);
|
||||
return {
|
||||
content: [{ type: "text", text: JSON.stringify(results, null, 2) }],
|
||||
};
|
||||
},
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"get_item",
|
||||
"Fetch a single item by its ID.",
|
||||
{ id: z.string() },
|
||||
async ({ id }) => {
|
||||
const item = await upstreamApi.get(id);
|
||||
return { content: [{ type: "text", text: JSON.stringify(item) }] };
|
||||
},
|
||||
);
|
||||
|
||||
// Streamable HTTP transport (stateless mode — simplest)
|
||||
const app = express();
|
||||
app.use(express.json());
|
||||
|
||||
app.post("/mcp", async (req, res) => {
|
||||
const transport = new StreamableHTTPServerTransport({
|
||||
sessionIdGenerator: undefined, // stateless
|
||||
});
|
||||
res.on("close", () => transport.close());
|
||||
await server.connect(transport);
|
||||
await transport.handleRequest(req, res, req.body);
|
||||
});
|
||||
|
||||
app.listen(process.env.PORT ?? 3000);
|
||||
```
|
||||
|
||||
**Stateless vs stateful:** The snippet above creates a fresh transport per request (stateless). Fine for most API-wrapping servers. If tools need to share state across calls in a session (rare), use a session-keyed transport map — see the SDK's `examples/server/simpleStreamableHttp.ts`.
|
||||
|
||||
---
|
||||
|
||||
## FastMCP 2.0 (Python)
|
||||
|
||||
```bash
|
||||
pip install fastmcp
|
||||
```
|
||||
|
||||
**`server.py`**
|
||||
|
||||
```python
|
||||
from fastmcp import FastMCP
|
||||
|
||||
mcp = FastMCP(name="my-service")
|
||||
|
||||
@mcp.tool
|
||||
def search_items(query: str, limit: int = 10) -> list[dict]:
|
||||
"""Search items by keyword. Returns up to `limit` matches ranked by relevance."""
|
||||
return upstream_api.search(query, limit)
|
||||
|
||||
@mcp.tool
|
||||
def get_item(id: str) -> dict:
|
||||
"""Fetch a single item by its ID."""
|
||||
return upstream_api.get(id)
|
||||
|
||||
if __name__ == "__main__":
|
||||
mcp.run(transport="http", host="0.0.0.0", port=3000)
|
||||
```
|
||||
|
||||
FastMCP derives the JSON schema from type hints and the docstring becomes the tool description. Keep docstrings terse and action-oriented — they land in Claude's context window verbatim.
|
||||
|
||||
---
|
||||
|
||||
## Search + execute pattern (large API surface)
|
||||
|
||||
When wrapping 50+ endpoints, don't register them all. Two tools:
|
||||
|
||||
```typescript
|
||||
const CATALOG = loadActionCatalog(); // { id, description, paramSchema }[]
|
||||
|
||||
server.tool(
|
||||
"search_actions",
|
||||
"Find available actions matching an intent. Call this first to discover what's possible. Returns action IDs, descriptions, and parameter schemas.",
|
||||
{ intent: z.string().describe("What you want to do, in plain English") },
|
||||
async ({ intent }) => {
|
||||
const matches = rankActions(CATALOG, intent).slice(0, 10);
|
||||
return { content: [{ type: "text", text: JSON.stringify(matches, null, 2) }] };
|
||||
},
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"execute_action",
|
||||
"Execute an action by ID. Get the ID and params schema from search_actions first.",
|
||||
{
|
||||
action_id: z.string(),
|
||||
params: z.record(z.unknown()),
|
||||
},
|
||||
async ({ action_id, params }) => {
|
||||
const action = CATALOG.find(a => a.id === action_id);
|
||||
if (!action) throw new Error(`Unknown action: ${action_id}`);
|
||||
validate(params, action.paramSchema);
|
||||
const result = await dispatch(action, params);
|
||||
return { content: [{ type: "text", text: JSON.stringify(result) }] };
|
||||
},
|
||||
);
|
||||
```
|
||||
|
||||
`rankActions` can be simple keyword matching to start. Upgrade to embeddings if precision matters.
|
||||
|
||||
---
|
||||
|
||||
## Deployment checklist
|
||||
|
||||
- [ ] `POST /mcp` responds to `initialize` with server capabilities
|
||||
- [ ] `tools/list` returns your tools with complete schemas
|
||||
- [ ] Errors return structured MCP errors, not HTTP 500s with HTML bodies
|
||||
- [ ] CORS headers set if browser clients will connect
|
||||
- [ ] Health check endpoint separate from `/mcp` (hosts poll it)
|
||||
- [ ] Secrets from env vars, never hardcoded
|
||||
- [ ] If OAuth: DCR endpoint implemented — see `auth.md`
|
||||
@@ -0,0 +1,112 @@
|
||||
# Tool Design — Writing Tools Claude Uses Correctly
|
||||
|
||||
Tool schemas and descriptions are prompt engineering. They land directly in Claude's context and determine whether Claude picks the right tool with the right arguments. Most MCP integration bugs trace back to vague descriptions or loose schemas.
|
||||
|
||||
---
|
||||
|
||||
## Descriptions
|
||||
|
||||
**The description is the contract.** It's the only thing Claude reads before deciding whether to call the tool. Write it like a one-line manpage entry plus disambiguating hints.
|
||||
|
||||
### Good
|
||||
|
||||
```
|
||||
search_issues — Search issues by keyword across title and body. Returns up
|
||||
to `limit` results ranked by recency. Does NOT search comments or PRs —
|
||||
use search_comments / search_prs for those.
|
||||
```
|
||||
|
||||
- Says what it does
|
||||
- Says what it returns
|
||||
- Says what it *doesn't* do (prevents wrong-tool calls)
|
||||
|
||||
### Bad
|
||||
|
||||
```
|
||||
search_issues — Searches for issues.
|
||||
```
|
||||
|
||||
Claude will call this for anything vaguely search-shaped, including things it can't do.
|
||||
|
||||
### Disambiguate siblings
|
||||
|
||||
When two tools are similar, each description should say when to use the *other* one:
|
||||
|
||||
```
|
||||
get_user — Fetch a user by ID. If you only have an email, use find_user_by_email.
|
||||
find_user_by_email — Look up a user by email address. Returns null if not found.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Parameter schemas
|
||||
|
||||
**Tight schemas prevent bad calls.** Every constraint you express in the schema is one fewer thing that can go wrong at runtime.
|
||||
|
||||
| Instead of | Use |
|
||||
|---|---|
|
||||
| `z.string()` for an ID | `z.string().regex(/^usr_[a-z0-9]{12}$/)` |
|
||||
| `z.number()` for a limit | `z.number().int().min(1).max(100).default(20)` |
|
||||
| `z.string()` for a choice | `z.enum(["open", "closed", "all"])` |
|
||||
| optional with no hint | `.optional().describe("Defaults to the caller's workspace")` |
|
||||
|
||||
**Describe every parameter.** The `.describe()` text shows up in the schema Claude sees. Omitting it is leaving money on the table.
|
||||
|
||||
```typescript
|
||||
{
|
||||
query: z.string().describe("Keywords to search for. Supports quoted phrases."),
|
||||
status: z.enum(["open", "closed", "all"]).default("open")
|
||||
.describe("Filter by status. Use 'all' to include closed items."),
|
||||
limit: z.number().int().min(1).max(50).default(10)
|
||||
.describe("Max results. Hard cap at 50."),
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Return shapes
|
||||
|
||||
Claude reads whatever you put in `content[].text`. Make it parseable.
|
||||
|
||||
**Do:**
|
||||
- Return JSON for structured data (`JSON.stringify(result, null, 2)`)
|
||||
- Return short confirmations for mutations (`"Created issue #123"`)
|
||||
- Include IDs Claude will need for follow-up calls
|
||||
- Truncate huge payloads and say so (`"Showing 10 of 847 results. Refine the query to narrow down."`)
|
||||
|
||||
**Don't:**
|
||||
- Return raw HTML
|
||||
- Return megabytes of unfiltered API response
|
||||
- Return bare success with no identifier (`"ok"` after a create — Claude can't reference what it made)
|
||||
|
||||
---
|
||||
|
||||
## How many tools?
|
||||
|
||||
| Tool count | Guidance |
|
||||
|---|---|
|
||||
| 1–15 | One tool per action. Sweet spot. |
|
||||
| 15–30 | Still workable. Audit for near-duplicates that could merge. |
|
||||
| 30+ | Switch to search + execute. Optionally promote the top 3–5 to dedicated tools. |
|
||||
|
||||
The ceiling isn't a hard protocol limit — it's context-window economics. Every tool schema is tokens Claude spends *every turn*. Thirty tools with rich schemas can eat 3–5k tokens before the conversation even starts.
|
||||
|
||||
---
|
||||
|
||||
## Errors
|
||||
|
||||
Return MCP tool errors, not exceptions that crash the transport. Include enough detail for Claude to recover or retry differently.
|
||||
|
||||
```typescript
|
||||
if (!item) {
|
||||
return {
|
||||
isError: true,
|
||||
content: [{
|
||||
type: "text",
|
||||
text: `Item ${id} not found. Use search_items to find valid IDs.`,
|
||||
}],
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
The hint ("use search_items…") turns a dead end into a next step.
|
||||
179
plugins/mcp-server-dev/skills/build-mcpb/SKILL.md
Normal file
179
plugins/mcp-server-dev/skills/build-mcpb/SKILL.md
Normal file
@@ -0,0 +1,179 @@
|
||||
---
|
||||
name: build-mcpb
|
||||
description: This skill should be used when the user wants to "package an MCP server", "bundle an MCP", "make an MCPB", "ship a local MCP server", "distribute a local MCP", discusses ".mcpb files", mentions bundling a Node or Python runtime with their MCP server, or needs an MCP server that interacts with the local filesystem, desktop apps, or OS and must be installable without the user having Node/Python set up.
|
||||
version: 0.1.0
|
||||
---
|
||||
|
||||
# Build an MCPB (Bundled Local MCP Server)
|
||||
|
||||
MCPB is a local MCP server **packaged with its runtime**. The user installs one file; it runs without needing Node, Python, or any toolchain on their machine. It's the sanctioned way to distribute local MCP servers.
|
||||
|
||||
**Use MCPB when the server must run on the user's machine** — reading local files, driving a desktop app, talking to localhost services, OS-level APIs. If your server only hits cloud APIs, you almost certainly want a remote HTTP server instead (see `build-mcp-server`). Don't pay the MCPB packaging tax for something that could be a URL.
|
||||
|
||||
---
|
||||
|
||||
## What an MCPB bundle contains
|
||||
|
||||
```
|
||||
my-server.mcpb (zip archive)
|
||||
├── manifest.json ← identity, entry point, permissions, config schema
|
||||
├── server/ ← your MCP server code
|
||||
│ ├── index.js
|
||||
│ └── node_modules/ ← bundled dependencies (or vendored)
|
||||
├── runtime/ ← optional: pinned Node/Python if not using host's
|
||||
└── icon.png
|
||||
```
|
||||
|
||||
The host reads `manifest.json`, launches the entry point as a **stdio** MCP server, and pipes messages. From your code's perspective it's identical to a local stdio server — the only difference is packaging.
|
||||
|
||||
---
|
||||
|
||||
## Manifest
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "local-files",
|
||||
"version": "0.1.0",
|
||||
"description": "Read, search, and watch files on the local filesystem.",
|
||||
"entry": {
|
||||
"type": "node",
|
||||
"main": "server/index.js"
|
||||
},
|
||||
"permissions": {
|
||||
"filesystem": { "read": true, "write": false },
|
||||
"network": false
|
||||
},
|
||||
"config": {
|
||||
"rootDir": {
|
||||
"type": "string",
|
||||
"description": "Directory to expose. Defaults to ~/Documents.",
|
||||
"default": "~/Documents"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**`entry.type`** — `node`, `python`, or `binary`. Determines which bundled/host runtime launches `main`.
|
||||
|
||||
**`permissions`** — declared upfront and shown to the user at install. Request the minimum. Broad permissions (`filesystem.write: true`, `network: true`) trigger scarier consent UI and more scrutiny.
|
||||
|
||||
**`config`** — user-settable values surfaced in the host's settings UI. Your server reads them from env vars (`MCPB_CONFIG_<KEY>`).
|
||||
|
||||
---
|
||||
|
||||
## Server code: same as local stdio
|
||||
|
||||
The server itself is a standard stdio MCP server. Nothing MCPB-specific in the tool logic.
|
||||
|
||||
```typescript
|
||||
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
|
||||
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
|
||||
import { z } from "zod";
|
||||
import { readFile, readdir } from "node:fs/promises";
|
||||
import { join } from "node:path";
|
||||
import { homedir } from "node:os";
|
||||
|
||||
const ROOT = (process.env.MCPB_CONFIG_ROOTDIR ?? "~/Documents")
|
||||
.replace(/^~/, homedir());
|
||||
|
||||
const server = new McpServer({ name: "local-files", version: "0.1.0" });
|
||||
|
||||
server.tool(
|
||||
"list_files",
|
||||
"List files in a directory under the configured root.",
|
||||
{ path: z.string().default(".") },
|
||||
async ({ path }) => {
|
||||
const entries = await readdir(join(ROOT, path), { withFileTypes: true });
|
||||
const list = entries.map(e => ({ name: e.name, dir: e.isDirectory() }));
|
||||
return { content: [{ type: "text", text: JSON.stringify(list, null, 2) }] };
|
||||
},
|
||||
);
|
||||
|
||||
server.tool(
|
||||
"read_file",
|
||||
"Read a file's contents. Path is relative to the configured root.",
|
||||
{ path: z.string() },
|
||||
async ({ path }) => {
|
||||
const text = await readFile(join(ROOT, path), "utf8");
|
||||
return { content: [{ type: "text", text }] };
|
||||
},
|
||||
);
|
||||
|
||||
const transport = new StdioServerTransport();
|
||||
await server.connect(transport);
|
||||
```
|
||||
|
||||
**Sandboxing is your job.** The manifest permissions gate what the *host* allows the process to do, but don't rely on that alone — validate paths, refuse to escape `ROOT`, etc. See `references/local-security.md`.
|
||||
|
||||
---
|
||||
|
||||
## Build pipeline
|
||||
|
||||
### Node
|
||||
|
||||
```bash
|
||||
npm install
|
||||
npx esbuild src/index.ts --bundle --platform=node --outfile=server/index.js
|
||||
# or: copy node_modules wholesale if native deps resist bundling
|
||||
npx @modelcontextprotocol/mcpb pack . -o my-server.mcpb
|
||||
```
|
||||
|
||||
`mcpb pack` zips the directory, validates `manifest.json`, and optionally pulls a pinned Node runtime into `runtime/`.
|
||||
|
||||
### Python
|
||||
|
||||
```bash
|
||||
pip install -t server/vendor -r requirements.txt
|
||||
npx @modelcontextprotocol/mcpb pack . -o my-server.mcpb --runtime python3.12
|
||||
```
|
||||
|
||||
Vendor dependencies into a subdirectory and prepend it to `sys.path` in your entry script. Native extensions (numpy, etc.) must be built for each target platform — `mcpb pack --multiarch` cross-builds, but it's slow; avoid native deps if you can.
|
||||
|
||||
---
|
||||
|
||||
## Permissions: request the minimum
|
||||
|
||||
The install prompt shows what you ask for. Every extra permission is friction.
|
||||
|
||||
| Need | Request |
|
||||
|---|---|
|
||||
| Read files in one directory | `filesystem.read: true` + enforce root in code |
|
||||
| Write files | `filesystem.write: true` — justify in description |
|
||||
| Call a local HTTP service | `network: { "allow": ["localhost:*"] }` |
|
||||
| Call the internet | `network: true` — but ask yourself why this isn't a remote server |
|
||||
| Spawn processes | `process.spawn: true` — highest scrutiny |
|
||||
|
||||
If you find yourself requesting `network: true` to hit a cloud API, stop — that's a remote server wearing an MCPB costume. The user gains nothing from running it locally.
|
||||
|
||||
---
|
||||
|
||||
## MCPB + UI widgets
|
||||
|
||||
MCPB servers can serve UI resources exactly like remote MCP apps — the widget mechanism is transport-agnostic. A local file picker that browses the actual disk, a dialog that controls a native app, etc.
|
||||
|
||||
Widget authoring is covered in the **`build-mcp-app`** skill; it works the same here. The only difference is where the server runs.
|
||||
|
||||
---
|
||||
|
||||
## Testing
|
||||
|
||||
```bash
|
||||
# Run the server directly over stdio, poke it with the inspector
|
||||
npx @modelcontextprotocol/inspector node server/index.js
|
||||
|
||||
# Pack and validate
|
||||
npx @modelcontextprotocol/mcpb pack . -o test.mcpb
|
||||
npx @modelcontextprotocol/mcpb validate test.mcpb
|
||||
|
||||
# Install into Claude desktop for end-to-end
|
||||
npx @modelcontextprotocol/mcpb install test.mcpb
|
||||
```
|
||||
|
||||
Test on a machine **without** your dev toolchain before shipping. "Works on my machine" failures in MCPB almost always trace to a dependency that wasn't actually bundled.
|
||||
|
||||
---
|
||||
|
||||
## Reference files
|
||||
|
||||
- `references/manifest-schema.md` — full `manifest.json` field reference
|
||||
- `references/local-security.md` — path traversal, sandboxing, least privilege
|
||||
@@ -0,0 +1,111 @@
|
||||
# Local MCP Security
|
||||
|
||||
An MCPB server runs as the user, with whatever permissions the manifest was granted. Claude drives it. That combination means: **tool inputs are untrusted**, even though they come from an AI the user trusts. A prompt-injected web page can make Claude call your `delete_file` tool with a path you didn't intend.
|
||||
|
||||
Defense in depth. Manifest permissions are the outer wall; validation in your tool handlers is the inner wall.
|
||||
|
||||
---
|
||||
|
||||
## Path traversal
|
||||
|
||||
The #1 bug in local MCP servers. If you take a path parameter and join it to a root, **resolve and check containment**.
|
||||
|
||||
```typescript
|
||||
import { resolve, relative, isAbsolute } from "node:path";
|
||||
|
||||
function safeJoin(root: string, userPath: string): string {
|
||||
const full = resolve(root, userPath);
|
||||
const rel = relative(root, full);
|
||||
if (rel.startsWith("..") || isAbsolute(rel)) {
|
||||
throw new Error(`Path escapes root: ${userPath}`);
|
||||
}
|
||||
return full;
|
||||
}
|
||||
```
|
||||
|
||||
`resolve` normalizes `..`, symlink segments, etc. `relative` tells you if the result left the root. Don't just `String.includes("..")` — that misses encoded and symlink-based escapes.
|
||||
|
||||
**Python equivalent:**
|
||||
|
||||
```python
|
||||
from pathlib import Path
|
||||
|
||||
def safe_join(root: Path, user_path: str) -> Path:
|
||||
full = (root / user_path).resolve()
|
||||
if not full.is_relative_to(root.resolve()):
|
||||
raise ValueError(f"Path escapes root: {user_path}")
|
||||
return full
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Command injection
|
||||
|
||||
If you spawn processes, **never pass user input through a shell**.
|
||||
|
||||
```typescript
|
||||
// ❌ catastrophic
|
||||
exec(`git log ${branch}`);
|
||||
|
||||
// ✅ array-args, no shell
|
||||
execFile("git", ["log", branch]);
|
||||
```
|
||||
|
||||
If you're wrapping a CLI, build the full argv as an array. Validate each flag against an allowlist if the tool accepts flags at all.
|
||||
|
||||
---
|
||||
|
||||
## Read-only by default
|
||||
|
||||
Split read and write into separate tools. Most workflows only need read. A tool that's read-only can't be weaponized into data loss no matter what Claude is tricked into calling it with.
|
||||
|
||||
```
|
||||
list_files ← safe to call freely
|
||||
read_file ← safe to call freely
|
||||
write_file ← separate tool, separate permission, separate scrutiny
|
||||
delete_file ← consider not shipping this at all
|
||||
```
|
||||
|
||||
If you ship write/delete, consider requiring a confirmation widget (see `build-mcp-app`) so the user explicitly approves each destructive call.
|
||||
|
||||
---
|
||||
|
||||
## Resource limits
|
||||
|
||||
Claude will happily ask to read a 4GB log file. Cap everything:
|
||||
|
||||
```typescript
|
||||
const MAX_BYTES = 1_000_000;
|
||||
const buf = await readFile(path);
|
||||
if (buf.length > MAX_BYTES) {
|
||||
return {
|
||||
content: [{
|
||||
type: "text",
|
||||
text: `File is ${buf.length} bytes — too large. Showing first ${MAX_BYTES}:\n\n`
|
||||
+ buf.subarray(0, MAX_BYTES).toString("utf8"),
|
||||
}],
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Same for directory listings (cap entry count), search results (cap matches), and anything else unbounded.
|
||||
|
||||
---
|
||||
|
||||
## Secrets
|
||||
|
||||
- **Config secrets** (`secret: true` in manifest): host stores in OS keychain, delivers via env var. Don't log them. Don't include them in tool results.
|
||||
- **Never store secrets in plaintext files.** If the host's keychain integration isn't enough, use `keytar` (Node) / `keyring` (Python) yourself.
|
||||
- **Tool results flow into the chat transcript.** Anything you return, the user (and any log export) can see. Redact before returning.
|
||||
|
||||
---
|
||||
|
||||
## Checklist before shipping
|
||||
|
||||
- [ ] Every path parameter goes through containment check
|
||||
- [ ] No `exec()` / `shell=True` — `execFile` / array-argv only
|
||||
- [ ] Write/delete split from read tools
|
||||
- [ ] Size caps on file reads, listing lengths, search results
|
||||
- [ ] Manifest permissions match actual code behavior (no over-requesting)
|
||||
- [ ] Secrets never logged or returned in tool results
|
||||
- [ ] Tested with adversarial inputs: `../../etc/passwd`, `; rm -rf ~`, 10GB file
|
||||
@@ -0,0 +1,132 @@
|
||||
# MCPB Manifest Schema
|
||||
|
||||
Every `.mcpb` bundle has a `manifest.json` at its root. The host validates it before install.
|
||||
|
||||
---
|
||||
|
||||
## Top-level fields
|
||||
|
||||
| Field | Type | Required | Notes |
|
||||
|---|---|---|---|
|
||||
| `name` | string | ✅ | Unique identifier. Lowercase, hyphens only. Shown in settings. |
|
||||
| `version` | string | ✅ | Semver. Host compares for update prompts. |
|
||||
| `description` | string | ✅ | One line. Shown in the install prompt. |
|
||||
| `entry` | object | ✅ | How to launch the server — see below. |
|
||||
| `permissions` | object | ✅ | What the server needs — see below. |
|
||||
| `config` | object | — | User-settable values surfaced in settings UI. |
|
||||
| `icon` | string | — | Path to PNG inside the bundle. 256×256 recommended. |
|
||||
| `homepage` | string | — | URL shown in settings. |
|
||||
| `minHostVersion` | string | — | Refuse install on older hosts. |
|
||||
|
||||
---
|
||||
|
||||
## `entry`
|
||||
|
||||
```json
|
||||
{ "type": "node", "main": "server/index.js" }
|
||||
```
|
||||
|
||||
| `type` | `main` points at | Runtime resolution |
|
||||
|---|---|---|
|
||||
| `node` | `.js` or `.mjs` file | `runtime/node` if present, else host-bundled Node |
|
||||
| `python` | `.py` file | `runtime/python` if present, else host-bundled Python |
|
||||
| `binary` | executable | Run directly. Must be built per-platform. |
|
||||
|
||||
**`args`** (optional array) — extra argv passed to the entry. Rarely needed.
|
||||
|
||||
**`env`** (optional object) — static env vars set at launch. For user-configurable values use `config` instead.
|
||||
|
||||
---
|
||||
|
||||
## `permissions`
|
||||
|
||||
```json
|
||||
{
|
||||
"filesystem": { "read": true, "write": false },
|
||||
"network": { "allow": ["localhost:*", "127.0.0.1:*"] },
|
||||
"process": { "spawn": false }
|
||||
}
|
||||
```
|
||||
|
||||
### `filesystem`
|
||||
|
||||
| Value | Meaning |
|
||||
|---|---|
|
||||
| `false` or omitted | No filesystem access beyond the bundle itself |
|
||||
| `{ "read": true }` | Read anywhere the OS user can |
|
||||
| `{ "read": true, "write": true }` | Read and write |
|
||||
|
||||
There's no path scoping at the manifest level — scope in your code. The manifest permission is a coarse consent gate, not a sandbox.
|
||||
|
||||
### `network`
|
||||
|
||||
| Value | Meaning |
|
||||
|---|---|
|
||||
| `false` or omitted | No network (most local-first servers) |
|
||||
| `{ "allow": ["host:port", ...] }` | Allowlisted destinations. `*` wildcards ports. |
|
||||
| `true` | Unrestricted. Heavy scrutiny — explain why in `description`. |
|
||||
|
||||
### `process`
|
||||
|
||||
| Value | Meaning |
|
||||
|---|---|
|
||||
| `false` or omitted | Can't spawn child processes |
|
||||
| `{ "spawn": true }` | Can spawn. Needed for wrapping CLIs. |
|
||||
| `{ "spawn": true, "allow": ["git", "ffmpeg"] }` | Spawn only allowlisted binaries |
|
||||
|
||||
---
|
||||
|
||||
## `config`
|
||||
|
||||
User-editable settings, surfaced in the host UI. Each key becomes an env var: `MCPB_CONFIG_<UPPERCASE_KEY>`.
|
||||
|
||||
```json
|
||||
{
|
||||
"config": {
|
||||
"rootDir": {
|
||||
"type": "string",
|
||||
"description": "Directory to expose",
|
||||
"default": "~/Documents"
|
||||
},
|
||||
"maxFileSize": {
|
||||
"type": "number",
|
||||
"description": "Skip files larger than this (MB)",
|
||||
"default": 10,
|
||||
"min": 1,
|
||||
"max": 500
|
||||
},
|
||||
"includeHidden": {
|
||||
"type": "boolean",
|
||||
"description": "Include dotfiles in listings",
|
||||
"default": false
|
||||
},
|
||||
"apiKey": {
|
||||
"type": "string",
|
||||
"description": "Optional API key for the sync feature",
|
||||
"secret": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**`type`** — `string`, `number`, `boolean`. Enums: use `string` with `"enum": ["a", "b", "c"]`.
|
||||
|
||||
**`secret: true`** — host masks the value in UI and stores it in the OS keychain instead of a plain config file.
|
||||
|
||||
**`required: true`** — host blocks server launch until the user sets it. Use sparingly — a server that won't start until configured is a bad first-run experience.
|
||||
|
||||
---
|
||||
|
||||
## Minimal valid manifest
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "hello",
|
||||
"version": "0.1.0",
|
||||
"description": "Minimal MCPB server.",
|
||||
"entry": { "type": "node", "main": "server/index.js" },
|
||||
"permissions": {}
|
||||
}
|
||||
```
|
||||
|
||||
Empty `permissions` means no filesystem, no network, no spawn — pure computation only. Valid, if unusual.
|
||||
Reference in New Issue
Block a user