@cyanheads/mcp-ts-core 0.13.10 → 0.13.11

package/framework-skills/code-simplifier/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Cleanup pass that edits the working tree — over a session's uncommitted changes, or a named path or whole codebase. Reads `git diff` (or the named target) and simplifies, consolidates, and aligns code with the existing codebase — modernize syntax, cut unnecessary complexity and slop, consolidate duplicated logic, catch efficiency issues. Not a bug hunt: defects are reported, not fixed. Use after a substantive working session, or when asked to clean up, simplify, reduce slop, consolidate, modernize, tighten up, de-slop, or scan a codebase. For `@cyanheads/mcp-ts-core` projects, includes specific transformations for tool/resource/prompt definitions, the ctx pattern, error factories, and framework idioms.
 metadata:
   author: cyanheads
-  version: "1.6"
+  version: "1.7"
   audience: external
   type: workflow
 ---
@@ -75,7 +75,7 @@ Evaluate the changes across these dimensions. Not every dimension applies to eve
 - **Gate** — `bun run devcheck` plus the test suite (`bun run test`) is the project gate in Phase 2 step 4 and Phase 4 step 5.
 - **Framework-provided utilities** — Before hand-rolling, check `src/utils/` and `src/errors/` in the project and `node_modules/@cyanheads/mcp-ts-core/` for framework exports: pagination helpers, schema builders, retry primitives, and the `ATTR_*` OTel attribute constants are framework-provided. Raw OTel attribute keys should be `ATTR_*` imports from `@cyanheads/mcp-ts-core/utils`.
 - **Error throwing patterns** — Prefer framework error factories (`McpError`, `validationError`, `notFound`, `httpErrorFromResponse`) over raw `throw new Error()`. Tool handlers should throw — the framework catches, classifies, and instruments.
-- **Error codes** — `InvalidParams` only for malformed JSON-RPC params shape. `ValidationError` for domain validation. `NotFound` for missing entities. Don't conflate them.
+- **Error codes** — `InvalidParams` for input the schema rejects (the framework raises it before the handler runs) and for an upstream 400 mapped by `httpErrorFromResponse`. `ValidationError` for a business rule the schema cannot express. `NotFound` for missing entities. Don't conflate them.
 - **Ctx usage** — Use `ctx.log`, `ctx.state`, `ctx.enrich` — don't reach for global loggers or request-scoped storage directly. The `ctx` pattern carries tenant scope and OTel context.
 - **Zod schemas** — Every tool input/output field needs `.describe()`. Zod 4 requires `z.record(z.string(), z.string())` not `z.record(z.string())`. Use `.optional()` rather than `.nullish()` unless null is semantically distinct from absent.
 - **Tool annotations** — `readOnlyHint`, `idempotentHint`, `openWorldHint` should reflect reality. A read-only tool with `readOnlyHint: false` gives clients the wrong picture.

package/framework-skills/field-test/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: field-test
 description: >
-  Exercise tools, resources, and prompts against a live HTTP server via MCP JSON-RPC over curl. Starts the server, surfaces the catalog, runs real and adversarial inputs, measures every call (bytes, token estimate, wall-clock) and weighs the catalog, and produces a tight report with concrete findings and numbered follow-up options. Use after adding or modifying definitions, or when the user asks to test, try out, or verify their MCP surface.
+  Exercise tools, resources, and prompts against a live HTTP server via MCP JSON-RPC over curl. Starts the server, surfaces the catalog, runs real and adversarial inputs, measures every call (bytes, token estimate, wall-clock) and weighs the catalog, renders app tools' views in a headless MCP Apps host, and produces a tight report with concrete findings and numbered follow-up options. Use after adding or modifying definitions, or when the user asks to test, try out, or verify their MCP surface.
 metadata:
   author: cyanheads
-  version: "2.18"
+  version: "2.19"
   audience: external
   type: debug
 ---
