@cyanheads/whois-mcp-server 0.1.4 → 0.1.6

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 (45) hide show
  1. package/AGENTS.md +61 -28
  2. package/CLAUDE.md +61 -28
  3. package/Dockerfile +44 -33
  4. package/README.md +41 -65
  5. package/changelog/0.1.x/0.1.5.md +35 -0
  6. package/changelog/0.1.x/0.1.6.md +41 -0
  7. package/changelog/template.md +9 -26
  8. package/dist/app.d.ts +216 -0
  9. package/dist/app.d.ts.map +1 -0
  10. package/dist/app.js +47 -0
  11. package/dist/app.js.map +1 -0
  12. package/dist/index.js +2 -33
  13. package/dist/index.js.map +1 -1
  14. package/dist/mcp-server/tools/definitions/whois-check-availability.tool.d.ts.map +1 -1
  15. package/dist/mcp-server/tools/definitions/whois-check-availability.tool.js +1 -3
  16. package/dist/mcp-server/tools/definitions/whois-check-availability.tool.js.map +1 -1
  17. package/dist/mcp-server/tools/definitions/whois-get-dns.tool.d.ts +17 -0
  18. package/dist/mcp-server/tools/definitions/whois-get-dns.tool.d.ts.map +1 -1
  19. package/dist/mcp-server/tools/definitions/whois-get-dns.tool.js +21 -14
  20. package/dist/mcp-server/tools/definitions/whois-get-dns.tool.js.map +1 -1
  21. package/dist/mcp-server/tools/definitions/whois-get-dossier.tool.d.ts.map +1 -1
  22. package/dist/mcp-server/tools/definitions/whois-get-dossier.tool.js +39 -31
  23. package/dist/mcp-server/tools/definitions/whois-get-dossier.tool.js.map +1 -1
  24. package/dist/mcp-server/tools/definitions/whois-lookup-asn.tool.d.ts +4 -2
  25. package/dist/mcp-server/tools/definitions/whois-lookup-asn.tool.d.ts.map +1 -1
  26. package/dist/mcp-server/tools/definitions/whois-lookup-asn.tool.js +8 -5
  27. package/dist/mcp-server/tools/definitions/whois-lookup-asn.tool.js.map +1 -1
  28. package/dist/mcp-server/tools/definitions/whois-lookup-domain.tool.d.ts.map +1 -1
  29. package/dist/mcp-server/tools/definitions/whois-lookup-domain.tool.js +2 -5
  30. package/dist/mcp-server/tools/definitions/whois-lookup-domain.tool.js.map +1 -1
  31. package/dist/mcp-server/tools/definitions/whois-lookup-ip.tool.d.ts +4 -2
  32. package/dist/mcp-server/tools/definitions/whois-lookup-ip.tool.d.ts.map +1 -1
  33. package/dist/mcp-server/tools/definitions/whois-lookup-ip.tool.js +13 -12
  34. package/dist/mcp-server/tools/definitions/whois-lookup-ip.tool.js.map +1 -1
  35. package/dist/services/doh/doh-service.d.ts.map +1 -1
  36. package/dist/services/doh/doh-service.js +10 -12
  37. package/dist/services/doh/doh-service.js.map +1 -1
  38. package/dist/services/doh/types.d.ts +4 -0
  39. package/dist/services/doh/types.d.ts.map +1 -1
  40. package/dist/services/rdap/rdap-service.d.ts +10 -3
  41. package/dist/services/rdap/rdap-service.d.ts.map +1 -1
  42. package/dist/services/rdap/rdap-service.js +67 -109
  43. package/dist/services/rdap/rdap-service.js.map +1 -1
  44. package/package.json +13 -11
  45. package/server.json +3 -3
package/AGENTS.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** whois-mcp-server
4
- **Version:** 0.1.4
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.12.3`
6
- **Engines:** Bun ≥1.3.0, Node ≥24.0.0
7
- **MCP SDK:** `@modelcontextprotocol/server` ^2.0.0
8
- **Zod:** ^4.4.3
4
+ **Version:** 0.1.6
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.10`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` ^2.1.0
8
+ **Zod:** ^4.6.5
9
9
 
10
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
11
 
@@ -37,6 +37,7 @@ Tailor suggestions to what's actually missing or stale — don't recite the full
37
37
  - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
38
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
39
  - **Secrets in env vars only** — never hardcoded.
40
+ - **Cut noise.** Add only what earns its place: no speculative generality, no guards for states the framework already prevents (Zod-validated params, classified errors), no abstraction until a third caller proves it, no option nothing sets.
40
41
  - **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.
41
42
 
42
43
  ---
@@ -105,7 +106,9 @@ export function getServerConfig() {
105
106
  }
106
107
  ```
