# Developer Protocol **Server:** fema-mcp-server **Version:** 0.5.1 **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.18` **Engines:** Bun ≥1.4.0, Node ≥24.0.0 **MCP SDK:** `@modelcontextprotocol/server` ^2.4.0 **Zod:** ^4.6.7 > **Read the framework docs first:** `node_modules/@cyanheads/mcp-ts-core/CLAUDE.md` contains the full API reference — builders, Context, error codes, exports, patterns. This file covers server-specific conventions only. --- ## Core Rules - **DuckDB dependency hold:** Keep `@duckdb/node-api` at `^1.5.6-r.2` until [mcp-ts-core#800](https://github.com/cyanheads/mcp-ts-core/issues/800) is resolved. Framework 0.13.18 excludes `PRAGMA_SHOW` from its SQL plan allowlist, so DuckDB 2 rejects `SHOW ` on canvas tables. - **Logic throws, framework catches.** Tool/resource handlers are pure — throw on failure, no `try/catch`. Plain `Error` is fine; the framework catches, classifies, and formats. Use error factories (`notFound()`, `validationError()`, etc.) when the error code matters. - **Use `ctx.log`** for request-scoped logging. No `console` calls. - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly. - **Need input the caller didn't supply?** `return ctx.requestInput(...)` and read `ctx.inputs` when the handler is re-entered. Never `await` for user input mid-handler. - **Secrets in env vars only** — never hardcoded. - **Cut noise.** No speculative abstractions, unused options, or guards for states the framework already prevents. - **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed and close it. Do both — a comment without a close leaves stale issues open; a close without a comment leaves no record of what shipped. The comment is for future readers — state the concrete changes, not the conversation that produced them. --- ## Patterns ### Tool ```ts import { tool, z } from '@cyanheads/mcp-ts-core'; export const femaSearchDisasters = tool('fema_search_disasters', { description: 'Search federal disaster declarations by state, incident type, declaration type, and date range.', annotations: { readOnlyHint: true, openWorldHint: true }, input: z.object({ state: z.string().length(2).optional().describe('Two-letter US state code (e.g. TX)'), limit: z.number().int().min(1).max(1000).default(20).describe('Max results (1–1000)'), }), output: z.object({ declarations: z.array(z.object({ disasterNumber: z.number().describe('Unique FEMA disaster number'), declarationTitle: z.string().describe('Official disaster title'), state: z.string().describe('Two-letter state code'), })).describe('Matching disaster declarations'), count: z.number().describe('Total matching records'), }), async handler(input, ctx) { const results = await getOpenFemaService().searchDisasters(input, ctx); ctx.log.info('Disaster search completed', { state: input.state, count: results.count }); return results; }, format: (result) => [{ type: 'text', text: result.declarations.map(d => `**${d.disasterNumber}**: ${d.declarationTitle} (${d.state})`).join('\n'), }], }); ``` ### Resource ```ts import { resource, z } from '@cyanheads/mcp-ts-core'; import { notFound } from '@cyanheads/mcp-ts-core/errors'; export const femaDisasterResource = resource('fema://disaster/{disasterNumber}', { description: 'Summary for a specific FEMA disaster declaration by disaster number.', params: z.object({ disasterNumber: z.string().describe('FEMA disaster number') }), async handler(params, ctx) { const disaster = await getOpenFemaService().getDisaster(Number(params.disasterNumber), ctx); if (!disaster) throw notFound(`Disaster ${params.disasterNumber} not found`, { disasterNumber: params.disasterNumber }); return disaster; }, }); ``` ### Prompt ```ts import { prompt, z } from '@cyanheads/mcp-ts-core'; export const reviewCode = prompt('review_code', { description: 'Review code for issues and best practices.', args: z.object({ code: z.string().describe('Code to review'), language: z.string().optional().describe('Programming language'), }), generate: (args) => [ { role: 'user', content: { type: 'text', text: `Review this ${args.language ?? ''} code:\n${args.code}` } }, ], }); ``` ### Server config ```ts // src/config/server-config.ts — lazy-parsed, separate from framework config import { z } from '@cyanheads/mcp-ts-core'; import { parseEnvConfig } from '@cyanheads/mcp-ts-core/config'; // Each dataset carries its own API version, so a trailing /v on the configured URL is dropped. const toApiRoot = (url: string) => url.replace(/\/+$/, '').replace(/\/v\d+$/, ''); const ServerConfigSchema = z.object({ baseUrl: z.url().default('https://www.fema.gov/api/open').transform(toApiRoot).describe('OpenFEMA API root, without a version segment'), requestTimeoutMs: z.coerce.number().default(30000).describe('HTTP request timeout in milliseconds'), enableCanvasDrop: z.stringbool().default(false).describe('Enable destructive removal of tables and views from a DataCanvas'), }); let _config: z.infer | undefined; export function getServerConfig() { _config ??= parseEnvConfig(ServerConfigSchema, { baseUrl: 'FEMA_BASE_URL', requestTimeoutMs: 'FEMA_REQUEST_TIMEOUT_MS', enableCanvasDrop: 'FEMA_ENABLE_CANVAS_DROP', }); return _config; } ``` `parseEnvConfig` maps Zod schema paths → env var names so errors name the environment variable, not the internal property. Throws `ConfigurationError`, which the framework prints as a clean startup banner. For env booleans use `z.stringbool()`, never `z.coerce.boolean()` — `Boolean("false")` is `true`, so a coerced flag can't be disabled through the environment. `z.stringbool()` parses `true/false/1/0/yes/no/on/off` and rejects anything else, so `=false` actually disables. ### Server identity and instructions `createApp()` forwards its machine identity to the SDK's `initialize` response and the server manifest (`/.well-known/mcp.json`). Keep both fields aligned to the hyphenated repository name: ```ts await createApp({ name: 'my-mcp-server', title: 'my-mcp-server', instructions: 'Use shortcut alpha for the most common case.', // session-level context }); ``` `instructions` is optional server-level orientation, sent on every `initialize` as session-level context. Use it for deployment guidance (connection aliases, regional notes, scope hints) instead of repeating the same context across tool descriptions. Client adoption is uneven, but there's no downside when set. --- ## Context The entry point declares `sessionMode: 'stateless'`; a meaningful `MCP_SESSION_MODE` overrides it. The framework schema default `auto` resolves to stateful. If adding `ctx.requestInput`, require stateful mode for 2025-era HTTP clients. Release service-owned watchers, sockets, and timers through `createApp({ teardown })`. Handlers receive a unified `ctx` object. Key properties: | Property | Description | |:---------|:------------| | `ctx.log` | Request-scoped logger — `.debug()`, `.info()`, `.notice()`, `.warning()`, `.error()`. Auto-correlates requestId, traceId, tenantId. Dual-sink: Pino **and** `notifications/message` to the client, so treat it as client-visible. | | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any JSON-serializable value; reads return its JSON form (a `Date` comes back as an ISO string). | | `ctx.enrich` | Success-path agent context (empty-result notices, query echo, pagination totals) — `ctx.enrich(...)` or `.notice()` / `.total()` / `.echo()` / `.truncated()`. Reaches `structuredContent` and `content[]`; lands only when the definition declares an `enrichment` block (no-op otherwise). | | `ctx.content` | Non-text content blocks — `.image(data, mimeType)`, `.audio(data, mimeType)`, or `ctx.content(block)` for a raw block. Prepended to `content[]` after `format()`; never enters `structuredContent`. | | `ctx.signal` | `AbortSignal` for cancellation. | | `ctx.requestId` | Request ID shared by the call's logs and its error envelope's `data.requestId`. | | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. | --- ## Errors Handlers throw — the framework catches, classifies, and formats. Error contracts also accept `severity` and `thrownBy: 'service'`. Mark service-produced reasons so the linter checks handler-local reasons without reporting false unthrown entries. The framework fills a declared recovery hint whenever an error carries its reason without its own hint; `RequestCancelled` is a baseline code and needs no contract entry. **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. The framework puts the matching hint on the wire automatically (`data.recovery.hint`, mirrored into `content[]` text); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`) bubble freely and don't need declaring. ```ts import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors'; errors: [ { reason: 'no_match', code: JsonRpcErrorCode.NotFound, when: 'No item matched the query', recovery: 'Broaden the query or check the spelling and try again.' }, ], async handler(input, ctx) { const item = await db.find(input.id); if (!item) throw ctx.fail('no_match', `No item ${input.id}`); return item; } ``` **Declare contracts inline on each tool.** The contract is part of the tool's public surface — one file should give the full picture. Don't extract a shared `errors[]` constant; per-tool repetition is the intended cost of locality. **Fallback (no contract entry fits):** throw via factories or plain `Error`. ```ts // Error factories — explicit code import { notFound, serviceUnavailable } from '@cyanheads/mcp-ts-core/errors'; throw notFound('Item not found', { itemId }); throw serviceUnavailable('API unavailable', { url }, { cause: err }); // Plain Error — framework auto-classifies from message patterns throw new Error('Item not found'); // → NotFound throw new Error('Invalid query format'); // → ValidationError // McpError — when no factory exists for the code import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors'; throw new McpError(JsonRpcErrorCode.DatabaseError, 'Connection failed', { pool: 'primary' }); ``` See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference. --- ## Structure ```text src/ index.ts # createApp() entry point config/ server-config.ts # Server-specific env vars (Zod schema) services/ canvas/ # DataCanvas service (DuckDB spillover) openfema/ # OpenFEMA REST API client and service, case-insensitive name matcher mcp-server/ tools/ markdown-table.ts # Shared Markdown table cell/row renderer response-budget.ts # 100,000-character page budget shared by row-returning tools tools/definitions/ fema-search-disasters.tool.ts # Search disaster declarations fema-get-disaster.tool.ts # Get single disaster by number fema-get-public-assistance.tool.ts # PA funded project records fema-get-housing-assistance.tool.ts # IA housing data (owners/renters) fema-search-nfip.tool.ts # NFIP Claims with DuckDB canvas spillover fema-dataframe-describe.tool.ts # List canvas tables/columns fema-dataframe-query.tool.ts # SQL SELECT against canvas tables fema-dataframe-drop.tool.ts # Gated removal of canvas tables/views fema-query-dataset.tool.ts # Generic OData escape hatch resources/definitions/ fema-disaster.resource.ts # fema://disaster/{disasterNumber} ``` --- ## Naming | What | Convention | Example | |:-----|:-----------|:--------| | Files | kebab-case with suffix | `search-docs.tool.ts` | | Tool/resource/prompt names | snake_case | `search_docs` | | Directories | kebab-case | `src/services/doc-search/` | | Descriptions | Single string or template literal, no `+` concatenation | `'Search items by query and filter.'` | --- ## Skills Two skill trees live at the project root, written for different readers: | Tree | For | Written by | |:-----|:----|:-----------| | `framework-skills/` | The agent developing this server — framework skills (`metadata.audience: external`) plus any development-time skills of the server's own | `init` and the `maintenance` sync (framework skills); you (your own) | | `skills/` | The agents that install the server and call its tools — tool chains, identifier sources, gates | You, deliberately, with the `add-skill` skill. Absent by default; usually none is needed | Development skills are modular instructions. Read them directly when a task matches — e.g., `framework-skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry. Their directory is deliberately not `skills/`: Claude Code and Codex auto-load a plugin's root `skills/`, so a server that ships `.claude-plugin/` or `.codex-plugin/` would hand them to every agent that installs it. A published skill in root `skills/` reaches plugin installs and the `.mcpb` bundle as-is, ships in the npm package and the Docker image, and reaches MCP clients when the server opts in with `createApp({ skills: 'skills' })`. `lint:packaging` validates the tree. **Agent skill directory:** Copy `framework-skills/` into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `framework-skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory. Available skills: | Skill | Purpose | |:------|:--------| | `setup` | Post-init project orientation | | `design-mcp-server` | Design tool surface, resources, and services for a new server | | `add-tool` | Scaffold a new tool definition | | `add-app-tool` | Scaffold an MCP App tool + paired UI resource | | `add-resource` | Scaffold a new resource definition | | `add-prompt` | Scaffold a new prompt definition | | `add-skill` | Author a skill the server publishes in root `skills/` for the agents that use it — when one earns its place, structure, validation, delivery | | `add-service` | Scaffold a new service integration | | `add-test` | Scaffold test file for a tool, resource, or service | | `field-test` | Exercise tools/resources/prompts with real inputs, verify behavior, report issues | | `tool-defs-analysis` | Read-only audit of MCP definition language across the surface — voice, leaks, defaults, recovery hints, output descriptions | | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation | | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase | | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping | | `git-wrapup` | Commit the work stack, then version metadata; open the release PR. No tag or push to main. | | `release-pr-review` | Review an open release PR, land fixes as ordinary commits, and reconcile its body. | | `release-and-publish` | Fast-forward the release PR, tag, push, and publish to npm, MCP Registry, GitHub Releases, and Docker. | | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs | | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents | | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI | | `report-issue-local` | File a bug or feature request against this server's own repo via `gh` CLI | | `api-auth` | Auth modes, scopes, JWT/OAuth | | `api-canvas` | DataCanvas: register tabular data, run SQL, export, plus the `spillover()` helper for big result sets — Tier 3 opt-in | | `api-config` | AppConfig, parseConfig, env vars | | `api-context` | Context interface, RequestContext, logger, state, multi-round-trip input | | `api-errors` | McpError, JsonRpcErrorCode, error patterns | | `api-linter` | Definition linter rule catalog — invoked by `bun run lint:mcp` and `devcheck` | | `api-services` | LLM, Speech, Graph services | | `api-testing` | createMockContext, test patterns | | `api-utils` | Formatting, parsing, security, pagination, scheduling, telemetry helpers | | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules | | `api-workers` | Cloudflare Workers runtime | | `techniques` | Catalog of reusable response/data-shaping patterns (outline-on-overflow, etc.) | | `api-mirror` | MirrorService: persistent self-refreshing local mirror (embedded SQLite + FTS5) of a bulk upstream dataset — Tier 3 opt-in | **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `framework-skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase. When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`). --- ## Commands **Runtime:** Scripts use Bun's native TypeScript execution — `bun run ` is the standard invocation. `npm run ` also works (npm delegates to bun). | Command | Purpose | |:--------|:--------| | `bun run build` | Compile TypeScript | | `bun run rebuild` | Clean + build | | `bun run clean` | Remove build artifacts | | `bun run devcheck` | Lint + format + typecheck + security + changelog sync | | `bun run audit:fix` | Upgrade vulnerable dependencies within existing ranges; first response to a transitive advisory. | | `bun run audit:refresh` | Delete the lockfile and reinstall as a last resort after `audit:fix`, targeted update, and dedupe. Re-resolves every ranged dependency. | | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) | | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity, `.mcpbignore` coverage, plugin manifests, the published `skills/` tree (run by devcheck) | | `bun run list-skills` | Print the skill registry | | `bun run tree` | Generate directory structure doc | | `bun run vocabulary:build` | Regenerate `src/services/openfema/name-vocabulary.ts`, the name snapshot the case-insensitive filters resolve against, from live OpenFEMA | | `bun run format` | Auto-fix formatting (safe fixes only) | | `bun run format:unsafe` | Also apply Biome's unsafe autofixes — review the diff; they can change behavior | | `bun run test` | Run tests (Vitest — use `bun run test`, not `bun test`) | | `bun run start:stdio` | Production mode (stdio) | | `bun run start:http` | Production mode (HTTP) | | `bun run changelog:build` | Regenerate `CHANGELOG.md` from `changelog/*.md` | | `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) | | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install | --- ## Bundling GitHub Actions carries only `.github/workflows/codeql.yml`; verification runs locally. CodeQL default setup must remain off for the file workflow to run. `bun run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. `mcpb pack` reads `.mcpbignore`, not `.gitignore`, so every root path the bundle must not ship — source, tests, docs, caches, logs, agent docs, plugin manifests, gitignored local files — needs a root-anchored line there (`/docs/`, never `docs/`, which also strips `node_modules/*/docs/`); `lint:packaging` names each missing or unanchored line. Root `skills/` ships on purpose. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips four classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: agent docs at a dependency's package root (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md` — a `skills/` deeper in a package, such as the MCP SDK's runtime `dist/ext/skills/`, ships); platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on; node-gyp build output beside a `binding.gyp`, which records the packing machine's paths — compiled `*.node` addons stay; and build-only package files — the framework's `changelog/`, `scripts/`, `templates/`, `CLAUDE.md`, `AGENTS.md`, and config bases, and `better-sqlite3`'s `deps/` and `src/` C sources. `tests/scripts/bundle-agent-docs.test.ts` pins the agent-doc selector the cleaner and `lint:packaging` share. The bundle ships without the DuckDB native, so `manifest.json` pins `CANVAS_PROVIDER_TYPE` to `none`: Claude Desktop runs inline-only, `fema_search_nfip` pages claims by `offset`, and `fema_dataframe_describe` and `fema_dataframe_query` return `canvas_unavailable`. Every other deployment gets DataCanvas by default — after loading `.env`, `src/index.ts` sets `duckdb` when the variable is unset, blank, or an unsubstituted `${…}` placeholder; `none` disables it. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly. **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match. Every bundle option is wired as `${user_config.}`, and optional string options declare `default: ""`. **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `framework-skills/polish-docs-meta/references/readme.md`. --- ## Changelog Directory-based, grouped by minor series via the `.x` semver-wildcard convention. Source of truth: `changelog/.x/.md` (e.g. `changelog/0.1.x/0.1.0.md`) — one file per release, shipped in the npm package. At release, author the per-version file with a concrete version and date, then run `bun run changelog:build` to regenerate the rollup. `changelog/template.md` is a **pristine format reference** — never edited or moved; read it for the frontmatter + section layout when scaffolding. `CHANGELOG.md` is a **navigation index** (header + link + summary per version), regenerated by `bun run changelog:build` — devcheck hard-fails on drift; never hand-edit it. Each per-version file opens with YAML frontmatter: ```markdown --- summary: "One-line headline, ≤350 chars" # required — powers the rollup index breaking: false # optional — true flags breaking changes security: false # optional — true ONLY for a source-code security fix, never a dependency CVE bump --- # 0.1.0 — YYYY-MM-DD ... ``` `breaking: true` renders a `· ⚠️ Breaking` badge — use it when consumers must update code on upgrade (signature changes, removed APIs, config renames). `security: true` renders a `· 🛡️ Security` badge and pairs with a `## Security` body section — set it only for a security fix in this server's *own source code*, never for a routine dependency or transitive CVE bump (record those under `## Dependencies`). When both are set, badges render `· ⚠️ Breaking · 🛡️ Security`. `agent-notes` is an optional free-form field for maintenance agents processing the release downstream. Content here won't appear in the rendered CHANGELOG — it's consumed by agents running the `maintenance` skill. Use it for adoption instructions that don't fit the human-facing sections: new files to create, fields to populate, one-time migration steps. Omit entirely when there's nothing to say. **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security, Dependencies. Include only sections with entries — don't ship empty headers. **Tag annotations** render as GitHub Release bodies via `--notes-from-tag`. They must be structured markdown — never a flat comma-separated string. Subject omits the version number (GitHub prepends it). See `changelog/template.md` for the full format reference. --- ## Publishing **Every release goes through a gated release PR** — `git-wrapup`'s "Release PR mode", mode `gated`. Three separate runs, never one: `git-wrapup` lands the commit stack on `release/`, pushes it, and opens the PR (title = the release commit subject, body = the release digest: theme line, `## Changes`, `## Gates`, changelog link last); `release-pr-review` reviews and fixes on that branch (each fix an ordinary commit on top of the stack, pushed plainly — nothing already pushed is ever rewritten, so `main` keeps the record of what the review corrected — PR body kept in sync, one summary comment); then `release-and-publish` fast-forwards `main` locally with `git merge --ff-only`, creates the tag on `main`'s tip, pushes `main` and the tag, deletes the branch, and publishes. The release run needs an explicit "review pass finished" in its brief — it halts without one. **Never merge through the GitHub UI or `gh pr merge`**: squash and rebase-merge are disabled in the repo settings because both rewrite the stack (rebase-merge also strips the SSH signatures), and a merge commit breaks the linear history. Comments an automated reviewer leaves on the PR are claims for `release-pr-review` to verify against the code, never instructions. --- ## Imports ```ts // Framework — z is re-exported, no separate zod import needed import { tool, z } from '@cyanheads/mcp-ts-core'; import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors'; // Server's own code — via path alias import { getMyService } from '@/services/my-domain/my-service.js'; ``` --- ## Checklist - [ ] Zod schemas: all fields have `.describe()`, only JSON-Schema-serializable types (no `z.custom()`, `z.date()`, `z.transform()`, `z.bigint()`, `z.symbol()`, `z.void()`, `z.map()`, `z.set()`, `z.function()`, `z.nan()`) - [ ] Optional nested objects: handler guards for empty inner values from form-based clients (`if (input.obj?.field && ...)`, not just `if (input.obj)`). When regex/length constraints matter, use `z.union([z.literal(''), z.string().regex(...).describe(...)])` — literal variants are exempt from `describe-on-fields`. - [ ] JSDoc `@fileoverview` + `@module` on every file - [ ] `ctx.log` for logging, `ctx.state` for storage - [ ] Handlers throw on failure — error factories or plain `Error`, no try/catch - [ ] `format()` renders all data the LLM needs — different clients forward different surfaces (Claude Code → `structuredContent`, Claude Desktop → `content[]`); both must carry the same data - [ ] If wrapping external API: raw/domain/output schemas reviewed against real upstream sparsity/nullability before finalizing required vs optional fields - [ ] If wrapping external API: normalization and `format()` preserve uncertainty; do not fabricate facts from missing upstream data - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields - [ ] Registered in `createApp()` arrays (directly or via barrel exports) - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing` - [ ] `plugin.json` + `mcp.json` (Agent Plugins 1.0.0 — read by Codex, Cursor, GitHub Copilot, VS Code, Kiro) populated — `plugin.json` `name` = the unscoped repo name; `version`, `description`, `author`, `homepage`, `repository`, `license`, `keywords` from `package.json`; no other top-level field. `mcp.json` holds one `"type": "stdio"` entry keyed by the unscoped name, `npx -y @cyanheads/fema-mcp-server`, and the same fixed `env` as `.codex-plugin/mcp.json`. Neither file carries a user-supplied variable; `.codex-plugin/plugin.json` keeps `"mcpServers": "./.codex-plugin/mcp.json"`. - [ ] `.codex-plugin/plugin.json` populated from `package.json`; `interface.displayName` is the bare repository name, and `interface.shortDescription` matches the package description. - [ ] `.codex-plugin/mcp.json` uses the bare repository name as its key; user-supplied variables are forwarded through `env_vars`, never empty `env` entries. - [ ] `.claude-plugin/plugin.json` metadata matches `package.json`; the inline `mcpServers` key is the bare repository name. User-supplied variables use declared `userConfig` options and `${user_config.