@cyanheads/exchange-rates-mcp-server 0.4.0 → 0.4.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 (40) hide show
  1. package/AGENTS.md +46 -20
  2. package/CLAUDE.md +46 -20
  3. package/Dockerfile +87 -38
  4. package/README.md +95 -76
  5. package/changelog/0.4.x/0.4.1.md +27 -0
  6. package/changelog/0.4.x/0.4.2.md +45 -0
  7. package/changelog/template.md +9 -26
  8. package/dist/index.js +9 -0
  9. package/dist/index.js.map +1 -1
  10. package/dist/mcp-server/tools/definitions/fx-convert-currency.tool.d.ts.map +1 -1
  11. package/dist/mcp-server/tools/definitions/fx-convert-currency.tool.js +4 -9
  12. package/dist/mcp-server/tools/definitions/fx-convert-currency.tool.js.map +1 -1
  13. package/dist/mcp-server/tools/definitions/fx-dataframe-describe.tool.d.ts.map +1 -1
  14. package/dist/mcp-server/tools/definitions/fx-dataframe-describe.tool.js +3 -6
  15. package/dist/mcp-server/tools/definitions/fx-dataframe-describe.tool.js.map +1 -1
  16. package/dist/mcp-server/tools/definitions/fx-dataframe-drop.tool.d.ts +3 -2
  17. package/dist/mcp-server/tools/definitions/fx-dataframe-drop.tool.d.ts.map +1 -1
  18. package/dist/mcp-server/tools/definitions/fx-dataframe-drop.tool.js +7 -7
  19. package/dist/mcp-server/tools/definitions/fx-dataframe-drop.tool.js.map +1 -1
  20. package/dist/mcp-server/tools/definitions/fx-dataframe-query.tool.d.ts.map +1 -1
  21. package/dist/mcp-server/tools/definitions/fx-dataframe-query.tool.js +6 -15
  22. package/dist/mcp-server/tools/definitions/fx-dataframe-query.tool.js.map +1 -1
  23. package/dist/mcp-server/tools/definitions/fx-get-rate.tool.d.ts.map +1 -1
  24. package/dist/mcp-server/tools/definitions/fx-get-rate.tool.js +4 -9
  25. package/dist/mcp-server/tools/definitions/fx-get-rate.tool.js.map +1 -1
  26. package/dist/mcp-server/tools/definitions/fx-get-rates.tool.d.ts.map +1 -1
  27. package/dist/mcp-server/tools/definitions/fx-get-rates.tool.js +4 -9
  28. package/dist/mcp-server/tools/definitions/fx-get-rates.tool.js.map +1 -1
  29. package/dist/mcp-server/tools/definitions/fx-get-timeseries.tool.d.ts.map +1 -1
  30. package/dist/mcp-server/tools/definitions/fx-get-timeseries.tool.js +19 -17
  31. package/dist/mcp-server/tools/definitions/fx-get-timeseries.tool.js.map +1 -1
  32. package/dist/services/frankfurter/errors.d.ts +6 -1
  33. package/dist/services/frankfurter/errors.d.ts.map +1 -1
  34. package/dist/services/frankfurter/errors.js +6 -2
  35. package/dist/services/frankfurter/errors.js.map +1 -1
  36. package/dist/services/frankfurter/frankfurter-service.d.ts.map +1 -1
  37. package/dist/services/frankfurter/frankfurter-service.js +12 -4
  38. package/dist/services/frankfurter/frankfurter-service.js.map +1 -1
  39. package/package.json +13 -11
  40. package/server.json +12 -26
package/AGENTS.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** exchange-rates-mcp-server
4
- **Version:** 0.4.0
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `0.12.8`
4
+ **Version:** 0.4.2
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.11`
6
6
  **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
- **MCP SDK:** `@modelcontextprotocol/server` ^2.0.0
8
- **Zod:** ^4.6.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` ^2.2.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
 