107
108
 
108
- `parseEnvConfig` maps Zod schema paths → env var names so errors name the variable (`RDAP_TIMEOUT_MS`) not the path (`rdapTimeoutMs`). Throws `ConfigurationError`, which the framework prints as a clean startup banner.
109
+ `parseEnvConfig` maps Zod schema paths → env var names so errors name the variable (`RDAP_TIMEOUT_MS`) not the path (`rdapTimeoutMs`). Throws `ConfigurationError`, which the framework prints as a clean startup banner. An empty string and a whole-value unsubstituted `${…}` placeholder read as unset, so an optional field stays `undefined` and a defaulted field takes its default.
110
+
111
+ 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.
109
112
 
110
113
  ### Server identity and instructions
111
114
 
@@ -121,6 +124,24 @@ await createApp({
121
124
 
122
125
  `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.
123
126
 
127
+ ### Session posture and shutdown
128
+
129
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
130
+
131
+ ```ts
132
+ await createApp({
133
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
134
+ setup(core) { startMyWatcher(core.config); },
135
+ async teardown() { await stopMyWatcher(); },
136
+ });
137
+ ```
138
+
139
+ `sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the option). Add `require: 'stateful'` when a tool asks the caller for input mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused.
140
+
141
+ `teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d timer there. It runs after the transport stops and before the logger closes, on every shutdown path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step never settles within the framework's 10 s ceiling).
142
+
143
+ **This server declares `sessionMode: 'stateless'`.** It holds no per-session state and no handler calls `ctx.requestInput`, so the session store and the per-session `McpServer` allocation are pure overhead and the process scales horizontally. `MCP_SESSION_MODE=stateless` in `.env.example` and the `Dockerfile` restate the same posture rather than overriding it; `require: 'stateful'` is deliberately not set. Neither `RdapService` nor `DohService` allocates a watcher, socket, or ref'd timer, so no `teardown` hook is warranted.
144
+
124
145
  ---
125
146
 
126
147
  ## Context
@@ -130,13 +151,14 @@ Handlers receive a unified `ctx` object. Key properties:
130
151
  | Property | Description |
131
152
  |:---------|:------------|
132
153
  | `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. |
133
- | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
134
- | `ctx.requestInput` | Suspend and ask the caller for more input — `return ctx.requestInput(...)`. Never returns; the handler is re-entered with the answers. Always present. |
135
- | `ctx.inputs` | Reader over a retried request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped`. Empty on the first round. |
154
+ | `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). |
155
+ | `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. |
156
+ | `ctx.inputs` | The request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped` — limited to what the client declared (`elicitation` and its form/url modes, `sampling`, `roots`). Client-supplied: a consent gate trusts only a `ctx.state` record it stored when it asked, bound to the operation, caller, and target (see the `api-context` skill). |
157
+ | `ctx.clientCapabilities` | What the client declared for this request, `undefined` when no view exists. Decides whether to ask for optional context (e.g. roots); never a reason to skip a consent prompt. |
136
158
  | `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). |
137
159
  | `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`. |
138
160
  | `ctx.signal` | `AbortSignal` for cancellation. |
139
- | `ctx.requestId` | Unique request ID. |
161
+ | `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
140
162
  | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
141
163
 
142
164
  ---
@@ -145,7 +167,7 @@ Handlers receive a unified `ctx` object. Key properties:
145
167
 
146
168
  Handlers throw — the framework catches, classifies, and formats.
147
169
 
148
- **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. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`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.
170
+ **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. 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 it on the wire whenever a failure carrying that `reason` arrives without a hint — a bare `ctx.fail('reason')` or a service throw with `data: { reason }` — as `data.recovery.hint`, mirrored into `content[]` text unless the message already contains it verbatim; override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Every error envelope also carries `data.requestId`, the id the server's log records for that call carry, and `content[]` closes with `(reason … · request <id>)`. Mark an entry the service layer throws with `thrownBy: 'service'` so `error-contract-unthrown` skips it — lint-only metadata, nothing at runtime reads it. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`, `RequestCancelled`) bubble freely and don't need declaring.
149
171
 
