@cyanheads/epa-mcp-server 0.3.0 → 0.3.2

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 (41) hide show
  1. package/AGENTS.md +413 -0
  2. package/CLAUDE.md +91 -77
  3. package/Dockerfile +14 -7
  4. package/LICENSE +1 -1
  5. package/README.md +109 -97
  6. package/changelog/0.3.x/0.3.1.md +27 -0
  7. package/changelog/0.3.x/0.3.2.md +40 -0
  8. package/changelog/template.md +67 -43
  9. package/dist/config/server-config.d.ts +2 -2
  10. package/dist/config/server-config.d.ts.map +1 -1
  11. package/dist/config/server-config.js +6 -8
  12. package/dist/config/server-config.js.map +1 -1
  13. package/dist/index.js +2 -12
  14. package/dist/index.js.map +1 -1
  15. package/dist/mcp-server/tools/definitions/get-ejscreen.tool.d.ts +2 -1
  16. package/dist/mcp-server/tools/definitions/get-ejscreen.tool.d.ts.map +1 -1
  17. package/dist/mcp-server/tools/definitions/get-ejscreen.tool.js +1 -0
  18. package/dist/mcp-server/tools/definitions/get-ejscreen.tool.js.map +1 -1
  19. package/dist/mcp-server/tools/definitions/index.d.ts +12 -20
  20. package/dist/mcp-server/tools/definitions/index.d.ts.map +1 -1
  21. package/dist/mcp-server/tools/definitions/search-facilities.tool.d.ts +1 -6
  22. package/dist/mcp-server/tools/definitions/search-facilities.tool.d.ts.map +1 -1
  23. package/dist/mcp-server/tools/definitions/search-facilities.tool.js +0 -6
  24. package/dist/mcp-server/tools/definitions/search-facilities.tool.js.map +1 -1
  25. package/dist/mcp-server/tools/definitions/search-violations.tool.d.ts +3 -3
  26. package/dist/services/airnow/airnow-service.d.ts.map +1 -1
  27. package/dist/services/airnow/airnow-service.js +2 -2
  28. package/dist/services/airnow/airnow-service.js.map +1 -1
  29. package/dist/services/dmap/dmap-service.d.ts.map +1 -1
  30. package/dist/services/dmap/dmap-service.js +57 -41
  31. package/dist/services/dmap/dmap-service.js.map +1 -1
  32. package/dist/services/echo/echo-service.d.ts.map +1 -1
  33. package/dist/services/echo/echo-service.js +32 -10
  34. package/dist/services/echo/echo-service.js.map +1 -1
  35. package/dist/services/echo/types.d.ts +1 -0
  36. package/dist/services/echo/types.d.ts.map +1 -1
  37. package/dist/services/ejscreen/ejscreen-service.d.ts.map +1 -1
  38. package/dist/services/ejscreen/ejscreen-service.js +6 -8
  39. package/dist/services/ejscreen/ejscreen-service.js.map +1 -1
  40. package/package.json +16 -14
  41. package/server.json +4 -4