@@ -163,6 +163,22 @@ await createApp({
163
163
 
164
164
  `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.
165
165
 
166
+ ### Session posture and shutdown
167
+
168
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
169
+
170
+ ```ts
171
+ await createApp({
172
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
173
+ setup(core) { setCanvas(core.canvas); },
174
+ async teardown() { await stopMyWatcher(); },
175
+ });
176
+ ```
177
+
178
+ `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). This server declares `stateless`: no handler calls `ctx.requestInput`, so nothing needs a session to resume. Add `require: 'stateful'` when a tool does ask the caller for input mid-handler: 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.
179
+
180
+ `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). Nothing here declares one: `setup()` only hands `core.canvas` to the module accessor, and the canvas service is torn down by the framework.
181
+
166
182
  ---
167
183
 
168
184
  ## Context
@@ -172,13 +188,14 @@ Handlers receive a unified `ctx` object. Key properties:
172
188
  | Property | Description |
173
189
  |:---------|:------------|
174
190
  | `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. |
175
- | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
191
+ | `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). |
176
192
  | `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. |
177
- | `ctx.inputs` | Reader over a retried request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped`. Empty on the first round. |
193
+ | `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). |
194
+ | `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. |
178
195
  | `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). |
179
196
  | `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`. |
180
197
  | `ctx.signal` | `AbortSignal` for cancellation. |
181
- | `ctx.requestId` | Unique request ID. |
198
+ | `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
182
199
  | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
183
200
 
184
201
  ---
@@ -187,7 +204,7 @@ Handlers receive a unified `ctx` object. Key properties:
187
204
 
188
205
  Handlers throw — the framework catches, classifies, and formats.
189
206
 
190
- **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`, `RequestCancelled`) bubble freely and don't need declaring.
207
+ **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.
191
208
 
192
209
  ```ts
193
210
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -199,7 +216,7 @@ errors: [
199
216
  ],
200
217
  async handler(input, ctx) {
201
218
  const item = await db.find(input.id);
202
- if (!item) throw ctx.fail('no_match', `No item ${input.id}`, ctx.recoveryFor('no_match'));
219
+ if (!item) throw ctx.fail('no_match', `No item ${input.id}`);
203
220
  return item;
204
221
  }
205
222
  ```
@@ -273,9 +290,9 @@ src/
273
290
 
274
291
  ## Skills
275
292
 
276
- 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. `bun run list-skills` prints the full registry.
293
+ 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.
277
294
 
278
- **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.
295
+ **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.
279
296
 
280
297
  Available skills:
281
298
 
@@ -295,7 +312,7 @@ Available skills:
295
312
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
296
313
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
297
314
  | `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 |
298
- | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixup commits autosquashed into the stack, PR body kept in sync. Release PR mode only |
315
+ | `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 |
299
316
  | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
300
317
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
301
318
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
@@ -315,7 +332,7 @@ Available skills:
315
332
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
316
333
  | `api-workers` | Cloudflare Workers runtime |
317
334
 
318
- **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.
335
+ **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.
319
336
 
320
337
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
321
338
 
@@ -331,7 +348,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
331
348
  | `bun run rebuild` | Clean + build |
332
349
  | `bun run clean` | Remove build artifacts |
333
350
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
334
- | `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. |
351
+ | `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` |
352
+ | `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` |
335
353
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
336
354
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
337
355
  | `bun run list-skills` | Print the skill registry |
@@ -346,15 +364,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
346
364
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
347
365
  | `bun run publish-mcp` | Publish to MCP Registry via mcp-publisher |
348
366
 
367
+ **CI is one file.** `.github/workflows/codeql.yml` (scaffolded) 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.
368
+
349
369
  ---
350
370
 
351
371
  ## Bundling
352
372
 
353
- `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 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. This server uses DataCanvas, so its bundle ships without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so `fx_dataframe_*` report an actionable install hint and every other tool works normally. 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.
373
+ `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 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. This server uses DataCanvas, so its bundle ships without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so `fx_dataframe_*` report an actionable install hint and every other tool works normally. 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.
354
374
 
355
- **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.
375
+ **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": ""`.
356
376
 
357
- **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`.
377
+ **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`.
358
378
 
359
379
  ---
360
380
 
