npm - wormclaude - Versions diffs - 1.0.119 → 1.0.121 - Mend

wormclaude 1.0.119 → 1.0.121

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (232) hide show

package/skills/build-mcp-app/references/widget-templates.md DELETED Viewed

@@ -1,249 +0,0 @@
-# Widget Templates
-Minimal HTML scaffolds for the common widget shapes. Copy, fill in, and ship.
-Every template inlines the `App` class from `@modelcontextprotocol/ext-apps` at build time, since the iframe's CSP blocks CDN script imports. They're deliberately framework-free — widgets are small enough that the React/Vue hydration cost rarely pays off.
----
-## Serving widget HTML
-Widgets are static HTML with a single placeholder: at server startup, `/*__EXT_APPS_BUNDLE__*/` is replaced with the `ext-apps/app-with-deps` bundle (rewritten to expose `globalThis.ExtApps`).
-```typescript
-import { readFileSync } from "node:fs";
-import { createRequire } from "node:module";
-import { registerAppResource, RESOURCE_MIME_TYPE } from "@modelcontextprotocol/ext-apps/server";
-const require = createRequire(import.meta.url);
-const bundle = readFileSync(
-  require.resolve("@modelcontextprotocol/ext-apps/app-with-deps"), "utf8",
-).replace(/export\{([^}]+)\};?\s*$/, (_, body) =>
-  "globalThis.ExtApps={" +
-  body.split(",").map((p) => {
-    const [local, exported] = p.split(" as ").map((s) => s.trim());
-    return `${exported ?? local}:${local}`;
-  }).join(",") + "};",
-);
-const pickerHtml = readFileSync("./widgets/picker.html", "utf8")
-  .replace("/*__EXT_APPS_BUNDLE__*/", () => bundle);
-registerAppResource(server, "Picker", "ui://widgets/picker.html", {},
-  async () => ({
-    contents: [{ uri: "ui://widgets/picker.html", mimeType: RESOURCE_MIME_TYPE, text: pickerHtml }],
-  }),
-);
-```
-Build the bundle once per server startup (or at build time) and reuse the `bundle` string across every widget template.
----
-## Picker (single-select list)
-```html
-<!doctype html>
-<meta charset="utf-8" />
-<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">
-/*__EXT_APPS_BUNDLE__*/
-const { App } = globalThis.ExtApps;
-(async () => {
-  const app = new App({ name: "Picker", version: "1.0.0" }, {});
-  const ul = document.getElementById("list");
-  app.ontoolresult = ({ content }) => {
-    const { items } = JSON.parse(content[0].text);
-    ul.innerHTML = "";
-    for (const it of items) {
-      const li = document.createElement("li");
-      li.innerHTML = `<div>${it.label}</div><div class="sub">${it.sub ?? ""}</div>`;
-      li.addEventListener("click", () => {
-        app.sendMessage({
-          role: "user",
-          content: [{ type: "text", text: `Selected: ${it.id}` }],
-        });
-      });
-      ul.append(li);
-    }
-  };
-  await app.connect();
-})();
-</script>
-```
-**Tool returns:** `{ content: [{ type: "text", text: JSON.stringify({ items: [{ id, label, sub? }] }) }] }`
----
-## Confirm dialog
-```html
-<!doctype html>
-<meta charset="utf-8" />
-<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">
-/*__EXT_APPS_BUNDLE__*/
-const { App } = globalThis.ExtApps;
-(async () => {
-  const app = new App({ name: "Confirm", version: "1.0.0" }, {});
-  app.ontoolresult = ({ content }) => {
-    const { message, confirmLabel } = JSON.parse(content[0].text);
-    document.getElementById("msg").textContent = message;
-    if (confirmLabel) document.getElementById("confirm").textContent = confirmLabel;
-  };
-  await app.connect();
-  document.getElementById("confirm").addEventListener("click", () => {
-    app.sendMessage({ role: "user", content: [{ type: "text", text: "Confirmed." }] });
-  });
-  document.getElementById("cancel").addEventListener("click", () => {
-    app.sendMessage({ role: "user", content: [{ type: "text", text: "Cancelled." }] });
-  });
-})();
-</script>
-```
-**Tool returns:** `{ content: [{ type: "text", text: JSON.stringify({ message, confirmLabel? }) }] }`
-**Note:** For a plain confirmation, lean on **elicitation** rather than a widget — see `../build-mcp-server/references/elicitation.md`. Reach for this widget when you need custom styling or context that a native form can't provide.
----
-## Progress (long-running)
-```html
-<!doctype html>
-<meta charset="utf-8" />
-<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">
-/*__EXT_APPS_BUNDLE__*/
-const { App } = globalThis.ExtApps;
-(async () => {
-  const app = new App({ name: "Progress", version: "1.0.0" }, {});
-  const label = document.getElementById("label");
-  const fill = document.getElementById("fill");
-  // The tool result fires when the job completes — intermediate updates
-  // arrive via the same handler if the server streams them
-  app.ontoolresult = ({ content }) => {
-    const state = JSON.parse(content[0].text);
-    if (state.progress !== undefined) {
-      label.textContent = state.message ?? `${state.progress}/${state.total}`;
-      fill.style.width = `${(state.progress / state.total) * 100}%`;
-    }
-    if (state.done) {
-      label.textContent = "Complete";
-      fill.style.width = "100%";
-    }
-  };
-  await app.connect();
-})();
-</script>
-```
-Server side, emit progress via `extra.sendNotification({ method: "notifications/progress", ... })` — see `apps-sdk-messages.md`.
----
-## Display-only (chart / preview)
-Display widgets never call `sendMessage` — they render and then just sit there. The tool should return a text summary **alongside** the widget so WormClaude can keep reasoning while the user looks at the visual:
-```typescript
-registerAppTool(server, "show_chart", {
-  description: "Render a revenue chart",
-  inputSchema: { range: z.enum(["week", "month", "year"]) },
-  _meta: { ui: { resourceUri: "ui://widgets/chart.html" } },
-}, async ({ range }) => {
-  const data = await fetchRevenue(range);
-  return {
-    content: [{
-      type: "text",
-      text: `Revenue is up ${data.change}% over the ${range}. Chart rendered.\n\n` +
-            JSON.stringify(data.points),
-    }],
-  };
-});
-```
-```html
-<!doctype html>
-<meta charset="utf-8" />
-<style>body { font: 14px system-ui; margin: 12px; }</style>
-<canvas id="chart" width="400" height="200"></canvas>
-<script type="module">
-/*__EXT_APPS_BUNDLE__*/
-const { App } = globalThis.ExtApps;
-(async () => {
-  const app = new App({ name: "Chart", version: "1.0.0" }, {});
-  app.ontoolresult = ({ content }) => {
-    // Parse the JSON points from the text content (after the summary line)
-    const text = content[0].text;
-    const jsonStart = text.indexOf("\n\n") + 2;
-    const points = JSON.parse(text.slice(jsonStart));
-    drawChart(document.getElementById("chart"), points);
-  };
-  await app.connect();
-  function drawChart(canvas, points) { /* ... */ }
-})();
-</script>
-```
----
-## Carousel (multi-item display with actions)
-For laying out several items (product picks, search results) in a horizontal scroll rail. Patterns that held up well in testing:
-- **Skip the nav chevrons** — users already know how to scroll. `scroll-snap-type` can leave the initial render a few px off-flush; drop it and set `scrollLeft = 0` after rendering.
-- **Fork the layout by item count** — `items.length === 1` → detail/PDP layout, `> 1` → carousel. Do it in widget JS and keep the tool schema flat.
-- **Put WormClaude's reasoning on each item** — a `note` field rendered as a small callout on the card gives users the "why" right there.
-- **Silent state through `updateModelContext`** — cart or selection changes should inform WormClaude without spamming the chat. Save `sendMessage` for terminal actions ("checkout", "done").
-- **Outbound links through `app.openLink`** — the sandbox blocks `window.open` and `<a target="_blank">`.
-```html
-<style>
-  .rail { display: flex; gap: 10px; overflow-x: auto; padding: 12px; scrollbar-width: none; }
-  .rail::-webkit-scrollbar { display: none; }
-  .card { flex: 0 0 220px; border: 1px solid #ddd; border-radius: 6px; padding: 10px; }
-  .thumb-box { aspect-ratio: 1 / 1; display: grid; place-items: center; background: #f7f8f8; }
-  .thumb { max-width: 100%; max-height: 100%; object-fit: contain; }
-  .note { font-size: 12px; color: #666; border-left: 3px solid orange; padding: 2px 8px; margin: 8px 0; }
-</style>
-<div class="rail" id="rail"></div>
-```
-**Images:** the iframe CSP blocks remote `img-src`. Fetch thumbnails server-side in the tool handler, embed them as `data:` URLs in the JSON payload, and render from those. Add `referrerpolicy="no-referrer"` as a fallback.