package/AGENTS.md ADDED
@@ -0,0 +1,413 @@
1
+ # Developer Protocol
2
+
3
+ **Server:** epa-mcp-server
4
+ **Version:** 0.3.2
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.6`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` ^2.0.0
8
+ **Zod:** ^4.6.5
9
+
10
+ > **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.
11
+
12
+ ---
13
+
14
+ ## What's Next?
15
+
16
+ When the user asks what's next or needs direction, suggest options based on the current project state. Common next steps:
17
+
18
+ 1. **Re-run the `setup` skill** — ensures CLAUDE.md, skills, structure, and metadata are populated and up to date with the current codebase
19
+ 2. **Run the `design-mcp-server` skill** — if the tool/resource surface hasn't been mapped yet, work through domain design
20
+ 3. **Add tools/resources/prompts** — scaffold new definitions using the `add-tool`, `add-app-tool`, `add-resource`, `add-prompt` skills
21
+ 4. **Add services** — scaffold domain service integrations using the `add-service` skill
22
+ 5. **Add tests** — scaffold tests for existing definitions using the `add-test` skill
23
+ 6. **Field-test definitions** — exercise tools/resources/prompts with real inputs using the `field-test` skill, get a report of issues and pain points
24
+ 7. **Run `devcheck`** — lint, format, typecheck, and security audit
25
+ 8. **Run the `security-pass` skill** — audit handlers for MCP-specific security gaps: output injection, scope blast radius, input sinks, tenant isolation
26
+ 9. **Run the `polish-docs-meta` skill** — finalize README, CHANGELOG, metadata, and agent protocol for shipping
27
+ 10. **Run the `maintenance` skill** — investigate changelogs, adopt upstream changes, and sync skills after `bun update --latest`
28
+
29
+ Tailor suggestions to what's actually missing or stale — don't recite the full list every time.
30
+
31
+ ---
32
+
33
+ ## Core Rules
34
+
35
+ - **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.
36
+ - **Use `ctx.log`** for request-scoped logging. No `console` calls.
37
+ - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
38
+ - **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.
39
+ - **Secrets in env vars only** — never hardcoded.
40
+ - **Cut noise.** No speculative abstractions, guards for states the framework prevents, or unused options.
41
+ - **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed before moving on. The comment is for future readers — state the concrete changes, not the conversation that produced them.
42
+
43
+ ---
44
+
45
+ ## Patterns
46
+
47
+ ### Tool
48
+
49
+ ```ts
50
+ import { tool, z } from '@cyanheads/mcp-ts-core';
51
+
52
+ export const searchItems = tool('search_items', {
53
+ description: 'Search inventory items by query.',
54
+ annotations: { readOnlyHint: true },
55
+ input: z.object({
56
+ query: z.string().describe('Search terms'),
57
+ limit: z.number().default(10).describe('Max results'),
58
+ }),
59
+ output: z.object({
60
+ items: z.array(z.object({
61
+ id: z.string().describe('Item ID'),
62
+ name: z.string().describe('Item name'),
63
+ })).describe('Matching items'),
64
+ }),
65
+ auth: ['inventory:read'],
66
+
67
+ async handler(input, ctx) {
68
+ const items = await findItems(input.query, input.limit);
69
+ ctx.log.info('Search completed', { query: input.query, count: items.length });
70
+ return { items };
71
+ },
72
+
73
+ // format() populates content[] — the markdown twin of structuredContent.
74
+ // Different clients read different surfaces (Claude Code → structuredContent,
75
+ // Claude Desktop → content[]); both must carry the same data.
76
+ // Enforced at lint time: every field in `output` must appear in the rendered text.
77
+ format: (result) => [{
78
+ type: 'text',
79
+ text: result.items.map(i => `**${i.id}**: ${i.name}`).join('\n'),
80
+ }],
81
+ });
82
+ ```
83
+
84
+ ### Resource
85
+
86
+ ```ts
87
+ import { resource, z } from '@cyanheads/mcp-ts-core';
88
+ import { notFound } from '@cyanheads/mcp-ts-core/errors';
89
+
90
+ export const itemData = resource('inventory://{itemId}', {
91
+ description: 'Fetch an inventory item by ID.',
92
+ params: z.object({ itemId: z.string().describe('Item identifier') }),
93
+ auth: ['inventory:read'],
94
+ async handler(params, ctx) {
95
+ const item = await ctx.state.get(`item/${params.itemId}`);
96
+ if (!item) throw notFound(`Item ${params.itemId} not found`, { itemId: params.itemId });
97
+ return item;
98
+ },
99
+ });
100
+ ```
101
+
102
+ ### Prompt
103
+
104
+ ```ts
105
+ import { prompt, z } from '@cyanheads/mcp-ts-core';
106
+
107
+ export const reviewCode = prompt('review_code', {
108
+ description: 'Review code for issues and best practices.',
109
+ args: z.object({
110
+ code: z.string().describe('Code to review'),
111
+ language: z.string().optional().describe('Programming language'),
112
+ }),
113
+ generate: (args) => [
114
+ { role: 'user', content: { type: 'text', text: `Review this ${args.language ?? ''} code:\n${args.code}` } },
115
+ ],
116
+ });
117
+ ```
118
+
119
+ ### Server config
120
+
121
+ ```ts
122
+ // src/config/server-config.ts — lazy-parsed, separate from framework config
123
+ import { z } from '@cyanheads/mcp-ts-core';
124
+ import { parseEnvConfig } from '@cyanheads/mcp-ts-core/config';
125
+
126
+ const ServerConfigSchema = z.object({
127
+ apiKey: z.string().describe('External API key'),
128
+ maxResults: z.coerce.number().default(100),
129
+ verboseLogging: z.stringbool().default(false).describe('Enable verbose logging'),
130
+ });
131
+
132
+ let _config: z.infer<typeof ServerConfigSchema> | undefined;
133
+ export function getServerConfig() {
134
+ _config ??= parseEnvConfig(ServerConfigSchema, {
135
+ apiKey: 'MY_API_KEY',
136
+ maxResults: 'MY_MAX_RESULTS',
137
+ verboseLogging: 'MY_VERBOSE_LOGGING',
138
+ });
139
+ return _config;
140
+ }
141
+ ```
142
+
143
+ `parseEnvConfig` maps Zod schema paths → env var names so errors name the variable (`MY_API_KEY`) not the path (`apiKey`). Throws `ConfigurationError`, which the framework prints as a clean startup banner.
144
+
145
+ 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.
146
+
147
+ ### Server identity and instructions
148
+
149
+ The canonical `createApp()` identity block is the unscoped repository name in both fields. Package description and website metadata derive from `package.json`; do not duplicate them here.
150
+
151
+ ```ts
152
+ await createApp({
153
+ name: 'epa-mcp-server',
154
+ title: 'epa-mcp-server',
155
+ instructions: 'Server-level orientation forwarded to the model on every initialize.',
156
+ });
157
+ ```
158
+
159
+ `instructions` is optional server-level orientation, sent on every `initialize` as session-level context. Use it for deployment guidance, data-vintage notes, scope limits, and cross-tool workflows instead of repeating the same context across tool descriptions.
160
+
161
+ ### Session posture and shutdown
162
+
163
+ EPA declares `sessionMode: 'stateless'` in `createApp()`. `MCP_SESSION_MODE` overrides that default when set to `auto`, `stateful`, or `stateless`; `auto` resolves to stateful. Empty strings and whole-value `${…}` placeholders use the server default. Tenant-scoped `ctx.state` storage is independent of sessions. If a future tool uses `ctx.requestInput`, require stateful HTTP with `{ default: 'stateful', require: 'stateful' }` for 2025-era clients.
164
+
165
+ Release service-owned watchers, sockets, and timers in `createApp({ teardown(core) })`. The hook runs after transport shutdown and before core storage and logging are disposed.
166
+
167
+ ---
168
+
169
+ ## Context
170
+
171
+ Handlers receive a unified `ctx` object. Key properties:
172
+
173
+ | Property | Description |
174
+ |:---------|:------------|
175
+ | `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. |
176
+ | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
177
+ | `ctx.requestInput` | Suspend and ask the caller for more input — `return ctx.requestInput({ inputRequests: { key: inputRequired.elicit({ message, requestedSchema }) } })`. Never returns; the handler is re-entered with the answers. Always present. |
178
+ | `ctx.inputs` | Reader over a retried request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped`. Empty on the first round. |
179
+ | `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). |
180
+ | `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`. |
181
+ | `ctx.signal` | `AbortSignal` for cancellation. |
182
+ | `ctx.requestId` | Unique request ID. |
183
+ | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
184
+
185
+ ---
186
+
187
+ ## Errors
188
+
189
+ Handlers throw — the framework catches, classifies, and formats.
190
+
191
+ **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable?, severity?, thrownBy? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. `recovery` is required (≥ 5 words, lint-validated). Forward it with `ctx.recoveryFor('reason')` in the throw's data; both client surfaces receive it, with duplicate hints omitted from the text. Use explicit `{ recovery: { hint } }` for runtime guidance. Mark reasons produced below the handler with `thrownBy: 'service'`; remove unused entries. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`, `RequestCancelled`) need no declaration.
192
+
193
+ ```ts
194
+ import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
195
+
196
+ errors: [
197
+ { reason: 'no_match', code: JsonRpcErrorCode.NotFound,
198
+ when: 'No item matched the query',
199
+ recovery: 'Broaden the query or check the spelling and try again.' },
200
+ ],
201
+ async handler(input, ctx) {
202
+ const item = await db.find(input.id);
203
+ if (!item) throw ctx.fail('no_match', `No item ${input.id}`, ctx.recoveryFor('no_match'));
204
+ return item;
205
+ }
206
+ ```
207
+
208
+ **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.
209
+
210
+ **Fallback (no contract entry fits):** throw via factories or plain `Error`.
211
+
212
+ ```ts
213
+ // Error factories — explicit code
214
+ import { notFound, serviceUnavailable } from '@cyanheads/mcp-ts-core/errors';
215
+ throw notFound('Item not found', { itemId });
216
+ throw serviceUnavailable('API unavailable', { url }, { cause: err });
217
+
218
+ // Plain Error — framework auto-classifies from message patterns
219
+ throw new Error('Item not found'); // → NotFound
220
+ throw new Error('Invalid query format'); // → ValidationError
221
+
222
+ // McpError — when no factory exists for the code
223
+ import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
224
+ throw new McpError(JsonRpcErrorCode.DatabaseError, 'Connection failed', { pool: 'primary' });
225
+ ```
226
+
227
+ See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
228
+
229
+ ---
230
+
231
+ ## Structure
232
+
233
+ ```text
234
+ src/
235
+ index.ts # createApp() entry point
236
+ config/
237
+ server-config.ts # Server-specific env vars (Zod schema)
238
+ services/
239
+ [domain]/
240
+ [domain]-service.ts # Domain service (init/accessor pattern)
241
+ types.ts # Domain types
242
+ mcp-server/
243
+ tools/definitions/
244
+ [tool-name].tool.ts # Tool definitions
245
+ resources/definitions/
246
+ [resource-name].resource.ts # Resource definitions
247
+ prompts/definitions/
248
+ [prompt-name].prompt.ts # Prompt definitions
249
+ ```
250
+
251
+ ---
252
+
253
+ ## Naming
254
+
255
+ | What | Convention | Example |
256
+ |:-----|:-----------|:--------|
257
+ | Files | kebab-case with suffix | `search-docs.tool.ts` |
258
+ | Tool/resource/prompt names | snake_case | `search_docs` |
259
+ | Directories | kebab-case | `src/services/doc-search/` |
260
+ | Descriptions | Single string or template literal, no `+` concatenation | `'Search items by query and filter.'` |
261
+
262
+ ---
263
+
264
+ ## Skills
265
+
266
+ Skills are modular instructions in `framework-skills/` at the project root. 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. Reserve root `skills/` for end-user plugin skills; plugin hosts automatically load that directory.
267
+
268
+ **Agent skill directory:** Copy 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.
269
+
270
+ Available skills:
271
+
272
+ | Skill | Purpose |
273
+ |:------|:--------|
274
+ | `setup` | Post-init project orientation |
275
+ | `design-mcp-server` | Design tool surface, resources, and services for a new server |
276
+ | `add-tool` | Scaffold a new tool definition |
277
+ | `add-app-tool` | Scaffold an MCP App tool + paired UI resource |
278
+ | `add-resource` | Scaffold a new resource definition |
279
+ | `add-prompt` | Scaffold a new prompt definition |
280
+ | `add-service` | Scaffold a new service integration |
281
+ | `add-test` | Scaffold test file for a tool, resource, or service |
282
+ | `field-test` | Exercise tools/resources/prompts with real inputs, verify behavior, report issues |
283
+ | `tool-defs-analysis` | Read-only audit of MCP definition language across the surface — voice, leaks, defaults, recovery hints, output descriptions |
284
+ | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
285
+ | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
286
+ | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
287
+ | `git-wrapup` | Commit the work by concern, then release metadata; open the release PR. No tag or push to main |
288
+ | `release-pr-review` | Review an open release PR; fixes land as ordinary commits on top of the stack |
289
+ | `release-and-publish` | Fast-forward merge + tag + push + npm + MCP Registry + GH Release + Docker |
290
+ | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
291
+ | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
292
+ | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
293
+ | `report-issue-local` | File a bug or feature request against this server's own repo via `gh` CLI |
294
+ | `techniques` | Catalog of response/data-shaping techniques — overflow handling, payload shaping, retrieval patterns |
295
+ | `api-auth` | Auth modes, scopes, JWT/OAuth |
296
+ | `api-canvas` | DataCanvas: register tabular data, run SQL, export, plus the `spillover()` helper for big result sets — Tier 3 opt-in |
297
+ | `api-config` | AppConfig, parseConfig, env vars |
298
+ | `api-context` | Context interface, RequestContext, logger, state, multi-round-trip input |
299
+ | `api-errors` | McpError, JsonRpcErrorCode, error patterns |
300
+ | `api-linter` | Definition linter rule catalog — invoked by `bun run lint:mcp` and `devcheck` |
301
+ | `api-mirror` | MirrorService: persistent self-refreshing local mirror (embedded SQLite + FTS5) of a bulk upstream dataset — Tier 3 opt-in |
302
+ | `api-services` | LLM, Speech, Graph services |
303
+ | `api-testing` | createMockContext, test patterns |
304
+ | `api-utils` | Formatting, parsing, security, pagination, scheduling, telemetry helpers |
305
+ | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
306
+ | `api-workers` | Cloudflare Workers runtime |
307
+
308
+ **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.
309
+
310
+ When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
311
+
312
+ ---
313
+
314
+ ## Commands
315
+
316
+ **Runtime:** Scripts use Bun's native TypeScript execution — use `bun run <cmd>`.
317
+
318
+ | Command | Purpose |
319
+ |:--------|:--------|
320
+ | `bun run build` | Compile TypeScript |
321
+ | `bun run rebuild` | Clean + build |
322
+ | `bun run clean` | Remove build artifacts |
323
+ | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
324
+ | `bun run audit:fix` | `bun audit fix`: upgrade vulnerable packages within existing ranges; first response to an advisory, then `bun update <name>` and `bun dedupe` |
325
+ | `bun run audit:refresh` | Last resort: delete the lockfile and reinstall; every ranged dependency, including the framework, re-resolves |
326
+ | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
327
+ | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
328
+ | `bun run list-skills` | Print the skill registry |
329
+ | `bun run tree` | Generate directory structure doc |
330
+ | `bun run format` | Auto-fix formatting (safe fixes only) |
331
+ | `bun run format:unsafe` | Also apply Biome's unsafe autofixes — review the diff; they can change behavior |
332
+ | `bun run test` | Run tests (Vitest — use `bun run test`, not `bun test`) |
333
+ | `bun run start:stdio` | Production mode (stdio) |
334
+ | `bun run start:http` | Production mode (HTTP) |
335
+ | `bun run changelog:build` | Regenerate `CHANGELOG.md` from `changelog/*.md` |
336
+ | `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
337
+ | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
338
+
339
+ ---
340
+
341
+ ## Bundling
342
+
343
+ `bun run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips dependency-shipped agent docs plus platform-specific native bindings. 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.
344
+
345
+ **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). Wire bundle options as `${user_config.KEY}` and give optional string options `default: ""`. Plugin user variables belong in Claude `userConfig` with matching references and Codex `env_vars`, never empty `env` values. `lint:packaging` checks parity and wiring.
346
+
347
+ **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the 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`.
348
+
349
+ ---
350
+
351
+ ## Changelog
352
+
353
+ Directory-based, grouped by minor series via the `.x` semver-wildcard convention. Source of truth: `changelog/<major.minor>.x/<version>.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.
354
+
355
+ Each per-version file opens with YAML frontmatter:
356
+
357
+ ```markdown
358
+ ---
359
+ summary: "One-line headline, ≤350 chars" # required — powers the rollup index
360
+ breaking: false # optional — true flags breaking changes
361
+ security: false # optional — true ONLY for a source-code security fix, never a dependency CVE bump
362
+ ---
363
+
364
+ # 0.1.0 — YYYY-MM-DD
365
+ ...
366
+ ```
367
+
368
+ `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. When both are set, badges render `· ⚠️ Breaking · 🛡️ Security`.
369
+
370
+ `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, and one-time migration steps. Omit it when there's nothing to say.
371
+
372
+ **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security, then Dependencies. Include only sections with entries — don't ship empty headers.
373
+
374
+ **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.
375
+
376
+ ---
377
+
378
+ ## Publishing
379
+
380
+ **Every release goes through a release PR, straight-through** — `git-wrapup`'s "Release PR mode", mode `straight-through`. One run: `git-wrapup` lands the commit stack on `release/<version>`, pushes it, and opens the PR (title = the release commit subject, body = the changelog entry plus a gates section); `release-and-publish` then 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. A caller's brief may run a given release as `gated` instead — a `release-pr-review` pass on the open PR before `release-and-publish`. **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.
381
+
382
+ ---
383
+
384
+ ## Imports
385
+
386
+ ```ts
387
+ // Framework — z is re-exported, no separate zod import needed
388
+ import { tool, z } from '@cyanheads/mcp-ts-core';
389
+ import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
390
+
391
+ // Server's own code — via path alias
392
+ import { getMyService } from '@/services/my-domain/my-service.js';
393
+ ```
394
+
395
+ ---
396
+
397
+ ## Checklist
398
+
399
+ - [ ] 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()`)
400
+ - [ ] 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`.
401
+ - [ ] JSDoc `@fileoverview` + `@module` on every file
402
+ - [ ] `ctx.log` for logging, `ctx.state` for storage
403
+ - [ ] Handlers throw on failure — error factories or plain `Error`, no try/catch
404
+ - [ ] `format()` renders all data the LLM needs — different clients forward different surfaces (Claude Code → `structuredContent`, Claude Desktop → `content[]`); both must carry the same data
405
+ - [ ] If wrapping external API: raw/domain/output schemas reviewed against real upstream sparsity/nullability before finalizing required vs optional fields
406
+ - [ ] If wrapping external API: normalization and `format()` preserve uncertainty; do not fabricate facts from missing upstream data
407
+ - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
408
+ - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
409
+ - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
410
+ - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = unscoped repo name; `interface.shortDescription` is concise and target-specific
411
+ - [ ] `.codex-plugin/mcp.json` updated — server name key matches the unscoped repo name; env vars added for any required API keys
412
+ - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry uses the unscoped repo name
413
+ - [ ] `bun run devcheck` passes