150
172
  ```ts
151
173
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -178,7 +200,7 @@ throw new Error('Invalid query format'); // → ValidationError
178
200
 
179
201
  // McpError — when no factory exists for the code
180
202
  import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
181
- throw new McpError(JsonRpcErrorCode.DatabaseError, 'Connection failed', { pool: 'primary' });
203
+ throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
182
204
  ```
183
205
 
184
206
  See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
@@ -189,7 +211,8 @@ See framework CLAUDE.md and the `api-errors` skill for the full auto-classificat
189
211
 
190
212
  ```text
191
213
  src/
192
- index.ts # createApp() entry point
214
+ index.ts # Entry point — starts the app
215
+ app.ts # createApp() options — tools, services, session mode
193
216
  config/
194
217
  server-config.ts # Server-specific env vars (Zod schema)
195
218
  services/
@@ -225,9 +248,9 @@ src/
225
248
 
226
249
  ## Skills
227
250
 
228
- Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool.
251
+ 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. The 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 these development skills to every agent that installs it. Keep `skills/` free for skills meant for those agents.
229
252
 
230
- **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
253
+ **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.
231
254
 
232
255
  Available skills:
233
256
 
@@ -245,28 +268,29 @@ Available skills:
245
268
  | `tool-defs-analysis` | Read-only audit of MCP definition language across the surface — voice, leaks, defaults, recovery hints, output descriptions |
246
269
  | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
247
270
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
248
- | `devcheck` | Lint, format, typecheck, audit |
249
271
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
250
- | `git-wrapup` | Land working-tree changes as a versioned commit + annotated tag — version bump, changelog, verify, tag. Local only. |
251
- | `release-and-publish` | Push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
272
+ | `git-wrapup` | Land working-tree changes as a commit stack — version bump, changelog, verify, commit by concern, release commit on top. No tag, no push to main; opens the release PR when the project declares release PR mode |
273
+ | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixes as ordinary commits on top of the stack, PR body kept in sync. Release PR mode only |
274
+ | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
252
275
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
253
276
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
254
277
  | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
255
278
  | `report-issue-local` | File a bug or feature request against this server's own repo via `gh` CLI |
279
+ | `techniques` | Catalog of response/data-shaping techniques — overflow handling, payload shaping, retrieval patterns |
256
280
  | `api-auth` | Auth modes, scopes, JWT/OAuth |
257
281
  | `api-canvas` | DataCanvas: register tabular data, run SQL, export, plus the `spillover()` helper for big result sets — Tier 3 opt-in |
258
282
  | `api-config` | AppConfig, parseConfig, env vars |
259
283
  | `api-context` | Context interface, RequestContext, logger, state, multi-round-trip input |
260
284
  | `api-errors` | McpError, JsonRpcErrorCode, error patterns |
261
285
  | `api-linter` | Definition linter rule catalog — invoked by `bun run lint:mcp` and `devcheck` |
286
+ | `api-mirror` | MirrorService: persistent self-refreshing local mirror (embedded SQLite + FTS5) of a bulk upstream dataset — Tier 3 opt-in |
262
287
  | `api-services` | LLM, Speech, Graph services |
263
288
  | `api-testing` | createMockContext, test patterns |
264
289
  | `api-utils` | Formatting, parsing, security, pagination, scheduling, telemetry helpers |
265
290
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
266
291
  | `api-workers` | Cloudflare Workers runtime |
267
- | `techniques` | Reusable response/data-shaping patterns — outline-on-overflow, spillover, capped-list disclosure |
268
292
 
269
- **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*, `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.
293
+ **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.
270
294
 
271
295
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
272
296
 
@@ -282,7 +306,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
282
306
  | `bun run rebuild` | Clean + build |
283
307
  | `bun run clean` | Remove build artifacts |