@@ -413,6 +413,7 @@ Treat any hit as a `ux` finding in the report. The authoring rule lives under *T
 | Tool declared an `errors: [...]` contract | Error contract (tool): trigger ≥1 declared failure mode. Verify `result.structuredContent.error.code` matches the contract entry, `result.structuredContent.error.data.reason` is the declared reason (only present when the handler threw an `McpError` — `ctx.fail` always does, plain `throw new Error(...)` does not), and `content[0].text` is actionable. Reasons declared but unreachable from any input are dead contract entries. |
 | Resource declared an `errors: [...]` contract | Error contract (resource): trigger ≥1 declared failure mode by reading a URI that exercises it. Resources re-throw errors at the JSON-RPC level — verify `error.code` matches the contract entry and `error.data.reason` is the declared reason. (Resources don't use the `result.isError` envelope — they fail the request itself.) |
 | Mutator (write/update/delete/append/patch verbs, or `destructiveHint: true`) | Mutator response observability: run an intentionally-ambiguous input (typo path, wrong ID, already-deleted target). Confirm the response carries enough state (pre/post values, state-change discriminator) for the agent to detect intent-effect divergence without re-fetching. |
+| `_meta.ui.resourceUri` on the tool (an app tool) | View rendering: Step 6. The curl calls see only the `format()` text and the view's raw HTML; whether the view runs is visible only when it is rendered. |
 
 **Resources.** Happy path, not-found URI (use a syntactically valid but non-existent ID — e.g., substitute a fake ID into the URI template), `list` if defined, pagination if used.
 **Prompts.** Happy path, defaults omitted, skim message quality.
@@ -430,7 +431,7 @@ Use `TaskCreate` — one task per definition. Mark complete as you go. Don't bat
 
 For each call, capture: input sent, the `⏱` line (bytes, split, ms), response (trim huge payloads to files), whether `isError: true` appeared, anything surprising (slow response, parity drift, unhelpful text, crash).
 
-When a call surprises you — slow, hangs, returns terse output, surfaces an unhelpful error — run `. /tmp/<project-name>-field-test-<ID>.sh && mcp_log <log>` to tail the server log. The pino startup banner, request handler errors, upstream API call traces, and rate-limit warnings all land in the per-server log (read via `mcp_log`) rather than coming back through `mcp_call`. Don't guess at runtime behavior from response text alone.
+When a call surprises you — slow, hangs, returns terse output, surfaces an unhelpful error — run `. /tmp/<project-name>-field-test-<ID>.sh && mcp_log <log>` to tail the server log. The pino startup banner, request handler errors, upstream API call traces, and rate-limit warnings all land in the per-server log (read via `mcp_log`) rather than coming back through `mcp_call`. Don't guess at runtime behavior from response text alone. To count upstream requests from the log, start the server with `MCP_LOG_RATE_LIMIT_THRESHOLD=0`: by default the logger drops a message repeated past its per-window threshold and reports it later as a `Suppressed N` line, so a count read mid-run comes up short.
 
 **Interpreting responses**
 
@@ -441,17 +442,60 @@ When a call surprises you — slow, hangs, returns terse output, surfaces an unh
 - JSON-RPC `error` only appears for protocol issues (bad session, malformed envelope, unknown method).
 - `mcp_call` already strips SSE framing. Pipe to `jq` for readability.
 
-### 6. Tear down
+### 6. Render app views
+
+Skip this step when no tool carries `_meta.ui.resourceUri`. List the app tools:
+
+```bash
+. /tmp/<project-name>-field-test-<ID>.sh
+mcp_call <url> <sid> tools/list '' <protocol> | jq -r '.result.tools[] | select(._meta.ui.resourceUri) | .name'
+```
+
+Render each one with `mcp-ts-core app-render` against the Step 1 server. It connects as an MCP Apps client, calls the tool, loads the `ui://` view into headless `chrome-headless-shell` inside the double-iframe sandbox and CSP the MCP Apps spec prescribes, plays the host half of the protocol, and writes `report.json` plus screenshots under `--out`. No window opens.
+
+```bash
+bunx @cyanheads/mcp-ts-core app-render --url <url> --tool <app_tool> --args '<happy-path JSON>' \
+  --click '<selector>' --out /tmp/<project-name>-field-test-<ID>-apps/<app_tool> > /dev/null; echo "exit=$?"
+jq '{initialized, failure, toolError, errors, cspViolations, size, steps, text}' \
+  /tmp/<project-name>-field-test-<ID>-apps/<app_tool>/report.json
+```
+
+The report also goes to stdout; read the file instead, since `messages` grows with every exchange. Pass one `--click` per control whose handler matters (a screenshot follows each), run a second pass with `--theme dark` when the view applies host theming, and add `--stream-input` when it renders partial input. Fill, wait-for, and evaluate steps need `renderAppTool` from `@cyanheads/mcp-ts-core/testing/apps` in a script; it returns the same report.
+
+**A setup failure exits 1** with `app-render: <reason>` on stderr and writes no report:
+
+| Reason names | Meaning |
+|:-------------|:--------|
+| A missing optional peer | `@modelcontextprotocol/client` or `@modelcontextprotocol/ext-apps` is not installed. With the user's go-ahead, `bun add -d` it; otherwise record app views as `skipped — requires <package>`. |
+| No browser, or a browser path | No usable `chrome-headless-shell`. With the user's go-ahead, `npx @puppeteer/browsers install chrome-headless-shell@stable --path ~/.cache/puppeteer` (without `--path` it installs into the working directory, where the host never looks), or pass an existing build with `--browser`; otherwise record `skipped — requires chrome-headless-shell`. Never point `--browser` at a desktop browser. |
+| The server is unreachable | Wrong URL, or the Step 1 server died — `mcp_log <log>`. |
+| No such tool, no UI resource, an unreadable UI resource, or a `_meta.ui.csp` entry | A server finding (`bug`): the tool is unregistered, its `resourceUri` is missing, `resources/read` on the `ui://` URI fails, or a CSP domain entry is not a plain origin. |
+
+**A view failure exits 0**: the run reached the browser, and the report says what the view did. Read every field:
+
+- **`initialized`** — the view completed `ui/initialize`. `false`, with `failure` naming the timeout, means the view never connected: a script threw before `app.connect()` (see `errors`), the CSP blocked its SDK import (see `cspViolations`), or the HTML does not use the ext-apps `App` class. `bug`.
+- **`toolError`** — the tool call failed at the protocol level, so the view received `tool-cancelled` instead of a result.
+- **`errors`** — uncaught exceptions and console errors, each tagged with its `frame`. A `view` entry is the server's own UI code: `bug`. `sandbox`, `host`, and `unknown` entries come from the host pages, not the server; report them apart from the server's findings.
+- **`cspViolations`** — loads the view's CSP blocked, as `directive` + `blockedURI`. An origin the view needs but its resource's `_meta.ui.csp` omits (`resourceDomains` for scripts, styles, images, fonts, and media; `connectDomains` for fetch and WebSocket; `frameDomains` for iframes) is a `bug`, because a spec-conformant host blocks the same load. `blockedURI: "eval"` means the view calls `eval` or `new Function`, which the policy never allows. An `eval` entry whose `sourceURL` points into the ext-apps bundle (`app-with-deps.js`) is Zod's guarded capability probe, which catches the refusal, not the view's own code, so it is no finding.
+- **`messages`** — every message between view and host, in order, with its `direction`. A healthy run opens `view-to-host` `ui/initialize` → `ui/notifications/initialized`, then `host-to-view` `ui/notifications/tool-input` → `ui/notifications/tool-result`. A click that should reach the server shows a `view-to-host` `tools/call` and its `host-to-view` response; an `error` there is the server's rejection, or the host refusing a tool whose `_meta.ui.visibility` excludes `app`. Requests that need a user or a model (`ui/message`, `ui/open-link`, `ui/update-model-context`, `ui/request-display-mode`) are recorded and acknowledged — check their params carry what the control meant to send.
+- **`steps`** — one entry per click and screenshot; `ok: false` with `No element matches <selector>` means the control is missing from the rendered view.
+- **`text` and the screenshots** — the rendered text after the steps, and the PNGs (`final.png`, one per click). Open them: a blank, unstyled, clipped, or unreadable-in-dark view is a `ux` finding even when every field above is clean, and so is data in the tool result's `structuredContent` that the view never shows.
+- **`size`** — the view's last `ui/notifications/size-changed`. Absent means the view never reports its size, so a host cannot fit its frame to it: `ux`.
+
+The harness stops the browser and deletes its profile itself; the `--out` directories are removed in Step 7.
+
+### 7. Tear down
 
 ```bash
 . /tmp/<project-name>-field-test-<ID>.sh
 mcp_stop <pid> <log> <port>
+rm -rf /tmp/<project-name>-field-test-<ID>-apps
 rm -f /tmp/<project-name>-field-test-<ID>.sh
 ```
 
-Kills the background server and its port-holding child, removes the server log, then removes the helper script itself. Do this *before* writing the report so nothing leaks into the next session. Pass the `port` — it's what turns "the wrapper PID is gone" into "the socket is actually free." If `mcp_stop` warns the port is still held or the PID survived SIGKILL, note it in the report and proceed — don't block on a zombie process, but do say which PID to kill.
+Kills the background server and its port-holding child, removes the server log and any app-render output, then removes the helper script itself. Do this *before* writing the report so nothing leaks into the next session. Pass the `port` — it's what turns "the wrapper PID is gone" into "the socket is actually free." If `mcp_stop` warns the port is still held or the PID survived SIGKILL, note it in the report and proceed — don't block on a zombie process, but do say which PID to kill.
 
-### 7. Report
+### 8. Report
 
 Four sections. Tight. The user should be able to skim the summary, scan the numbers, read details only for what matters, and act on numbered options.
 
@@ -514,5 +558,6 @@ End with:
 - [ ] **If a resource declared an `errors: [...]` contract:** ≥1 declared failure mode triggered; top-level JSON-RPC `error.code` and `error.data.reason` verified against the contract entry
 - [ ] **If any tool truncates, caps, or spills its output:** truncation forced; disclosure + a retrieval path (cursor, offset, selector, canvas handle) verified
 - [ ] External-state / auth-gated tools handled explicitly (run, skip, or confirm)
-- [ ] Server stopped (port confirmed free); server log and helper script removed
+- [ ] **If any tool carries `_meta.ui.resourceUri`:** each view rendered with `app-render` (Step 6); `initialized`, `errors`, `cspViolations`, the message log, and the screenshots checked; a missing peer or browser recorded as skipped, not as a server finding
+- [ ] Server stopped (port confirmed free); server log, app-render output, and helper script removed
 - [ ] Report: summary paragraph → size & latency table → grouped findings → numbered options

package/framework-skills/git-wrapup/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Land working-tree changes as logical commits — the work grouped by concern, topped by a release commit (version bump, changelog, regenerated artifacts). The work commits land first, then the version bump, verification, and the release commit on top. Stops at "committed locally on main" — or, when the project releases through a release PR, at "release branch pushed, PR open". No tag, no push to main, no publish: the release-and-publish skill merges, tags, and ships from here. Distilled from the git_wrapup_instructions protocol.
 metadata:
   author: cyanheads
-  version: "1.27"
+  version: "1.28"
   audience: external
   type: workflow
 ---
@@ -173,7 +173,7 @@ security: false    # true ONLY for a security fix in this server's own source
 ---
 ```
 
-**Write `summary:` LAST, derived from the body you just wrote — never independently.** It is the line most readers see: `changelog:build` copies it verbatim into the `CHANGELOG.md` rollup, which ships inside the npm tarball, and in release PR mode it opens the PR body. Written from recollection rather than from the body, it reliably names a mechanism that was never built or a target that was never fixed, while the body beside it stays correct. After writing it, re-read the body and confirm every claim in the summary appears there. Derived-from-the-body means the facts come from the body — not that every body item appears: it is one headline, and comma-stitching every change into an inventory near the 350-char cap is the failure mode.
+**Write `summary:` LAST, derived from the body you just wrote — never independently.** It is the line most readers see: `changelog:build` copies it verbatim into the `CHANGELOG.md` rollup, the entry file ships inside the npm tarball (`changelog/` is in `package.json` `files`; the rollup is not), and in release PR mode it opens the PR body. Written from recollection rather than from the body, it reliably names a mechanism that was never built or a target that was never fixed, while the body beside it stays correct. After writing it, re-read the body and confirm every claim in the summary appears there. Derived-from-the-body means the facts come from the body — not that every body item appears: it is one headline, and comma-stitching every change into an inventory near the 350-char cap is the failure mode.
 
 **`security:` is a source-code signal — not a dependency-CVE signal.** Set `security: true` only when this release fixes a vulnerability or adds hardening in code *this server ships*. A dependency or transitive CVE bump — even one that clears an advisory (`bun audit` going 1 → 0) — is routine maintenance: record it under `## Dependencies` with the advisory ID and leave the flag `false`. The `🛡️ Security` badge answers "does the server itself have a vuln"; a dep bump must not trip it.
 

package/framework-skills/orchestrations/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Pick and run a multi-phase workflow that chains foundational task skills (`git-wrapup`, `release-and-publish`, `maintenance`, `field-test`, `setup`, etc.) end-to-end. Routes user intent to a workflow file under `workflows/` — greenfield builds, maintenance + release, field-test + fix, or known-work + release. Single source for the universal rules (no commits without authorization, no destructive git, no marketing language), the orchestrator posture (own the goal, ground sub-agents in primary sources, verify against the goal), and the sub-agent strategy (orient block, parallel fanout, isolation, normalization) that apply across every workflow. Sub-agents are an optional capability — workflows run linearly when fanout isn't available.
 metadata:
   author: cyanheads
-  version: "1.12"
+  version: "1.13"
   audience: external
   type: workflow
 ---

package/framework-skills/orchestrations/workflows/greenfield-build.md

@@ -4,7 +4,7 @@ description: >
   Workflow: scaffold one or more new MCP server projects from `bunx @cyanheads/mcp-ts-core init` through design → build → polish → first public release. Each phase invokes a foundational skill end-to-end; this file is the sequencing and gates, not the procedural detail. Read `../SKILL.md` first for the universal rules and sub-agent strategy.
 metadata:
   author: cyanheads
-  version: "1.3"
+  version: "1.4"
   audience: external
   type: workflow
 ---
@@ -85,7 +85,7 @@ Sub-agent runs `bunx @cyanheads/mcp-ts-core init <name>`, follows the `setup` sk
 ### Phase 2: Initial commit
 Sub-agent verifies `gh repo view --json visibility` returns `PRIVATE` (or has explicit user authorization for public) before push. Tag is `v0.1.0`.
 
-A private repository without GitHub Advanced Security has no code scanning, so the scaffolded `.github/workflows/codeql.yml` fails on every push until the repo is public. Keep the file. GitHub registers the workflow on the first push, and that push already runs it. Right after this push, disable it with `gh workflow disable CodeQL` and delete that failed run with `gh run delete <id>`. It stays disabled through the private checkpoints. Phase 18 turns it back on.
+A private repository without GitHub Advanced Security has no code scanning, so the scaffolded `.github/workflows/codeql.yml` fails on every push until the repo is public. Keep the file. GitHub registers the workflow on the first push, and that push already runs it. Right after this push, disable it with `gh workflow disable CodeQL` and cancel that run with `gh run cancel <id>` before it fails. Keep the cancelled run: deleting a workflow's only run unregisters the workflow, and the next push registers it again as active and runs it. It stays disabled through the private checkpoints; after each checkpoint push, confirm that `gh api repos/<owner>/<repo>/actions/workflows` still shows it `disabled_manually`. Phase 18 turns it back on.
 
 ### Checkpoint commits (Phases 2, 5, 10, 16)
 Plain commits on `main`, pushed to the private repo. They follow `git-wrapup`'s step 3 conventions — grouped by concern, staged and committed by pathspec, one- or two-line bodies — and nothing else from that skill: no version bump, no changelog entry, no release branch or PR. Run end to end, `git-wrapup` bumps the version and, when the project declares a release PR mode, moves the work to `release/<version>` and opens a PR; that belongs to Phase 17 alone. Only Phase 2 tags (`v0.1.0`, annotated, `--cleanup=whitespace`).

package/framework-skills/polish-docs-meta/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Finalize documentation and project metadata for a ship-ready MCP server. Use after implementation is complete, tests pass, and devcheck is clean. Safe to run at any stage — each step checks current state and only acts on what still needs work.
 metadata:
   author: cyanheads
-  version: "2.21"
+  version: "2.22"
   audience: external
   type: workflow
 ---
@@ -95,6 +95,7 @@ Key sync points:
 - `description` matches `package.json` description
 - `environmentVariables` reflect the server config Zod schema — server-specific required vars in both entries, transport vars only in HTTP entry
 - Two package entries: one for stdio, one for HTTP (if both transports supported)
+- npm entries carry `runtimeHint: "npx"` and no `packageArguments` — a registry client runs the package's bin, which ignores `run start:*` arguments; the HTTP entry fixes `MCP_TRANSPORT_TYPE` as `"value": "http"`, never as a `default`. `lint:packaging` fails the arguments and a missing or wrong transport value
 
 ### 7. GitHub Repository Metadata
 
@@ -204,7 +205,7 @@ If the project ships as an `.mcpb` bundle for Claude Desktop (check for `manifes
 **`package.json` scripts:**
 
 - `bundle` — builds the `.mcpb` (`mcpb pack`, then `scripts/clean-mcpb.ts` prunes dev deps and strips dependency-shipped agent docs)
-- `lint:packaging` — validates `manifest.json` ↔ `server.json` env var consistency, version parity for `manifest.json`, the plugin manifests, and the README badge, and the Dockerfile's stages: a stage not pinned to `$BUILDPLATFORM` must not run JavaScript while building — no `bun run build`, `bun -e`, or script, and no `bun install` once `bunfig.toml` is in the stage (run by `devcheck`, which gates the step on `manifest.json`, a plugin manifest, `.mcpbignore`, `README.md`, or `Dockerfile`)
+- `lint:packaging` — validates `manifest.json` ↔ `server.json` env var consistency, version parity for `manifest.json`, the plugin manifests, and the README badge, the launch shape of `server.json` npm entries (no `run start:*` arguments; a `streamable-http` entry sets `MCP_TRANSPORT_TYPE` to `"value": "http"`), and the Dockerfile's stages: a stage not pinned to `$BUILDPLATFORM` must not run JavaScript while building — no `bun run build`, `bun -e`, or script, and no `bun install` once `bunfig.toml` is in the stage (run by `devcheck`, which gates the step on `manifest.json`, a plugin manifest, `.mcpbignore`, `README.md`, `Dockerfile`, or `server.json`)
 
 **Cross-file consistency:**
 
@@ -270,7 +271,7 @@ Both must pass clean.
 - [ ] Agent protocol file accurate — no stale template content, real examples, structure matches reality
 - [ ] `.env.example` in sync with server config schema
 - [ ] `package.json` metadata complete (`description`, `mcpName`, `repository`, `author`, `keywords`, `engines`, `packageManager`)
-- [ ] `server.json` matches official MCP schema, versions synced, env vars current
+- [ ] `server.json` matches official MCP schema, versions synced, env vars current; npm entries launch through `npx` with no arguments, and the HTTP entry fixes `MCP_TRANSPORT_TYPE` as `"value": "http"`
 - [ ] GitHub repo description matches `package.json` description; topics ↔ keywords in sync
 - [ ] `bunfig.toml` present
 - [ ] Changelog current — either monolithic `CHANGELOG.md` (hand-edited, Keep a Changelog) or directory-based (`changelog/<minor>.x/<version>.md` + rollup regenerated and in sync)

package/framework-skills/polish-docs-meta/references/server-json.md

@@ -31,12 +31,8 @@ The manifest uses the official MCP schema. A typical server has two package entr
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "@org-name/my-mcp-server",
-      "runtimeHint": "bun",
+      "runtimeHint": "npx",
       "version": "1.0.0",
-      "packageArguments": [
-        { "type": "positional", "value": "run" },
-        { "type": "positional", "value": "start:stdio" }
-      ],
       "environmentVariables": [
         {
           "name": "ACME_API_KEY",
@@ -60,12 +56,8 @@ The manifest uses the official MCP schema. A typical server has two package entr
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "@org-name/my-mcp-server",
-      "runtimeHint": "bun",
+      "runtimeHint": "npx",
       "version": "1.0.0",
-      "packageArguments": [
-        { "type": "positional", "value": "run" },
-        { "type": "positional", "value": "start:http" }
-      ],
       "environmentVariables": [
         {
           "name": "ACME_API_KEY",
@@ -73,6 +65,12 @@ The manifest uses the official MCP schema. A typical server has two package entr
           "format": "string",
           "isRequired": true
         },
+        {
+          "name": "MCP_TRANSPORT_TYPE",
+          "description": "Selects the HTTP transport.",
+          "format": "string",
+          "value": "http"
+        },
         {
           "name": "MCP_HTTP_HOST",
           "description": "The hostname for the HTTP server.",
@@ -140,9 +138,9 @@ Each entry in `packages[]` describes one way to install and run the server:
 | `registryType` | Yes | `"npm"` for npm packages. |
 | `registryBaseUrl` | Yes | `"https://registry.npmjs.org"` for npm. |
 | `identifier` | Yes | The npm package name (e.g., `@org/my-server`). |
-| `runtimeHint` | No | `"bun"` or `"node"`. Tells clients which runtime to use. |
+| `runtimeHint` | No | `"npx"` for npm packages, the registry's runner for npm. A client that runs the hint as the command launches `<runtimeHint> <identifier>@<version>`, so `"node"` or `"bun"` there names a file path that does not exist. |
 | `version` | Yes | Package version. Must match top-level `version`. |
-| `packageArguments` | No | Array of `{ "type": "positional", "value": "..." }` args passed after the package command. |
+| `packageArguments` | No | Arguments appended to the launch command. Omit it: a framework server's bin reads none (see Package Arguments). |
 | `environmentVariables` | No | Array of env var descriptors (see below). |
 | `transport` | Yes | `{ "type": "stdio" }` or `{ "type": "streamable-http", "url": "..." }` |
 
@@ -154,28 +152,28 @@ Each entry in `packages[]` describes one way to install and run the server:
 | `description` | Yes | Human-readable purpose. |
 | `format` | No | `"string"` (default). |
 | `isRequired` | No | `true` if the server won't start without it. |
-| `default` | No | Default value if not set. |
+| `default` | No | Value used when the user sets none. The user can change it. |
+| `value` | No | Fixed value the client always sets; the user cannot change it. Use it for a setting the entry depends on, such as `MCP_TRANSPORT_TYPE` on the HTTP entry. |
 
 ### Package Arguments
 
-The `packageArguments` array tells clients what args to pass when running the package. For `bun run start:stdio`:
-
-```json
-"packageArguments": [
-  { "type": "positional", "value": "run" },
-  { "type": "positional", "value": "start:stdio" }
-]
-```
+A registry client launches an npm entry as `npx <identifier>@<version> <packageArguments>`, with the entry's `environmentVariables` set. That runs the package's bin (`dist/index.js`), not an npm script, and the bin reads no arguments: it takes its transport from `MCP_TRANSPORT_TYPE`. Leave `packageArguments` out. A `run` + `start:stdio` / `start:http` pair is npm-script syntax that reaches the bin as argv it ignores, and `lint:packaging` rejects it on any npm entry.
 
 ### Transport Patterns
 
-**stdio only** (one package entry):
+**stdio only** (one package entry). stdio is the framework's default transport, so the entry needs no transport variable:
 
 ```json
 "transport": { "type": "stdio" }
 ```
 
-**stdio + HTTP** (two package entries): One entry with `start:stdio` and `{ "type": "stdio" }`, another with `start:http` and `{ "type": "streamable-http", "url": "http://localhost:{port}/mcp" }`. The HTTP entry includes additional env vars for host, port, endpoint path, and auth mode.
+**stdio + HTTP** (two package entries): the stdio entry above, plus an entry with `{ "type": "streamable-http", "url": "http://localhost:{port}/mcp" }` that fixes the transport in its `environmentVariables`:
+
+```json
+{ "name": "MCP_TRANSPORT_TYPE", "description": "Selects the HTTP transport.", "format": "string", "value": "http" }
+```
+
+Use `value`, not `default`: a default is user-editable, and without the variable the server starts on stdio. `lint:packaging` fails a `streamable-http` npm entry that does not set it to `"http"`. The HTTP entry also carries env vars for host, port, endpoint path, and auth mode.
 
 ## Generating / Updating
 
@@ -187,9 +185,9 @@ If `server.json` doesn't exist, create it from the surface area audit. If it exi
 4. Set `repository` from `package.json` repository URL, with `"source": "github"`
 5. Create package entries — one for stdio, one for HTTP (if the server supports both transports)
 6. Set `identifier` to the npm package name from `package.json`
-7. Set `runtimeHint` to `"bun"`
-8. Set `packageArguments` for each transport (`start:stdio`, `start:http`)
-9. Populate `environmentVariables` — server-specific required vars in both entries, transport-specific vars (host, port, endpoint, auth) only in the HTTP entry, `MCP_LOG_LEVEL` in both
+7. Set `runtimeHint` to `"npx"`
+8. Leave out `packageArguments` — the bin takes its transport from `MCP_TRANSPORT_TYPE`, not from arguments
+9. Populate `environmentVariables` — server-specific required vars in both entries, `MCP_TRANSPORT_TYPE` with `"value": "http"` and the transport-specific vars (host, port, endpoint, auth) only in the HTTP entry, `MCP_LOG_LEVEL` in both
 10. All three `version` fields (top-level, and each package entry) must be identical and match `package.json`
 
 ## Keeping in Sync

package/framework-skills/release-and-publish/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Ship a release end-to-end across every registry the project targets (npm, MCP Registry, GitHub Releases for `.mcpb` bundles, GHCR). Runs the final verification gate, fast-forwards `main` when the release rode a release PR, creates the annotated tag on the commit `main` now points at, pushes commits and tags, then publishes to each applicable destination. Assumes git wrapup (version bumps, changelog, commit stack — and in release PR mode, the pushed branch and open PR) is already complete — this skill is the post-wrapup merge + tag + publish workflow. Retries transient network failures on publish steps; halts with a partial-state report when retries are exhausted or the failure is terminal.
 metadata:
   author: cyanheads
-  version: "2.23"
+  version: "2.24"
   audience: external
   type: workflow
 ---
@@ -280,7 +280,7 @@ docker buildx build --platform linux/amd64,linux/arm64 \
   --push .
 ```
 
-No stage built for the target platform may run JavaScript: the non-native leg of the multi-arch build runs it under QEMU, where bun >= 1.4 aborts with a JavaScriptCore allocator assertion (`qemu: uncaught target signal 6`) and no image publishes for either architecture. That covers `bun run build`, and also a `bun install` that sees `bunfig.toml` — its security scanner runs as a Bun program and the install fails with `NoSecurityScanData`. The templates keep every such step in stages that start `FROM --platform=$BUILDPLATFORM` — the build stage, and a `deps` stage that cross-installs production dependencies with `--os`/`--cpu` and runs `scripts/install-otel.ts` — so the production stage's only Bun calls are `HEALTHCHECK` and `CMD`. `bun run lint:packaging` (check 15, part of `devcheck`) fails a Dockerfile that breaks this and names the line. npm, the MCP Registry, and the GitHub Release have all published by this step, so the recovery is a follow-up patch release rather than a retry — confirm the lint passes before building, not after.
+No stage built for the target platform may run JavaScript: the non-native leg of the multi-arch build runs it under QEMU, where bun >= 1.4 aborts with a JavaScriptCore allocator assertion (`qemu: uncaught target signal 6`) and no image publishes for either architecture. That covers `bun run build`, and also a `bun install` that sees `bunfig.toml` — its security scanner runs as a Bun program and the install fails with `NoSecurityScanData`. The templates keep every such step in stages that start `FROM --platform=$BUILDPLATFORM` — the build stage, and a `deps` stage that cross-installs production dependencies with `--os`/`--cpu`, runs `scripts/install-otel.ts`, then runs `scripts/prune-musl-packages.ts` (Bun cannot filter optional dependencies by libc, so it deletes the musl variants the glibc runtime image never loads) — so the production stage's only Bun calls are `HEALTHCHECK` and `CMD`. `bun run lint:packaging` (check 15, part of `devcheck`) fails a Dockerfile that breaks this and names the line. npm, the MCP Registry, and the GitHub Release have all published by this step, so the recovery is a follow-up patch release rather than a retry — confirm the lint passes before building, not after.
 
 If the project uses a non-GHCR registry or a custom image name, respect the project's convention. If push fails with a 401/403, prompt the user to authenticate (`echo $GITHUB_TOKEN | docker login ghcr.io -u <OWNER> --password-stdin`) and retry. Halt on build failure or non-auth push failure.
 

package/framework-skills/release-pr-review/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Review pass on an open release PR (`release/<version>` → `main`) — the step between `git-wrapup` and `release-and-publish` when a project releases in gated release PR mode. Reads the PR's commit range through the `code-simplifier` lens plus a correctness review, verifies whatever an automated reviewer left on the PR, lands fixes as ordinary commits on top of the release branch and pushes it, keeps the PR body in sync with what ships, and leaves one summary comment. The only agent role that both edits and commits — and it never rewrites pushed history, tags, merges, touches `main`, or publishes.
 metadata:
   author: cyanheads
-  version: "1.7"
+  version: "1.8"
   audience: external
   type: workflow
 ---
@@ -84,14 +84,14 @@ A passing check is not an all-clear — it can pass while alerts stay open on th
 
 ```bash
 gh api "repos/<OWNER>/<REPO>/code-scanning/alerts?state=open&ref=refs/pull/<N>/merge" \
-  --jq '.[] | "\(.number) \(.rule.id) \(.most_recent_instance.ref) \(.most_recent_instance.analysis_key)"'
+  --jq '.[] | "\(.number) \(.rule.id) \(.most_recent_instance.ref) \(.most_recent_instance.category)"'
 ```
 
-Every alert ends the pass in a settled state: a real finding is fixed on the branch, a genuine false positive is dismissed with a stated reason. One trap sits between those two. **An alert that the branch has already fixed but that will not close is an analysis-key problem, not a dismissal decision.** An alert raised by the retired CodeQL default setup (`analysis_key` beginning `dynamic/`) can never close itself once the repository carries its own workflow, because an alert closes only when the *same* key re-scans the ref — the new key's scan reports zero results while the old alert stays open forever. None of the three dismissal reasons (`false positive`, `won't fix`, `used in tests`) is true of a real finding that has been fixed, and `won't fix` on a high-severity alert reads to anyone auditing the repository as a decision not to fix it. Delete the retired configuration's orphaned analyses instead, newest-first:
+Every alert ends the pass in a settled state: a real finding is fixed on the branch, a genuine false positive is dismissed with a stated reason. One trap sits between those two. **An alert that the branch has already fixed but that will not close is a category problem, not a dismissal decision.** GitHub re-evaluates an alert only through new analyses in the alert's own category (`most_recent_instance.category`), whichever workflow or setup uploads them. Once no current configuration uploads to that category, the fixed code is scanned only under other categories, where it reports zero results while the old alert stays open forever. The template CodeQL workflow uploads each language under `/language:<language>`, the category CodeQL default setup uses, so alerts default setup raised close normally, and default setup's earlier analyses share a set with the workflow's — neither orphaned nor deletable. The usual orphan is a retired category, such as the path-derived `.github/workflows/codeql.yml:analyze` an earlier workflow uploaded under. None of the three dismissal reasons (`false positive`, `won't fix`, `used in tests`) is true of a real finding that has been fixed, and `won't fix` on a high-severity alert reads to anyone auditing the repository as a decision not to fix it. Once the current workflow has analyzed the alert's ref under its own categories, delete the orphaned category's analyses on that ref instead, newest-first — only the most recent analysis of a set is deletable, and `confirm_delete` lets the last one go:
 
 ```bash
-gh api "repos/<OWNER>/<REPO>/code-scanning/analyses?per_page=100" \
-  --jq '.[] | select(.analysis_key | startswith("dynamic/")) | "\(.id) \(.created_at) \(.ref)"'
+gh api --paginate "repos/<OWNER>/<REPO>/code-scanning/analyses?ref=<REF>&per_page=100" \
+  --jq '.[] | select(.category == "<ORPHANED_CATEGORY>") | "\(.id) \(.created_at) \(.deletable)"'
 gh api -X DELETE "repos/<OWNER>/<REPO>/code-scanning/analyses/<ID>?confirm_delete=true"
 ```
 

package/framework-skills/setup/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Post-init orientation for an MCP server built on @cyanheads/mcp-ts-core. Use after running `@cyanheads/mcp-ts-core init` to understand the project structure, conventions, and skill sync model. Also use when onboarding to an existing project for the first time.
 metadata:
   author: cyanheads
-  version: "1.11"
+  version: "1.12"
   audience: external
   type: workflow
 ---
@@ -40,7 +40,7 @@ Dockerfile                                      # Starter multi-stage image
 .vscode/                                        # Recommended extensions + editor settings
 server.json                                     # MCP Registry publishing metadata
 changelog/template.md                           # Format reference for per-version changelog files
-scripts/                                        # build, clean, devcheck, lint-mcp, list-skills, build-changelog, tree, check-docs-sync
+scripts/                                        # Framework scripts (build, devcheck and its checks, lint-mcp, lint-packaging, Docker install-otel and prune-musl-packages, release-github, …), re-synced by `maintenance`
 framework-skills/                               # External skills copied from the package (source of truth)
 src/
   index.ts                                      # createApp() entry point

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cyanheads/mcp-ts-core",
-  "version": "0.13.10",
+  "version": "0.13.11",
   "mcpName": "io.github.cyanheads/mcp-ts-core",
   "description": "Agent-native TypeScript framework for MCP servers. Includes runtime infrastructure and agent skills for building, testing, and shipping servers.",
   "files": [
@@ -20,6 +20,7 @@
     "scripts/lint-mcp.ts",
     "scripts/lint-packaging.ts",
     "scripts/list-skills.ts",
+    "scripts/prune-musl-packages.ts",
     "scripts/release-github.ts",
     "scripts/tree.ts",
     "framework-skills/",
@@ -114,6 +115,11 @@
       "import": "./dist/testing/index.js",
       "default": "./dist/testing/index.js"
     },
+    "./testing/apps": {
+      "types": "./dist/testing/apps/index.d.ts",
+      "import": "./dist/testing/apps/index.js",
+      "default": "./dist/testing/apps/index.js"
+    },
     "./testing/fuzz": {
       "types": "./dist/testing/fuzz.d.ts",
       "import": "./dist/testing/fuzz.js",
@@ -197,12 +203,13 @@
     "publish-mcp": "mcp-publisher login github -token \"$(security find-generic-password -a \"$USER\" -s mcp-publisher-github-pat -w)\" && mcp-publisher publish"
   },
   "devDependencies": {
-    "@biomejs/biome": "2.5.14",
+    "@biomejs/biome": "2.5.15",
     "@cloudflare/vitest-pool-workers": "^0.22.0",
-    "@cloudflare/workers-types": "5.20260924.1",
-    "@duckdb/node-api": "^1.5.5-r.5",
-    "@hono/otel": "^1.1.2",
-    "@modelcontextprotocol/client": "^2.1.0",
+    "@cloudflare/workers-types": "5.20260930.2",
+    "@duckdb/node-api": "^1.5.6-r.1",
+    "@hono/otel": "^1.2.0",
+    "@modelcontextprotocol/client": "^2.2.0",
+    "@modelcontextprotocol/ext-apps": "^2.0.3",
     "@opentelemetry/api-logs": "^0.222.0",
     "@opentelemetry/exporter-logs-otlp-http": "^0.222.0",
     "@opentelemetry/exporter-metrics-otlp-http": "^0.222.0",
@@ -216,11 +223,11 @@
     "@opentelemetry/sdk-trace-node": "^2.11.0",
     "@opentelemetry/semantic-conventions": "^1.43.0",
     "@socketsecurity/bun-security-scanner": "^1.1.3",
-    "@supabase/supabase-js": "^2.117.1",
+    "@supabase/supabase-js": "^2.117.2",
     "@types/bun": "^1.4.2",
-    "@types/node": "26.6.2",
+    "@types/node": "26.6.3",
     "@types/papaparse": "^5.5.2",
-    "@types/sanitize-html": "^2.16.1",
+    "@types/sanitize-html": "^2.16.2",
     "@vitest/coverage-istanbul": "4.1.11",
     "@vitest/ui": "4.1.11",
     "better-sqlite3": "^13.0.3",
@@ -231,24 +238,24 @@
     "diff": "^9.0.0",
     "execa": "^10.0.1",
     "fast-check": "^4.10.2",
-    "fast-xml-parser": "^5.11.1",
-    "ignore": "^7.0.10",
+    "fast-xml-parser": "^5.11.2",
+    "ignore": "^7.0.11",
     "js-yaml": "^5.4.2",
     "linkedom": "^0.18.13",
     "node-cron": "^4.6.0",
-    "openai": "^7.23.0",
+    "openai": "^7.25.0",
     "papaparse": "^5.7.0",
     "partial-json": "^0.1.7",
     "pdf-lib": "^1.17.1",
     "pino-pretty": "^13.1.3",
     "repomix": "^1.18.1",
-    "sanitize-html": "^2.17.7",
-    "tsc-alias": "^1.9.5",
+    "sanitize-html": "^2.18.0",
+    "tsc-alias": "^1.9.7",
     "typedoc": "^0.28.20",
     "typescript": "^7.0.2",
     "typescript-v6": "npm:typescript@^6.0.3",
     "unpdf": "^1.8.1",
-    "vite": "8.3.0",
+    "vite": "8.3.1",
     "vitest": "^4.1.11"
   },
   "keywords": [
@@ -290,17 +297,19 @@
     "access": "public"
   },
   "dependencies": {
-    "@hono/node-server": "^2.1.1",
-    "@modelcontextprotocol/server": "^2.1.0",
+    "@hono/node-server": "^2.1.3",
+    "@modelcontextprotocol/server": "^2.2.0",
     "@opentelemetry/api": "^1.9.1",
-    "hono": "^4.13.9",
+    "hono": "^4.13.12",
     "jose": "^6.2.12",
     "pino": "^10.3.1",
     "zod": "^4.6.5"
   },
   "peerDependencies": {
-    "@duckdb/node-api": "^1.5.5-r.1",
+    "@duckdb/node-api": "^1.5.5-r.1 || ^1.5.6-r.1",
     "@hono/otel": "^1.1.2",
+    "@modelcontextprotocol/client": "^2.1.0",
+    "@modelcontextprotocol/ext-apps": "^2.0.0",
     "@opentelemetry/api-logs": "^0.222.0",
     "@opentelemetry/exporter-logs-otlp-http": "^0.222.0",
     "@opentelemetry/exporter-metrics-otlp-http": "^0.222.0",
@@ -339,6 +348,12 @@
     "@hono/otel": {
       "optional": true
     },
+    "@modelcontextprotocol/client": {
+      "optional": true
+    },
+    "@modelcontextprotocol/ext-apps": {
+      "optional": true
+    },
     "@opentelemetry/api-logs": {
       "optional": true
     },
@@ -428,12 +443,12 @@
     }
   },
   "overrides": {
-    "brace-expansion": "^2.1.3",
+    "brace-expansion": "^2.1.7",
     "postcss": "^8.5.23",
     "protobufjs": "^7.6.5",
     "sharp": "^0.35.3",
-    "fast-uri": "^3.1.6",
-    "ip-address": "^10.3.1",
+    "fast-uri": "^3.1.8",
+    "ip-address": "^10.7.1",
     "nanoid": "^3.3.18"
   }
 }