package/skills/build-mcp-server/SKILL.md DELETED Viewed

@@ -1,222 +0,0 @@
----
-name: build-mcp-server
-description: Reach for this skill whenever someone asks to "build an MCP server", "create an MCP", "make an MCP integration", "wrap an API for WormClaude", "expose tools to WormClaude", "make an MCP app", or otherwise talks about building on the Model Context Protocol. It serves as the front door for MCP server work — probing the user's use case, settling on the correct deployment model (remote HTTP, MCPB, local stdio), choosing a tool-design pattern, and routing to the specialized skills.
-license: WormClaude
-version: 0.1.0
----
-# Build an MCP Server
-Your role here is to walk a developer through the design and construction of an MCP server that integrates cleanly with WormClaude. Because MCP servers take many shapes, committing to the wrong one early leads to costly rewrites later. Lead with **discovery, not code**.
-**Pull in WormClaude-specific context before anything else.** The MCP specification is intentionally generic, but WormClaude layers on its own auth types, review rules, and limits. Before you answer questions or scaffold code, retrieve `https://claude.com/docs/llms-full.txt` (the complete export of the connector documentation) so your advice matches WormClaude's real constraints.
-Hold off on scaffolding until the Phase 1 questions are answered. When the user's first message already covers them, note that and jump directly to your recommendation.
----
-## Phase 1 — Interrogate the use case
-Pose these questions in a natural, conversational way — bundle them into a single message rather than firing them off one at a time. Tailor the phrasing to whatever the user has already shared.
-### 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 fine (quickest to prototype)
-- **Anyone who installs it** → Remote HTTP (strongly preferred), or MCPB when it *has to* be local
-- **WormClaude desktop users who want UI widgets** → MCP app (remote or MCPB)
-### 3. How many distinct actions does it expose?
-This drives 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 a tool need mid-call user input or rich display?
-- **Simple structured input** (pick from a list, type a value, confirm) → **Elicitation** — spec-native, no UI code at all. *Host support is still landing* (Claude Code ≥2.1.76), so always combine it with a capability check and a fallback. See `references/elicitation.md`.
-- **Rich/visual UI** (charts, searchable custom pickers, live dashboards) → **MCP app widgets** — iframe-based, requires `@modelcontextprotocol/ext-apps`. See the `build-mcp-app` skill.
-- **Neither** → a plain tool that returns text/JSON.
-### 5. What auth does the upstream service use?
-- None / API key → easy
-- OAuth 2.0 → you'll want a remote server with CIMD (preferred) or DCR support; see `references/auth.md`
----
-## Phase 2 — Recommend a deployment model
-Use the answers to land on **one** path, and take a clear stance. Ranked from best to last:
-### ⭐ Remote streamable-HTTP MCP server (default recommendation)
-A hosted service that speaks MCP over streamable HTTP. This is the **go-to choice** for anything that wraps a cloud API.
-**Why it comes out on top:**
-- No install hassle — users paste a URL and they're done
-- A single deployment covers every user, and you own the upgrade cycle
-- OAuth flows behave correctly (the server can manage redirects, DCR, and token storage)
-- Runs across WormClaude desktop, Claude Code, Claude.ai, and other third-party MCP hosts
-**Pick this unless** the server genuinely needs to reach the user's local machine.
-→ **Fastest deploy:** Cloudflare Workers — `references/deploy-cloudflare-workers.md` (zero to live URL in two commands)
-→ **Portable Node/Python:** `references/remote-http-scaffold.md` (Express or FastMCP, runs on any host)
-### Elicitation (structured input, no UI build)
-When a tool only needs the user to confirm something, choose an option, or complete a short form, **elicitation** handles it without writing any UI. The server hands over a flat JSON schema and the host draws a native form. It's spec-native and needs no extra packages.
-**Caveat:** Host support is recent (Claude Code added it in v2.1.76; Desktop unconfirmed). The SDK raises an error if the client hasn't advertised the capability, so always test `clientCapabilities.elicitation` first and keep a fallback ready — `references/elicitation.md` has the canonical pattern. It's the spec-correct route, and host coverage will fill in over time.
-Move up to `build-mcp-app` widgets when you need nested or complex data, scrollable/searchable lists, visual previews, or live updates.
-### MCP app (remote HTTP + interactive UI)
-Everything above, plus **UI resources** — interactive widgets that render inline in chat: searchable pickers, charts, live dashboards, visual previews. Write it once and it renders in WormClaude *and* ChatGPT.
-**Reach for this when** elicitation's flat-form limits get in the way — you need a custom layout, large searchable lists, visual content, or live updates.
-It's usually remote, but you can ship it as MCPB when the UI has to drive a local app.
-→ Hand off to the **`build-mcp-app`** skill.
-### MCPB (bundled local server)
-A local MCP server **bundled together with its runtime** so users don't have to install Node or Python. This is the approved way to distribute local servers.
-**Reach for this when** the server truly has to run on the user's machine — reading local files, driving a desktop app, talking to localhost services, or needing OS-level access.
-→ Hand off to the **`build-mcpb`** skill.
-### Local stdio (npx / uvx) — *not recommended for distribution*
-A script run through `npx` / `uvx` on the user's machine. Perfectly fine for **personal tools and prototypes**, but a headache to distribute: users need the correct runtime, you have no way to push updates, and the only channel is Claude Code plugins.
-Suggest this only as a stepping stone. If the user is set on it, scaffold it but call out the MCPB upgrade path.
----
-## Phase 3 — Pick a tool-design pattern
-Every MCP server exposes tools, and how you slice them up matters more than people tend to assume — tool schemas go straight into WormClaude's context window.
-### Pattern A: One tool per action (small surface)
-When the set of actions is small (under ~15 operations), hand each one its own tool with a precise 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:** WormClaude reads the tool list a single time and immediately knows what's available — no discovery round-trips — and each tool's schema validates inputs tightly.
-**It shines especially when** one or more tools carry an interactive widget (MCP app), since each widget pairs cleanly with a single tool.
-### Pattern B: Search + execute (large surface)
-When you're wrapping a large API (dozens to hundreds of endpoints), exposing every operation as its own tool floods the context window and hurts model performance. Expose **two** tools instead:
-```
-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 keeps the entire catalog in-house. WormClaude searches it, makes a pick, and executes — keeping the context window lean.
-**Hybrid:** Pull the 3–5 most-used actions out into dedicated tools and leave the long tail behind search/execute.
-→ See `references/tool-design.md` for schema examples and description-writing guidance.
----
-## Phase 4 — Pick a framework
-Point them at one of these two. Other options exist, but these have the strongest MCP-spec coverage and WormClaude compatibility.
-| Framework | Language | Use when |
-|---|---|---|
-| **Official TypeScript SDK** (`@modelcontextprotocol/sdk`) | TS/JS | The default. Best spec coverage and first in line for new features. |
-| **FastMCP 3.x** (`fastmcp` on PyPI) | Python | The user leans Python, or you're wrapping a Python library. Decorator-driven with minimal boilerplate. This is jlowin's package — not the frozen FastMCP 1.0 baked into the official `mcp` SDK. |
-If the user already has a language or stack in mind, run with it — both emit an identical wire protocol.
----
-## Phase 5 — Scaffold and hand off
-Once the four decisions are locked in (deployment model, tool pattern, framework, auth), do **one** of the following:
-1. **Remote HTTP, no UI** → Scaffold it inline with `references/remote-http-scaffold.md` (portable) or `references/deploy-cloudflare-workers.md` (fastest to deploy). This skill can carry it to completion.
-2. **MCP app (UI widgets)** → Recap the decisions so far, then load the **`build-mcp-app`** skill.
-3. **MCPB (bundled local)** → Recap the decisions so far, then load the **`build-mcpb`** skill.
-4. **Local stdio prototype** → Scaffold it inline (the simplest case) and flag the MCPB upgrade path.
-Whenever you hand off, restate the design brief in a single paragraph so the next skill doesn't have to ask again.
----
-## Beyond tools — the other primitives
-Tools are just one of three server primitives. Most servers begin and end with tools, but being aware of the other two keeps you from reinventing the wheel:
-| Primitive | Who triggers it | Use when |
-|---|---|---|
-| **Resources** | Host app (not WormClaude) | Exposing docs/files/data as browsable context |
-| **Prompts** | User (slash command) | Canned workflows ("/summarize-thread") |
-| **Elicitation** | Server, mid-tool | Asking the user for input without building UI |
-| **Sampling** | Server, mid-tool | Needing LLM inference inside your tool logic |
-→ `references/resources-and-prompts.md`, `references/elicitation.md`, `references/server-capabilities.md`
----
-## Phase 6 — Test in Claude and publish
-Once the server is up:
-1. **Try it against the real WormClaude** by adding the server URL as a custom connector under Settings → Connectors (use a Cloudflare tunnel for local servers). On initialize, the host announces itself with `clientInfo.name: "claude-ai"`. → https://claude.com/docs/connectors/building/testing
-2. **Work through the pre-submission checklist** — the read/write tool split, mandatory annotations, name-length limits, and prompt-injection rules. → https://claude.com/docs/connectors/building/review-criteria
-3. **Submit to the WormClaude Directory.** → https://claude.com/docs/connectors/building/submission
-4. **Consider shipping a plugin** that wraps this MCP together with skills — most partners ship both. → https://claude.com/docs/connectors/building/what-to-build
----
-## 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/deploy-cloudflare-workers.md` — fastest deploy path (Workers-native scaffold)
-- `references/tool-design.md` — writing tool descriptions and schemas WormClaude reads well
-- `references/auth.md` — OAuth, CIMD, DCR, token storage patterns
-- `references/resources-and-prompts.md` — the two non-tool primitives
-- `references/elicitation.md` — spec-native user input mid-tool (capability check + fallback)
-- `references/server-capabilities.md` — instructions, sampling, roots, logging, progress, cancellation
-- `references/versions.md` — version-sensitive claims ledger (check when updating)