284
308
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
285
- | `bun run audit:refresh` | Delete `bun.lock`, reinstall, and re-run `bun audit`. Use when `devcheck` flags a transitive advisory — Bun's `update` is sticky on transitive resolutions, so the advisory may be a stale-lockfile false positive. If it survives the refresh, it's real. |
309
+ | `bun run audit:fix` | `bun audit fix` — upgrade vulnerable packages to the lowest safe version within existing ranges (`--dry-run` previews, `--latest` rewrites ranges). First response when `devcheck` flags a transitive advisory; then `bun update <name>`, then `bun dedupe` |
310
+ | `bun run audit:refresh` | Delete `bun.lock` and reinstall. Last resort after `audit:fix`, `bun update <name>`, and `bun dedupe` — re-resolves every ranged dep (the framework pin included) and rewrites the lockfile as `lockfileVersion: 2` |
286
311
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
287
312
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
288
313
  | `bun run list-skills` | Print the skill registry |
@@ -296,15 +321,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
296
321
  | `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
297
322
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
298
323
 
324
+ **CI is one file.** `.github/workflows/codeql.yml` is the only GitHub Actions workflow: CodeQL is GitHub-owned end to end, and the file runs only while the repo's CodeQL *default setup* is turned off. Verification — `devcheck`, tests, the release gates — runs locally; don't add a workflow that re-runs it.
325
+
299
326
  ---
300
327
 
301
328
  ## Bundling
302
329
 
303
- `npm 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 two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. 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.
330
+ `npm 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 two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. 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.
304
331
 
305
- **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.
332
+ **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, that every `user_config` option is wired into `mcp_config.env` as `"X": "${user_config.X}"` (the host substitutes nothing else — `"${X}"` reaches the server as that literal string), and that an optional string option carries `"default": ""`.
306
333
 
307
- **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 `skills/polish-docs-meta/references/readme.md`.
334
+ **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`.
308
335
 
309
336
  ---
310
337
 
@@ -329,12 +356,18 @@ security: false # optional — true ONLY for a source
329
356
 
330
357
  `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.
331
358
 
332
- **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security. Include only sections with entries — don't ship empty headers.
359
+ **Section order:** the Keep a Changelog sequence — Added, Changed, Deprecated, Removed, Fixed, Security — then `Dependencies` last. Include only sections with entries — don't ship empty headers.
333
360
 
334
361
  **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.
335
362
 
336
363
  ---
337
364
 
365
+ ## Publishing
366
+
367
+ **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.
368
+
369
+ ---
370
+
338
371
  ## Imports
339
372
 
340
373
  ```ts