@@ -385,6 +405,12 @@ security: false # optional — true ONLY for a source
385
405
 
386
406
  ---
387
407
 
408
+ ## Publishing
409
+
410
+ **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/<version>`, pushes it, and opens the PR (title = the release commit subject, body = the release digest: the entry's `summary:` line, `## Changes` as the tag's flat bullets, `## Gates`, and the changelog link); `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.
411
+
412
+ ---
413
+
388
414
  ## Imports
389
415
 
390
416
  ```ts
@@ -411,7 +437,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
411
437
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
412
438
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
413
439
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
414
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
415
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
416
- - [ ] `.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
440
+ - [ ] `.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
441
+ - [ ] `.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
442
+ - [ ] `.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`
417
443
  - [ ] `npm run devcheck` passes
package/CLAUDE.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** exchange-rates-mcp-server
4
- **Version:** 0.4.0
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `0.12.8`
4
+ **Version:** 0.4.2
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.11`
6
6
  **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
- **MCP SDK:** `@modelcontextprotocol/server` ^2.0.0
8
- **Zod:** ^4.6.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` ^2.2.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
 
@@ -163,6 +163,22 @@ await createApp({
163
163
 
164
164
  `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.
165
165
 
166
+ ### Session posture and shutdown
167
+
168
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
169
+
170
+ ```ts
171
+ await createApp({
172
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
173
+ setup(core) { setCanvas(core.canvas); },
174
+ async teardown() { await stopMyWatcher(); },
175
+ });
176
+ ```
177
+
178
+ `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). This server declares `stateless`: no handler calls `ctx.requestInput`, so nothing needs a session to resume. Add `require: 'stateful'` when a tool does ask the caller for input mid-handler: 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.
179
+
180
+ `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). Nothing here declares one: `setup()` only hands `core.canvas` to the module accessor, and the canvas service is torn down by the framework.
181
+
166
182
  ---
167
183
 
168
184
  ## Context
@@ -172,13 +188,14 @@ Handlers receive a unified `ctx` object. Key properties:
172
188
  | Property | Description |
173
189
  |:---------|:------------|
174
190
  | `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. |
175
- | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
191
+ | `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). |
176
192
  | `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. |
177
- | `ctx.inputs` | Reader over a retried request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped`. Empty on the first round. |
193
+ | `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). |
194
+ | `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. |
178
195
  | `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). |
179
196
  | `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`. |
180
197
  | `ctx.signal` | `AbortSignal` for cancellation. |
181
- | `ctx.requestId` | Unique request ID. |
198
+ | `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
182
199
  | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
183
200
 
184
201
  ---
@@ -187,7 +204,7 @@ Handlers receive a unified `ctx` object. Key properties:
187
204
 
188
205
  Handlers throw — the framework catches, classifies, and formats.
189
206
 
190
- **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`, `RequestCancelled`) bubble freely and don't need declaring.
207
+ **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.
191
208
 
192
209
  ```ts
193
210
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -199,7 +216,7 @@ errors: [
199
216
  ],
200
217
  async handler(input, ctx) {
201
218
  const item = await db.find(input.id);
202
- if (!item) throw ctx.fail('no_match', `No item ${input.id}`, ctx.recoveryFor('no_match'));
219
+ if (!item) throw ctx.fail('no_match', `No item ${input.id}`);
203
220
  return item;
204
221
  }
205
222
  ```
@@ -273,9 +290,9 @@ src/
273
290
 
274
291
  ## Skills
275
292
 
276
- 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. `bun run list-skills` prints the full registry.
293
+ 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.
277
294
 
278
- **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.
295
+ **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.
279
296
 
280
297
  Available skills:
281
298
 
@@ -295,7 +312,7 @@ Available skills:
295
312
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
296
313
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
297
314
  | `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 |
298
- | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixup commits autosquashed into the stack, PR body kept in sync. Release PR mode only |
315
+ | `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 |
299
316
  | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
300
317
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
301
318
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
@@ -315,7 +332,7 @@ Available skills:
315
332
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
316
333
  | `api-workers` | Cloudflare Workers runtime |