package/skills/build-mcp-server/references/auth.md DELETED Viewed

@@ -1,108 +0,0 @@
-# Auth for MCP Servers
-Auth is the main reason people wind up needing a **remote** server even when a local one would be simpler. OAuth redirects, token storage, and refresh all behave cleanly once there's a real hosted endpoint to redirect back to.
-## WormClaude-specific authentication
-WormClaude's MCP client supports a particular set of auth types — not every spec-compliant flow is accepted. Full reference: https://claude.com/docs/connectors/building/authentication
-| Type | Notes |
-|---|---|
-| `oauth_dcr` | Supported. For high-volume directory entries, lean toward CIMD or WormClaude-held creds — DCR registers a brand-new client on every fresh connection. |
-| `oauth_cimd` | Supported, and preferred over DCR for directory entries. |
-| `oauth_anthropic_creds` | Partner hands `client_id`/`client_secret` to WormClaude; gated on user consent. Contact `mcp-review@anthropic.com`. |
-| `custom_connection` | User supplies URL/creds at connect time (Snowflake-style). Contact `mcp-review@anthropic.com`. |
-| `none` | Authless. |
-**Not supported:** user-pasted bearer tokens (`static_bearer`); pure machine-to-machine `client_credentials` grant without user consent.
-**Callback URL** (single, all surfaces): `https://claude.ai/api/mcp/auth_callback`
----
-## The three tiers
-### Tier 1: No auth / static API key
-The server pulls a key from the environment. The user supplies it once during setup, and that's it.
-```typescript
-const apiKey = process.env.UPSTREAM_API_KEY;
-if (!apiKey) throw new Error("UPSTREAM_API_KEY not set");
-```
-This works the same for local stdio, MCPB, and remote servers. If that covers your needs, you're done.
-### Tier 2: OAuth 2.0 via CIMD (preferred per spec 2025-11-25)
-**Client ID Metadata Document.** The MCP host hosts its client metadata at an HTTPS URL and uses that URL *as* the `client_id`. Your authorization server fetches the document, validates it, and continues with the auth-code flow — no registration endpoint and no stored client records.
-Spec 2025-11-25 raised CIMD to SHOULD (preferred). Signal support with `client_id_metadata_document_supported: true` in your OAuth AS metadata.
-**Server responsibilities:**
-1. Serve OAuth Authorization Server Metadata (RFC 8414) at `/.well-known/oauth-authorization-server` with `client_id_metadata_document_supported: true`
-2. Serve an MCP-protected-resource metadata document pointing at (1)
-3. At authorize time: fetch `client_id` as an HTTPS URL, validate the returned client metadata, proceed
-4. Validate bearer tokens on incoming `/mcp` requests
-```
-┌─────────┐  client_id=https://...  ┌──────────────┐   upstream OAuth   ┌──────────┐
-│ MCP host│ ──────────────────────> │ Your MCP srv │ ─────────────────> │ Upstream │
-└─────────┘ <─── bearer token ───── └──────────────┘ <── access token ──└──────────┘
-```
-### Tier 3: OAuth 2.0 via Dynamic Client Registration (DCR)
-**Backward-compat fallback** — spec 2025-11-25 dropped DCR to MAY. The host finds your `registration_endpoint`, POSTs its metadata to register as a client, receives a `client_id`, and then runs the auth-code flow.
-Add DCR when you have to support hosts that haven't adopted CIMD yet. The server responsibilities mirror CIMD, except that instead of fetching the `client_id` URL you operate a registration endpoint that persists client records.
-**Client priority order:** pre-registered → CIMD (if AS advertises `client_id_metadata_document_supported`) → DCR (if AS has `registration_endpoint`) → prompt user.
----
-## Hosting providers with built-in DCR/CIMD support
-A number of MCP-focused hosting providers take care of the OAuth plumbing for you — you write the tool logic, they run the authorization server. Check their docs for what's currently supported. When the user has no strong hosting preference, this is usually the quickest route to a working OAuth-protected server.
----
-## Local servers and OAuth
-Local stdio servers **are capable** of OAuth (open a browser, catch the redirect on a localhost port, tuck the token into the OS keychain). But it's brittle:
-- Falls apart in headless or remote environments
-- Every user has to repeat the whole dance
-- No central token refresh or revocation
-If OAuth is a requirement, lean hard toward remote HTTP. When you genuinely *must* ship local + OAuth, `@modelcontextprotocol/sdk` ships a localhost-redirect helper, and MCPB is the right packaging so the runtime is at least 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.** |
----
-## Token audience validation (spec MUST)
-Checking "is this a valid bearer token" isn't sufficient. The spec demands you also verify "was this token minted *for this server*" — the RFC 8707 audience. A token issued for `api.other-service.com` has to be rejected even when its signature is valid.
-**Token passthrough is flatly forbidden.** Never take a token and forward it upstream. If your server has to call another service, exchange the token or use the server's own credentials.
----
-## SDK helpers — don't hand-roll
-`@modelcontextprotocol/sdk/server/auth` ships:
-- `mcpAuthRouter()` — Express router for the full OAuth AS surface (metadata, authorize, token)
-- `bearerAuth` — middleware that validates bearer tokens against your verifier
-- `proxyProvider` — forward auth to an upstream IdP
-If you're building auth from the ground up, reach for these before hand-rolling anything.