@@ -361,7 +394,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
361
394
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
362
395
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
363
396
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
364
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
365
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
366
- - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry with server name key, env vars for any required API keys
397
+ - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name (never the npm scope — `lint:packaging` enforces this); `interface.shortDescription` from `package.json` description
398
+ - [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; every user-supplied variable (API key, contact email, instance URL) is listed in `env_vars` so Codex forwards it from the user's environment. Never write `"KEY": ""` into `env` — an empty value replaces the user's exported key and is read as unset
399
+ - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `author`, `repository`, `license`, `keywords` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name. Every user-supplied variable is declared under `userConfig` (`type`, `title`, `description`; `sensitive: true` for keys and tokens; `required: true` or `default: ""`) and referenced from `env` as `"KEY": "${user_config.<option>}"` — mirror the `user_config` block in `manifest.json`. Never write `"KEY": ""` into `env`
367
400
  - [ ] `npm run devcheck` passes
package/CLAUDE.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** whois-mcp-server
4
- **Version:** 0.1.4
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.12.3`
6
- **Engines:** Bun ≥1.3.0, Node ≥24.0.0
7
- **MCP SDK:** `@modelcontextprotocol/server` ^2.0.0
8
- **Zod:** ^4.4.3
4
+ **Version:** 0.1.6
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.10`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` ^2.1.0
8
+ **Zod:** ^4.6.5
9
9
 
10
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
11
 
@@ -37,6 +37,7 @@ Tailor suggestions to what's actually missing or stale — don't recite the full
37
37
  - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
38
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
39
  - **Secrets in env vars only** — never hardcoded.
40
+ - **Cut noise.** Add only what earns its place: no speculative generality, no guards for states the framework already prevents (Zod-validated params, classified errors), no abstraction until a third caller proves it, no option nothing sets.
40
41
  - **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.
41
42
 
42
43
  ---
@@ -105,7 +106,9 @@ export function getServerConfig() {
105
106
  }
106
107
  ```
107
108
 
108
- `parseEnvConfig` maps Zod schema paths → env var names so errors name the variable (`RDAP_TIMEOUT_MS`) not the path (`rdapTimeoutMs`). Throws `ConfigurationError`, which the framework prints as a clean startup banner.
109
+ `parseEnvConfig` maps Zod schema paths → env var names so errors name the variable (`RDAP_TIMEOUT_MS`) not the path (`rdapTimeoutMs`). Throws `ConfigurationError`, which the framework prints as a clean startup banner. An empty string and a whole-value unsubstituted `${…}` placeholder read as unset, so an optional field stays `undefined` and a defaulted field takes its default.
110
+
111
+ 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.
109
112
 
110
113
  ### Server identity and instructions
111
114
 
@@ -121,6 +124,24 @@ await createApp({
121
124
 
122
125
  `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.
123
126
 
127
+ ### Session posture and shutdown
128
+
129
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
130
+
131
+ ```ts
132
+ await createApp({
133
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
134
+ setup(core) { startMyWatcher(core.config); },
135
+ async teardown() { await stopMyWatcher(); },
136
+ });
137
+ ```
138
+
139
+ `sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the option). Add `require: 'stateful'` when a tool asks the caller for input mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused.
140
+
141
+ `teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d timer there. It runs after the transport stops and before the logger closes, on every shutdown path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step never settles within the framework's 10 s ceiling).
142
+
143
+ **This server declares `sessionMode: 'stateless'`.** It holds no per-session state and no handler calls `ctx.requestInput`, so the session store and the per-session `McpServer` allocation are pure overhead and the process scales horizontally. `MCP_SESSION_MODE=stateless` in `.env.example` and the `Dockerfile` restate the same posture rather than overriding it; `require: 'stateful'` is deliberately not set. Neither `RdapService` nor `DohService` allocates a watcher, socket, or ref'd timer, so no `teardown` hook is warranted.
144
+
124
145
  ---
125
146
 
126
147
  ## Context
@@ -130,13 +151,14 @@ Handlers receive a unified `ctx` object. Key properties:
130
151
  | Property | Description |
131
152
  |:---------|:------------|
132
153
  | `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. |
133
- | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
134
- | `ctx.requestInput` | Suspend and ask the caller for more input — `return ctx.requestInput(...)`. Never returns; the handler is re-entered with the answers. Always present. |
135
- | `ctx.inputs` | Reader over a retried request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped`. Empty on the first round. |
154
+ | `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). |
155
+ | `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. |
156
+ | `ctx.inputs` | The request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped` — limited to what the client declared (`elicitation` and its form/url modes, `sampling`, `roots`). Client-supplied: a consent gate trusts only a `ctx.state` record it stored when it asked, bound to the operation, caller, and target (see the `api-context` skill). |
157
+ | `ctx.clientCapabilities` | What the client declared for this request, `undefined` when no view exists. Decides whether to ask for optional context (e.g. roots); never a reason to skip a consent prompt. |
136
158
  | `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). |
137
159
  | `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`. |
138
160
  | `ctx.signal` | `AbortSignal` for cancellation. |
139
- | `ctx.requestId` | Unique request ID. |
161
+ | `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
140
162
  | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
141
163
 
142
164
  ---
@@ -145,7 +167,7 @@ Handlers receive a unified `ctx` object. Key properties:
145
167
 
146
168
  Handlers throw — the framework catches, classifies, and formats.
147
169
 
148
- **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. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`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.
170
+ **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. 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 it on the wire whenever a failure carrying that `reason` arrives without a hint — a bare `ctx.fail('reason')` or a service throw with `data: { reason }` — as `data.recovery.hint`, mirrored into `content[]` text unless the message already contains it verbatim; override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Every error envelope also carries `data.requestId`, the id the server's log records for that call carry, and `content[]` closes with `(reason … · request <id>)`. Mark an entry the service layer throws with `thrownBy: 'service'` so `error-contract-unthrown` skips it — lint-only metadata, nothing at runtime reads it. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`, `RequestCancelled`) bubble freely and don't need declaring.
149
171
 
150
172
  ```ts
151
173
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -178,7 +200,7 @@ throw new Error('Invalid query format'); // → ValidationError
178
200
 
179
201
  // McpError — when no factory exists for the code
180
202
  import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
181
- throw new McpError(JsonRpcErrorCode.DatabaseError, 'Connection failed', { pool: 'primary' });
203
+ throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
182
204
  ```
183
205
 