317
334
 
318
- **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.
335
+ **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.
319
336
 
320
337
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
321
338
 
@@ -331,7 +348,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
331
348
  | `bun run rebuild` | Clean + build |
332
349
  | `bun run clean` | Remove build artifacts |
333
350
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
334
- | `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. |
351
+ | `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` |
352
+ | `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` |
335
353
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
336
354
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
337
355
  | `bun run list-skills` | Print the skill registry |
@@ -346,15 +364,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
346
364
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
347
365
  | `bun run publish-mcp` | Publish to MCP Registry via mcp-publisher |
348
366
 
367
+ **CI is one file.** `.github/workflows/codeql.yml` (scaffolded) 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.
368
+
349
369
  ---
350
370
 
351
371
  ## Bundling
352
372
 
353
- `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 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. This server uses DataCanvas, so its bundle ships without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so `fx_dataframe_*` report an actionable install hint and every other tool works normally. 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.
373
+ `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 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. This server uses DataCanvas, so its bundle ships without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so `fx_dataframe_*` report an actionable install hint and every other tool works normally. 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.
354
374
 
355
- **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.
375
+ **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": ""`.
356
376
 
357
- **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`.
377
+ **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`.
358
378
 
359
379
  ---
360
380
 
@@ -385,6 +405,12 @@ security: false # optional — true ONLY for a source
385
405
 
386
406
  ---
387
407
 
408
+ ## Publishing
409
+
410
+ **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/<version>`, pushes it, and opens the PR (title = the release commit subject, body = the release digest: the entry's `summary:` line, `## Changes` as the tag's flat bullets, `## Gates`, and the changelog link); `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.
411
+
412
+ ---
413
+
388
414
  ## Imports
389
415
 
390
416
  ```ts
@@ -411,7 +437,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
411
437
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
412
438
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
413
439
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
414
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
415
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
416
- - [ ] `.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
440
+ - [ ] `.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
441
+ - [ ] `.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
442
+ - [ ] `.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`
417
443
  - [ ] `npm run devcheck` passes
package/Dockerfile CHANGED
@@ -5,16 +5,16 @@
5
5
  # source code into JavaScript, and prepares the production assets.
6
6
  #
7
7
  # Pinned to $BUILDPLATFORM rather than the target platform: `bun run build` emits
8
- # JavaScript, and only `dist/` crosses into the production stage, which runs its
9
- # own target-arch install. Built for the target instead, the non-native leg of a
10
- # `--platform linux/amd64,linux/arm64` build runs under QEMU, where bun >= 1.4
11
- # aborts with a JavaScriptCore allocator assertion and fails the multi-arch push.
8
+ # JavaScript, and only `dist/` crosses into the production stage. Built for the
9
+ # target instead, the non-native leg of a `--platform linux/amd64,linux/arm64`
10
+ # build runs under QEMU, where bun >= 1.4 aborts with a JavaScriptCore allocator
11
+ # assertion and fails the multi-arch push.
12
12
  #
13
13
  # The constraint this assumes: the build stage produces platform-independent
14
14
  # output. A stage that compiles a native addon needs the target-arch toolchain
15
15
  # and cannot cross-compile this way — drop the flag there.
16
16
  # ==============================================================================
17
- FROM --platform=$BUILDPLATFORM oven/bun:1.4.0 AS build
17
+ FROM --platform=$BUILDPLATFORM oven/bun:1.4.2 AS build
18
18
 
19
19
  WORKDIR /usr/src/app
20
20
 
@@ -33,19 +33,91 @@ COPY . .
33
33
  RUN bun run build
34
34
 
35
35
 
