@cyanheads/ris-austria-mcp-server 0.4.2 → 0.4.4
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.
- package/AGENTS.md +46 -19
- package/CLAUDE.md +46 -19
- package/README.md +71 -68
- package/changelog/0.4.x/0.4.3.md +33 -0
- package/changelog/0.4.x/0.4.4.md +30 -0
- package/changelog/template.md +9 -26
- package/dist/index.js +3 -0
- package/dist/index.js.map +1 -1
- package/dist/mcp-server/resources/definitions/ris-document.resource.js +1 -1
- package/dist/mcp-server/tools/definitions/ris-list-reference.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-list-reference.tool.js +9 -2
- package/dist/mcp-server/tools/definitions/ris-list-reference.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-announcements.tool.d.ts +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-announcements.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-announcements.tool.js +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-announcements.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-case-law.tool.d.ts +2 -0
- package/dist/mcp-server/tools/definitions/ris-search-case-law.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-case-law.tool.js +2 -0
- package/dist/mcp-server/tools/definitions/ris-search-case-law.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-drafts.tool.d.ts +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-drafts.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-drafts.tool.js +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-drafts.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-gazette.tool.d.ts +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-gazette.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-gazette.tool.js +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-gazette.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-legislation.tool.d.ts +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-legislation.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-search-legislation.tool.js +3 -0
- package/dist/mcp-server/tools/definitions/ris-search-legislation.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-track-changes.tool.d.ts +3 -0
- package/dist/mcp-server/tools/definitions/ris-track-changes.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/ris-track-changes.tool.js +3 -0
- package/dist/mcp-server/tools/definitions/ris-track-changes.tool.js.map +1 -1
- package/dist/services/ris/ris-service.d.ts +9 -6
- package/dist/services/ris/ris-service.d.ts.map +1 -1
- package/dist/services/ris/ris-service.js +23 -43
- package/dist/services/ris/ris-service.js.map +1 -1
- package/package.json +10 -9
- package/server.json +31 -3
package/AGENTS.md
CHANGED
|
@@ -1,11 +1,11 @@
|
|
|
1
1
|
# Developer Protocol
|
|
2
2
|
|
|
3
3
|
**Server:** ris-austria-mcp-server
|
|
4
|
-
**Version:** 0.4.
|
|
5
|
-
**Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.
|
|
6
|
-
**Engines:** Bun ≥1.
|
|
4
|
+
**Version:** 0.4.4
|
|
5
|
+
**Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.6`
|
|
6
|
+
**Engines:** Bun ≥1.4.0, Node ≥24.0.0
|
|
7
7
|
**MCP SDK:** `@modelcontextprotocol/server` ^2.0.0
|
|
8
|
-
**Zod:** ^4.
|
|
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
|
---
|
|
@@ -145,6 +146,7 @@ The entry point pins the machine identity and immutable public catalog cache hin
|
|
|
145
146
|
await createApp({
|
|
146
147
|
name: 'ris-austria-mcp-server',
|
|
147
148
|
title: 'ris-austria-mcp-server',
|
|
149
|
+
sessionMode: 'stateless',
|
|
148
150
|
cacheHints: {
|
|
149
151
|
'tools/list': { ttlMs: 3_600_000, cacheScope: 'public' },
|
|
150
152
|
'resources/list': { ttlMs: 3_600_000, cacheScope: 'public' },
|
|
@@ -161,6 +163,23 @@ await createApp({
|
|
|
161
163
|
|
|
162
164
|
`package.json` is the canonical description source; do not duplicate it into `createApp()`.
|
|
163
165
|
|
|
166
|
+
### Session posture and shutdown
|
|
167
|
+
|
|
168
|
+
`sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a
|
|
169
|
+
deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an
|
|
170
|
+
empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the
|
|
171
|
+
option). Every RIS tool answers from the request it was given, so `stateless` is the honest
|
|
172
|
+
declaration here. Add `require: 'stateful'` only if a tool ever asks the caller for input
|
|
173
|
+
mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than
|
|
174
|
+
serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused.
|
|
175
|
+
|
|
176
|
+
`teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d
|
|
177
|
+
timer there. It runs after the transport stops and before the logger closes, on every shutdown
|
|
178
|
+
path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step
|
|
179
|
+
never settles within the framework's 10 s ceiling). `RisService` holds nothing across requests
|
|
180
|
+
— every fetch is bounded by the caller's signal and the retry deadline — so this server
|
|
181
|
+
declares no `teardown`.
|
|
182
|
+
|
|
164
183
|
---
|
|
165
184
|
|
|
166
185
|
## Context
|
|
@@ -180,7 +199,7 @@ Handlers receive a unified `ctx` object. Key properties:
|
|
|
180
199
|
|
|
181
200
|
Handlers throw — the framework catches, classifies, and formats.
|
|
182
201
|
|
|
183
|
-
**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.
|
|
202
|
+
**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.
|
|
184
203
|
|
|
185
204
|
```ts
|
|
186
205
|
import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
|
|
@@ -213,7 +232,7 @@ throw new Error('Invalid query format'); // → ValidationError
|
|
|
213
232
|
|
|
214
233
|
// McpError — when no factory exists for the code
|
|
215
234
|
import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
|
|
216
|
-
throw new McpError(JsonRpcErrorCode.
|
|
235
|
+
throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
|
|
217
236
|
```
|
|
218
237
|
|
|
219
238
|
See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
|
|
@@ -257,9 +276,9 @@ src/
|
|
|
257
276
|
|
|
258
277
|
## Skills
|
|
259
278
|
|
|
260
|
-
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.
|
|
279
|
+
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.
|
|
261
280
|
|
|
262
|
-
**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.
|
|
281
|
+
**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.
|
|
263
282
|
|
|
264
283
|
Available skills:
|
|
265
284
|
|
|
@@ -278,8 +297,9 @@ Available skills:
|
|
|
278
297
|
| `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
|
|
279
298
|
| `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
|
|
280
299
|
| `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
|
|
281
|
-
| `git-wrapup` | Land working-tree changes as a
|
|
282
|
-
| `release-
|
|
300
|
+
| `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 |
|
|
301
|
+
| `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 |
|
|
302
|
+
| `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
|
|
283
303
|
| `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
|
|
284
304
|
| `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
|
|
285
305
|
| `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
|
|
@@ -298,7 +318,7 @@ Available skills:
|
|
|
298
318
|
| `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
|
|
299
319
|
| `api-workers` | Cloudflare Workers runtime |
|
|
300
320
|
|
|
301
|
-
**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.
|
|
321
|
+
**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.
|
|
302
322
|
|
|
303
323
|
When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
|
|
304
324
|
|
|
@@ -314,7 +334,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
|
|
|
314
334
|
| `bun run rebuild` | Clean + build |
|
|
315
335
|
| `bun run clean` | Remove build artifacts |
|
|
316
336
|
| `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
|
|
317
|
-
| `bun run audit:
|
|
337
|
+
| `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` |
|
|
338
|
+
| `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` |
|
|
318
339
|
| `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
|
|
319
340
|
| `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
|
|
320
341
|
| `bun run list-skills` | Print the skill registry |
|
|
@@ -332,11 +353,11 @@ When you complete a skill's checklist, check the boxes and add a completion time
|
|
|
332
353
|
|
|
333
354
|
## Bundling
|
|
334
355
|
|
|
335
|
-
`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. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools 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.
|
|
356
|
+
`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/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools 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.
|
|
336
357
|
|
|
337
358
|
**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.
|
|
338
359
|
|
|
339
|
-
**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`.
|
|
360
|
+
**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`.
|
|
340
361
|
|
|
341
362
|
---
|
|
342
363
|
|
|
@@ -361,9 +382,15 @@ security: false # optional — true ONLY for a source
|
|
|
361
382
|
|
|
362
383
|
`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.
|
|
363
384
|
|
|
364
|
-
**Section order
|
|
385
|
+
**Section order:** Added, Changed, Deprecated, Removed, Fixed, Security, then Dependencies. Include only sections with entries — don't ship empty headers.
|
|
386
|
+
|
|
387
|
+
**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 `framework-skills/release-and-publish/SKILL.md` for the tag format.
|
|
388
|
+
|
|
389
|
+
---
|
|
390
|
+
|
|
391
|
+
## Publishing
|
|
365
392
|
|
|
366
|
-
**
|
|
393
|
+
**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.
|
|
367
394
|
|
|
368
395
|
---
|
|
369
396
|
|
|
@@ -393,7 +420,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
|
|
|
393
420
|
- [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
|
|
394
421
|
- [ ] Registered in `createApp()` arrays (directly or via barrel exports)
|
|
395
422
|
- [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
|
|
396
|
-
- [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` =
|
|
397
|
-
- [ ] `.codex-plugin/mcp.json` updated — server name key
|
|
398
|
-
- [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry
|
|
423
|
+
- [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name; `interface.shortDescription` from `package.json` description
|
|
424
|
+
- [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; user-supplied variables are listed in `env_vars`, never empty `env` values
|
|
425
|
+
- [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name; user-supplied variables declared in `userConfig` and referenced as `${user_config.<option>}`
|
|
399
426
|
- [ ] `npm run devcheck` passes
|
package/CLAUDE.md
CHANGED
|
@@ -1,11 +1,11 @@
|
|
|
1
1
|
# Developer Protocol
|
|
2
2
|
|
|
3
3
|
**Server:** ris-austria-mcp-server
|
|
4
|
-
**Version:** 0.4.
|
|
5
|
-
**Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.
|
|
6
|
-
**Engines:** Bun ≥1.
|
|
4
|
+
**Version:** 0.4.4
|
|
5
|
+
**Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.6`
|
|
6
|
+
**Engines:** Bun ≥1.4.0, Node ≥24.0.0
|
|
7
7
|
**MCP SDK:** `@modelcontextprotocol/server` ^2.0.0
|
|
8
|
-
**Zod:** ^4.
|
|
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
|
---
|
|
@@ -145,6 +146,7 @@ The entry point pins the machine identity and immutable public catalog cache hin
|
|
|
145
146
|
await createApp({
|
|
146
147
|
name: 'ris-austria-mcp-server',
|
|
147
148
|
title: 'ris-austria-mcp-server',
|
|
149
|
+
sessionMode: 'stateless',
|
|
148
150
|
cacheHints: {
|
|
149
151
|
'tools/list': { ttlMs: 3_600_000, cacheScope: 'public' },
|
|
150
152
|
'resources/list': { ttlMs: 3_600_000, cacheScope: 'public' },
|
|
@@ -161,6 +163,23 @@ await createApp({
|
|
|
161
163
|
|
|
162
164
|
`package.json` is the canonical description source; do not duplicate it into `createApp()`.
|
|
163
165
|
|
|
166
|
+
### Session posture and shutdown
|
|
167
|
+
|
|
168
|
+
`sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a
|
|
169
|
+
deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an
|
|
170
|
+
empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the
|
|
171
|
+
option). Every RIS tool answers from the request it was given, so `stateless` is the honest
|
|
172
|
+
declaration here. Add `require: 'stateful'` only if a tool ever asks the caller for input
|
|
173
|
+
mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than
|
|
174
|
+
serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused.
|
|
175
|
+
|
|
176
|
+
`teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d
|
|
177
|
+
timer there. It runs after the transport stops and before the logger closes, on every shutdown
|
|
178
|
+
path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step
|
|
179
|
+
never settles within the framework's 10 s ceiling). `RisService` holds nothing across requests
|
|
180
|
+
— every fetch is bounded by the caller's signal and the retry deadline — so this server
|
|
181
|
+
declares no `teardown`.
|
|
182
|
+
|
|
164
183
|
---
|
|
165
184
|
|
|
166
185
|
## Context
|
|
@@ -180,7 +199,7 @@ Handlers receive a unified `ctx` object. Key properties:
|
|
|
180
199
|
|
|
181
200
|
Handlers throw — the framework catches, classifies, and formats.
|
|
182
201
|
|
|
183
|
-
**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.
|
|
202
|
+
**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.
|
|
184
203
|
|
|
185
204
|
```ts
|
|
186
205
|
import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
|
|
@@ -213,7 +232,7 @@ throw new Error('Invalid query format'); // → ValidationError
|
|
|
213
232
|
|
|
214
233
|
// McpError — when no factory exists for the code
|
|
215
234
|
import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
|
|
216
|
-
throw new McpError(JsonRpcErrorCode.
|
|
235
|
+
throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
|
|
217
236
|
```
|
|
218
237
|
|
|
219
238
|
See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
|
|
@@ -257,9 +276,9 @@ src/
|
|
|
257
276
|
|
|
258
277
|
## Skills
|
|
259
278
|
|
|
260
|
-
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.
|
|
279
|
+
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.
|
|
261
280
|
|
|
262
|
-
**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.
|
|
281
|
+
**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.
|
|
263
282
|
|
|
264
283
|
Available skills:
|
|
265
284
|
|
|
@@ -278,8 +297,9 @@ Available skills:
|
|
|
278
297
|
| `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
|
|
279
298
|
| `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
|
|
280
299
|
| `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
|
|
281
|
-
| `git-wrapup` | Land working-tree changes as a
|
|
282
|
-
| `release-
|
|
300
|
+
| `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 |
|
|
301
|
+
| `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 |
|
|
302
|
+
| `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
|
|
283
303
|
| `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
|
|
284
304
|
| `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
|
|
285
305
|
| `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
|
|
@@ -298,7 +318,7 @@ Available skills:
|
|
|
298
318
|
| `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
|
|
299
319
|
| `api-workers` | Cloudflare Workers runtime |
|
|
300
320
|
|
|
301
|
-
**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.
|
|
321
|
+
**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.
|
|
302
322
|
|
|
303
323
|
When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
|
|
304
324
|
|
|
@@ -314,7 +334,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
|
|
|
314
334
|
| `bun run rebuild` | Clean + build |
|
|
315
335
|
| `bun run clean` | Remove build artifacts |
|
|
316
336
|
| `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
|
|
317
|
-
| `bun run audit:
|
|
337
|
+
| `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` |
|
|
338
|
+
| `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` |
|
|
318
339
|
| `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
|
|
319
340
|
| `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
|
|
320
341
|
| `bun run list-skills` | Print the skill registry |
|
|
@@ -332,11 +353,11 @@ When you complete a skill's checklist, check the boxes and add a completion time
|
|
|
332
353
|
|
|
333
354
|
## Bundling
|
|
334
355
|
|
|
335
|
-
`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. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools 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.
|
|
356
|
+
`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/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools 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.
|
|
336
357
|
|
|
337
358
|
**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.
|
|
338
359
|
|
|
339
|
-
**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`.
|
|
360
|
+
**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`.
|
|
340
361
|
|
|
341
362
|
---
|
|
342
363
|
|
|
@@ -361,9 +382,15 @@ security: false # optional — true ONLY for a source
|
|
|
361
382
|
|
|
362
383
|
`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.
|
|
363
384
|
|
|
364
|
-
**Section order
|
|
385
|
+
**Section order:** Added, Changed, Deprecated, Removed, Fixed, Security, then Dependencies. Include only sections with entries — don't ship empty headers.
|
|
386
|
+
|
|
387
|
+
**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 `framework-skills/release-and-publish/SKILL.md` for the tag format.
|
|
388
|
+
|
|
389
|
+
---
|
|
390
|
+
|
|
391
|
+
## Publishing
|
|
365
392
|
|
|
366
|
-
**
|
|
393
|
+
**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.
|
|
367
394
|
|
|
368
395
|
---
|
|
369
396
|
|
|
@@ -393,7 +420,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
|
|
|
393
420
|
- [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
|
|
394
421
|
- [ ] Registered in `createApp()` arrays (directly or via barrel exports)
|
|
395
422
|
- [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
|
|
396
|
-
- [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` =
|
|
397
|
-
- [ ] `.codex-plugin/mcp.json` updated — server name key
|
|
398
|
-
- [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry
|
|
423
|
+
- [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name; `interface.shortDescription` from `package.json` description
|
|
424
|
+
- [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; user-supplied variables are listed in `env_vars`, never empty `env` values
|
|
425
|
+
- [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name; user-supplied variables declared in `userConfig` and referenced as `${user_config.<option>}`
|
|
399
426
|
- [ ] `npm run devcheck` passes
|