184
206
  See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
@@ -189,7 +211,8 @@ See framework CLAUDE.md and the `api-errors` skill for the full auto-classificat
189
211
 
190
212
  ```text
191
213
  src/
192
- index.ts # createApp() entry point
214
+ index.ts # Entry point — starts the app
215
+ app.ts # createApp() options — tools, services, session mode
193
216
  config/
194
217
  server-config.ts # Server-specific env vars (Zod schema)
195
218
  services/
@@ -225,9 +248,9 @@ src/
225
248
 
226
249
  ## Skills
227
250
 
228
- Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool.
251
+ 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. The 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 these development skills to every agent that installs it. Keep `skills/` free for skills meant for those agents.
229
252
 
230
- **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
253
+ **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.
231
254
 
232
255
  Available skills:
233
256
 
@@ -245,28 +268,29 @@ Available skills:
245
268
  | `tool-defs-analysis` | Read-only audit of MCP definition language across the surface — voice, leaks, defaults, recovery hints, output descriptions |
246
269
  | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
247
270
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
248
- | `devcheck` | Lint, format, typecheck, audit |
249
271
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
250
- | `git-wrapup` | Land working-tree changes as a versioned commit + annotated tag — version bump, changelog, verify, tag. Local only. |
251
- | `release-and-publish` | Push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
272
+ | `git-wrapup` | Land working-tree changes as a commit stack — version bump, changelog, verify, commit by concern, release commit on top. No tag, no push to main; opens the release PR when the project declares release PR mode |
273
+ | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixes as ordinary commits on top of the stack, PR body kept in sync. Release PR mode only |
274
+ | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
252
275
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
253
276
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
254
277
  | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
255
278
  | `report-issue-local` | File a bug or feature request against this server's own repo via `gh` CLI |
279
+ | `techniques` | Catalog of response/data-shaping techniques — overflow handling, payload shaping, retrieval patterns |
256
280
  | `api-auth` | Auth modes, scopes, JWT/OAuth |
257
281
  | `api-canvas` | DataCanvas: register tabular data, run SQL, export, plus the `spillover()` helper for big result sets — Tier 3 opt-in |
258
282
  | `api-config` | AppConfig, parseConfig, env vars |
259
283
  | `api-context` | Context interface, RequestContext, logger, state, multi-round-trip input |
260
284
  | `api-errors` | McpError, JsonRpcErrorCode, error patterns |
261
285
  | `api-linter` | Definition linter rule catalog — invoked by `bun run lint:mcp` and `devcheck` |
286
+ | `api-mirror` | MirrorService: persistent self-refreshing local mirror (embedded SQLite + FTS5) of a bulk upstream dataset — Tier 3 opt-in |
262
287
  | `api-services` | LLM, Speech, Graph services |
263
288
  | `api-testing` | createMockContext, test patterns |
264
289
  | `api-utils` | Formatting, parsing, security, pagination, scheduling, telemetry helpers |
265
290
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
266
291
  | `api-workers` | Cloudflare Workers runtime |
267
- | `techniques` | Reusable response/data-shaping patterns — outline-on-overflow, spillover, capped-list disclosure |
268
292
 
269
- **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*, `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.
293
+ **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.
270
294
 
271
295
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
272
296
 
@@ -282,7 +306,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
282
306
  | `bun run rebuild` | Clean + build |
283
307
  | `bun run clean` | Remove build artifacts |
284
308
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
285
- | `bun run audit:refresh` | Delete `bun.lock`, reinstall, and re-run `bun audit`. Use when `devcheck` flags a transitive advisory — Bun's `update` is sticky on transitive resolutions, so the advisory may be a stale-lockfile false positive. If it survives the refresh, it's real. |
309
+ | `bun run audit:fix` | `bun audit fix` — upgrade vulnerable packages to the lowest safe version within existing ranges (`--dry-run` previews, `--latest` rewrites ranges). First response when `devcheck` flags a transitive advisory; then `bun update <name>`, then `bun dedupe` |
310
+ | `bun run audit:refresh` | Delete `bun.lock` and reinstall. Last resort after `audit:fix`, `bun update <name>`, and `bun dedupe` — re-resolves every ranged dep (the framework pin included) and rewrites the lockfile as `lockfileVersion: 2` |
286
311
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
287
312
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
288
313
  | `bun run list-skills` | Print the skill registry |