36
+ # ==============================================================================
37
+ # Production Dependencies Stage
38
+ #
39
+ # Installs the production dependency tree for the target platform. Every step
40
+ # here can run JavaScript — bunfig.toml's security scanner runs as a Bun
41
+ # program, and so do the OTel and musl-prune scripts — so the stage runs on
42
+ # $BUILDPLATFORM and cross-installs with `--os`/`--cpu`, which pick each
43
+ # platform-specific optional dependency (native bindings such as DuckDB's) for
44
+ # the target. Only `node_modules` leaves this stage.
45
+ #
46
+ # A clean image rather than `FROM build`: the build stage's node_modules holds
47
+ # devDependencies.
48
+ # ==============================================================================
49
+ FROM --platform=$BUILDPLATFORM oven/bun:1.4.2 AS deps
50
+
51
+ WORKDIR /usr/src/app
52
+
53
+ # Copy dependency manifests. `bunfig.toml` rides along so every install below
54
+ # passes its release-age gate and security scanner, as a local install does.
55
+ COPY package.json bun.lock bunfig.toml ./
56
+
57
+ # The scanner bunfig.toml names is a devDependency, and Bun installs a missing
58
+ # scanner through the same production-filtered install, which omits it and
59
+ # aborts. Seed it from the build stage's full install instead. Remove this line,
60
+ # and the `rm` at the end of this stage, if bunfig.toml stops naming a scanner.
61
+ COPY --from=build /usr/src/app/node_modules/@socketsecurity/bun-security-scanner ./node_modules/@socketsecurity/bun-security-scanner
62
+
63
+ # Docker names the target architecture `amd64`/`arm64`; Bun's `--cpu` takes
64
+ # `x64`/`arm64`. Mapped once here, read by both installs below. `oven/bun`
65
+ # publishes only these two architectures, so any other target fails here.
66
+ ARG TARGETOS
67
+ ARG TARGETARCH
68
+ RUN case "$TARGETARCH" in \
69
+ amd64) echo x64 ;; \
70
+ arm64) echo arm64 ;; \
71
+ *) echo "Unsupported TARGETARCH '$TARGETARCH': expected amd64 or arm64" >&2; exit 1 ;; \
72
+ esac > .bun-cpu
73
+
74
+ # Install only production dependencies, ignoring any lifecycle scripts (like 'prepare')
75
+ # that are not needed in the final production image.
76
+ # `--omit=peer` drops the framework's optional peer tiers (test runner, service
77
+ # SDKs, parsers) that Bun would otherwise auto-install. Its one required peer
78
+ # (zod) and the DataCanvas engine (@duckdb/node-api) are direct dependencies of
79
+ # this server, so nothing needed at runtime is lost.
80
+ RUN --mount=type=cache,target=/root/.bun/install/cache \
81
+ bun install --production --omit=peer --frozen-lockfile --ignore-scripts \
82
+ --os="$TARGETOS" --cpu="$(cat .bun-cpu)"
83
+
84
+ # Conditionally install OpenTelemetry optional peer dependencies (Tier 3).
85
+ # Installed by default. Omit them for a leaner image at build time
86
+ # with: docker build --build-arg OTEL_ENABLED=false
87
+ # The script reads the list and each range from the installed framework's
88
+ # `peerDependencies` and passes the target flags on to its `bun install`.
89
+ COPY scripts/install-otel.ts ./scripts/
90
+ ARG OTEL_ENABLED=true
91
+ RUN --mount=type=cache,target=/root/.bun/install/cache \
92
+ if [ "$OTEL_ENABLED" = "true" ]; then \
93
+ bun scripts/install-otel.ts --os="$TARGETOS" --cpu="$(cat .bun-cpu)"; \
94
+ fi
95
+
96
+ # `--os`/`--cpu` have no libc counterpart, so a native dependency published in
97
+ # glibc and musl variants (DuckDB's bindings, for one) installs both. The
98
+ # runtime image is Debian (glibc) and never loads the musl copy; the script
99
+ # deletes every package whose own `libc` admits only musl. It follows every
100
+ # install, since a later `bun install` restores what it removes.
101
+ COPY scripts/prune-musl-packages.ts ./scripts/
102
+ RUN bun scripts/prune-musl-packages.ts
103
+
104
+ # The seeded scanner served only the installs above; keep it out of the image.
105
+ RUN rm -rf node_modules/@socketsecurity/bun-security-scanner
106
+
107
+
36
108
  # ==============================================================================
37
109
  # Production Stage