@@ -296,15 +321,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
296
321
  | `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
297
322
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
298
323
 
324
+ **CI is one file.** `.github/workflows/codeql.yml` is the only GitHub Actions workflow: CodeQL is GitHub-owned end to end, and the file runs only while the repo's CodeQL *default setup* is turned off. Verification — `devcheck`, tests, the release gates — runs locally; don't add a workflow that re-runs it.
325
+
299
326
  ---
300
327
 
301
328
  ## Bundling
302
329
 
303
- `npm 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 two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. 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.
330
+ `npm 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 two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. 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.
304
331
 
305
- **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.
332
+ **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, that every `user_config` option is wired into `mcp_config.env` as `"X": "${user_config.X}"` (the host substitutes nothing else — `"${X}"` reaches the server as that literal string), and that an optional string option carries `"default": ""`.
306
333
 
307
- **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 `skills/polish-docs-meta/references/readme.md`.
334
+ **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`.
308
335
 
309
336
  ---
310
337
 
@@ -329,12 +356,18 @@ security: false # optional — true ONLY for a source
329
356
 
330
357
  `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.
331
358
 
332
- **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security. Include only sections with entries — don't ship empty headers.
359
+ **Section order:** the Keep a Changelog sequence — Added, Changed, Deprecated, Removed, Fixed, Security — then `Dependencies` last. Include only sections with entries — don't ship empty headers.
333
360
 
334
361
  **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.
335
362
 
336
363
  ---
337
364
 
365
+ ## Publishing
366
+
367
+ **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.
368
+
369
+ ---
370
+
338
371
  ## Imports
339
372
 
340
373
  ```ts
@@ -361,7 +394,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
361
394
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
362
395
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
363
396
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
364
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
365
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
366
- - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry with server name key, env vars for any required API keys
397
+ - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name (never the npm scope — `lint:packaging` enforces this); `interface.shortDescription` from `package.json` description
398
+ - [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; every user-supplied variable (API key, contact email, instance URL) is listed in `env_vars` so Codex forwards it from the user's environment. Never write `"KEY": ""` into `env` — an empty value replaces the user's exported key and is read as unset
399
+ - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `author`, `repository`, `license`, `keywords` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name. Every user-supplied variable is declared under `userConfig` (`type`, `title`, `description`; `sensitive: true` for keys and tokens; `required: true` or `default: ""`) and referenced from `env` as `"KEY": "${user_config.<option>}"` — mirror the `user_config` block in `manifest.json`. Never write `"KEY": ""` into `env`
367
400
  - [ ] `npm run devcheck` passes
package/Dockerfile CHANGED
@@ -4,7 +4,7 @@
4
4
  # This stage installs all dependencies (including dev), builds the TypeScript
5
5
  # source code into JavaScript, and prepares the production assets.
6
6
  # ==============================================================================
7
- FROM --platform=$BUILDPLATFORM oven/bun:1.4.0 AS build
7
+ FROM --platform=$BUILDPLATFORM oven/bun:1.4.2 AS build
8
8
 
9
9
  WORKDIR /usr/src/app
10
10
 
@@ -23,6 +23,45 @@ COPY . .
23
23
  RUN bun run build
24
24
 
25
25
 
26
+ # ==============================================================================
27
+ # Production Dependencies Stage
28
+ #
29
+ # Run the scanner and OTel installer natively, cross-installing dependencies for
30
+ # the target architecture. Only node_modules enters the production image.
31
+ # ==============================================================================
32
+ FROM --platform=$BUILDPLATFORM oven/bun:1.4.2 AS deps
33
+
34
+ WORKDIR /usr/src/app
35
+
36
+ COPY package.json bun.lock bunfig.toml ./
37
+
38
+ # Seed the scanner omitted by the production install; bunfig.toml retains both
39
+ # the scanner and release-age protections for all dependency resolution.
40
+ COPY --from=build /usr/src/app/node_modules/@socketsecurity/bun-security-scanner ./node_modules/@socketsecurity/bun-security-scanner
41
+
42
+ ARG TARGETOS
43
+ ARG TARGETARCH
44
+ RUN case "$TARGETARCH" in \
45
+ amd64) echo x64 ;; \
46
+ arm64) echo arm64 ;; \
47
+ *) echo "Unsupported TARGETARCH '$TARGETARCH': expected amd64 or arm64" >&2; exit 1 ;; \
48
+ esac > .bun-cpu
49
+
50
+ RUN --mount=type=cache,target=/root/.bun/install/cache \
51
+ bun install --production --omit=peer --frozen-lockfile --ignore-scripts \
52
+ --os="$TARGETOS" --cpu="$(cat .bun-cpu)"
53
+
54
+ # Read the OTel package list and ranges from the installed framework.
55
+ COPY scripts/install-otel.ts ./scripts/
56
+ ARG OTEL_ENABLED=true
57
+ RUN --mount=type=cache,target=/root/.bun/install/cache \
58
+ if [ "$OTEL_ENABLED" = "true" ]; then \
59
+ bun scripts/install-otel.ts --os="$TARGETOS" --cpu="$(cat .bun-cpu)"; \
60
+ fi
61
+
62
+ RUN rm -rf node_modules/@socketsecurity/bun-security-scanner
63
+
64
+
26
65
  # ==============================================================================
27
66
  # Production Stage
28
67
  #
@@ -30,7 +69,7 @@ RUN bun run build
30
69
  # application. It uses a slim base image and only includes production
31
70
  # dependencies and build artifacts.
32
71
  # ==============================================================================
33
- FROM oven/bun:1.4.0-slim AS production
72
+ FROM oven/bun:1.4.2-slim AS production
34
73
 
35
74
  WORKDIR /usr/src/app
36
75
 
@@ -46,36 +85,9 @@ LABEL org.opencontainers.image.source="https://github.com/cyanheads/whois-mcp-se
46
85
  LABEL org.opencontainers.image.licenses="Apache-2.0"
47
86
  LABEL org.opencontainers.image.version="${APP_VERSION}"
48
87
 
49
- # Copy dependency manifests
50
- COPY package.json bun.lock ./
51
-
52
- # Install only production dependencies, ignoring any lifecycle scripts (like 'prepare')
53
- # that are not needed in the final production image.
54
- # `--omit=peer` drops the framework's optional peer tiers (test runner, service
55
- # SDKs, parsers) that Bun would otherwise auto-install. Anything this server
56
- # actually imports belongs in its own `dependencies`, so nothing needed at
57
- # runtime is lost. The OTEL step below carries the same flag — without it, that
58
- # install re-resolves the graph and pulls every optional peer back in.
59
- RUN --mount=type=cache,target=/root/.bun/install/cache \
60
- bun install --production --omit=peer --frozen-lockfile --ignore-scripts
61
-
62
- # Conditionally install OpenTelemetry optional peer dependencies (Tier 3).
63
- # These are not bundled by default to keep the base image lean. Enable at build time
64
- # with: docker build --build-arg OTEL_ENABLED=true
65
- ARG OTEL_ENABLED=true
66
- RUN --mount=type=cache,target=/root/.bun/install/cache \
67
- if [ "$OTEL_ENABLED" = "true" ]; then \
68
- bun add --omit=dev --omit=peer --ignore-scripts @hono/otel \
69
- @opentelemetry/instrumentation-http \
70
- @opentelemetry/exporter-metrics-otlp-http \
71
- @opentelemetry/exporter-trace-otlp-http \
72
- @opentelemetry/instrumentation-pino \
73
- @opentelemetry/resources \
74
- @opentelemetry/sdk-metrics \
75
- @opentelemetry/sdk-node \
76
- @opentelemetry/sdk-trace-node \
77
- @opentelemetry/semantic-conventions; \
78
- fi
88
+ # Keep the original manifest; the deps-stage OTel install rewrites its copy.
89
+ COPY package.json ./
90
+ COPY --from=deps /usr/src/app/node_modules ./node_modules
79
91
 
80
92
  # Copy the compiled application code from the build stage
81
93
  COPY --from=build /usr/src/app/dist ./dist
@@ -101,7 +113,6 @@ ENV MCP_TRANSPORT_TYPE="http"
101
113
  ENV MCP_SESSION_MODE="stateless"
102
114
  ENV MCP_LOG_LEVEL="info"
103
115
  ENV LOGS_DIR="/var/log/whois-mcp-server"
104
- ENV MCP_FORCE_CONSOLE_LOGGING="true"
105
116
 
106
117
  # Expose the port the server listens on
107
118
  EXPOSE ${MCP_HTTP_PORT}