38
110
  #
39
111
  # This stage creates a minimal, optimized, and secure image for running the
40
112
  # application. It uses a slim base image and only includes production
41
- # dependencies and build artifacts.
113
+ # dependencies and build artifacts. Its only Bun invocations are HEALTHCHECK
114
+ # and CMD, which run on the real target at container start.
42
115
  # ==============================================================================
43
- FROM oven/bun:1.4.0-slim AS production
116
+ FROM oven/bun:1.4.2-slim AS production
44
117
 
45
118
  WORKDIR /usr/src/app
46
119
 
47
- # Set the environment to production for performance and to ensure only
48
- # production dependencies are installed.
120
+ # Set the environment to production for performance.
49
121
  ENV NODE_ENV=production
50
122
 
51
123
  # OCI image metadata (https://github.com/opencontainers/image-spec/blob/main/annotations.md)
@@ -56,34 +128,10 @@ LABEL org.opencontainers.image.source="https://github.com/cyanheads/exchange-rat
56
128
  LABEL org.opencontainers.image.licenses="Apache-2.0"
57
129
  LABEL org.opencontainers.image.version="${APP_VERSION}"
58
130
 
59
- # Copy dependency manifests
60
- COPY package.json bun.lock ./
61
-
62
- # Install only production dependencies, ignoring any lifecycle scripts (like 'prepare')
63
- # that are not needed in the final production image. Peers are omitted too: the
64
- # framework's optional peers are opt-in tiers this server does not use, and its one
65
- # required peer (zod) is a direct dependency. The OTEL tier is installed explicitly
66
- # below; @duckdb/node-api is likewise a direct dependency.
67
- RUN --mount=type=cache,target=/root/.bun/install/cache \
68
- bun install --production --frozen-lockfile --ignore-scripts --omit=peer
69
-
70
- # Conditionally install OpenTelemetry optional peer dependencies (Tier 3).
71
- # These are not bundled by default to keep the base image lean. Enable at build time
72
- # with: docker build --build-arg OTEL_ENABLED=true
73
- ARG OTEL_ENABLED=true
74
- RUN --mount=type=cache,target=/root/.bun/install/cache \
75
- if [ "$OTEL_ENABLED" = "true" ]; then \
76
- bun add --omit=dev --omit=peer --ignore-scripts @hono/otel \
77
- @opentelemetry/instrumentation-http \
78
- @opentelemetry/exporter-metrics-otlp-http \
79
- @opentelemetry/exporter-trace-otlp-http \
80
- @opentelemetry/instrumentation-pino \
81
- @opentelemetry/resources \
82
- @opentelemetry/sdk-metrics \
83
- @opentelemetry/sdk-node \
84
- @opentelemetry/sdk-trace-node \
85
- @opentelemetry/semantic-conventions; \
86
- fi
131
+ # The manifest comes from the build context: the deps stage's copy was rewritten
132
+ # by the OTel install, and the runtime reads only its name, version, and type.
133
+ COPY package.json ./
134
+ COPY --from=deps /usr/src/app/node_modules ./node_modules
87
135
 
88
136
  # Copy the compiled application code from the build stage
89
137
  COPY --from=build /usr/src/app/dist ./dist
@@ -106,10 +154,11 @@ ARG PORT
106
154
  ENV MCP_HTTP_PORT=${PORT:-3010}
107
155
  ENV MCP_HTTP_HOST="0.0.0.0"
108
156
  ENV MCP_TRANSPORT_TYPE="http"
157
+ # Matches the `sessionMode: 'stateless'` src/index.ts declares; a value set
158
+ # here (or at `docker run`) overrides that declaration.
109
159
  ENV MCP_SESSION_MODE="stateless"
110
160
  ENV MCP_LOG_LEVEL="info"
111
161
  ENV LOGS_DIR="/var/log/exchange-rates-mcp-server"
112
- ENV MCP_FORCE_CONSOLE_LOGGING="true"
113
162
 
114
163
  # Expose the port the server listens on
115
164
  EXPOSE ${MCP_HTTP_PORT}