@cyanheads/interpro-mcp-server 0.0.0-stage → 0.1.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 (82) hide show
  1. package/AGENTS.md +376 -0
  2. package/CLAUDE.md +376 -0
  3. package/Dockerfile +186 -0
  4. package/LICENSE +201 -0
  5. package/README.md +289 -2
  6. package/changelog/0.1.x/0.1.1.md +20 -0
  7. package/changelog/0.1.x/0.1.2.md +27 -0
  8. package/changelog/template.md +151 -0
  9. package/dist/index.d.ts +7 -0
  10. package/dist/index.d.ts.map +1 -0
  11. package/dist/index.js +34 -0
  12. package/dist/index.js.map +1 -0
  13. package/dist/mcp-server/tools/definitions/interpro-find-proteins-by-domain.tool.d.ts +180 -0
  14. package/dist/mcp-server/tools/definitions/interpro-find-proteins-by-domain.tool.d.ts.map +1 -0
  15. package/dist/mcp-server/tools/definitions/interpro-find-proteins-by-domain.tool.js +212 -0
  16. package/dist/mcp-server/tools/definitions/interpro-find-proteins-by-domain.tool.js.map +1 -0
  17. package/dist/mcp-server/tools/definitions/interpro-get-clan.tool.d.ts +160 -0
  18. package/dist/mcp-server/tools/definitions/interpro-get-clan.tool.d.ts.map +1 -0
  19. package/dist/mcp-server/tools/definitions/interpro-get-clan.tool.js +259 -0
  20. package/dist/mcp-server/tools/definitions/interpro-get-clan.tool.js.map +1 -0
  21. package/dist/mcp-server/tools/definitions/interpro-get-entry.tool.d.ts +131 -0
  22. package/dist/mcp-server/tools/definitions/interpro-get-entry.tool.d.ts.map +1 -0
  23. package/dist/mcp-server/tools/definitions/interpro-get-entry.tool.js +105 -0
  24. package/dist/mcp-server/tools/definitions/interpro-get-entry.tool.js.map +1 -0
  25. package/dist/mcp-server/tools/definitions/interpro-get-protein-domains.tool.d.ts +172 -0
  26. package/dist/mcp-server/tools/definitions/interpro-get-protein-domains.tool.d.ts.map +1 -0
  27. package/dist/mcp-server/tools/definitions/interpro-get-protein-domains.tool.js +374 -0
  28. package/dist/mcp-server/tools/definitions/interpro-get-protein-domains.tool.js.map +1 -0
  29. package/dist/mcp-server/tools/definitions/interpro-list-reference.tool.d.ts +89 -0
  30. package/dist/mcp-server/tools/definitions/interpro-list-reference.tool.d.ts.map +1 -0
  31. package/dist/mcp-server/tools/definitions/interpro-list-reference.tool.js +99 -0
  32. package/dist/mcp-server/tools/definitions/interpro-list-reference.tool.js.map +1 -0
  33. package/dist/mcp-server/tools/definitions/interpro-search-entries.tool.d.ts +190 -0
  34. package/dist/mcp-server/tools/definitions/interpro-search-entries.tool.d.ts.map +1 -0
  35. package/dist/mcp-server/tools/definitions/interpro-search-entries.tool.js +165 -0
  36. package/dist/mcp-server/tools/definitions/interpro-search-entries.tool.js.map +1 -0
  37. package/dist/services/interpro/budget.d.ts +26 -0
  38. package/dist/services/interpro/budget.d.ts.map +1 -0
  39. package/dist/services/interpro/budget.js +41 -0
  40. package/dist/services/interpro/budget.js.map +1 -0
  41. package/dist/services/interpro/cursors.d.ts +25 -0
  42. package/dist/services/interpro/cursors.d.ts.map +1 -0
  43. package/dist/services/interpro/cursors.js +99 -0
  44. package/dist/services/interpro/cursors.js.map +1 -0
  45. package/dist/services/interpro/description-text.d.ts +3 -0
  46. package/dist/services/interpro/description-text.d.ts.map +1 -0
  47. package/dist/services/interpro/description-text.js +179 -0
  48. package/dist/services/interpro/description-text.js.map +1 -0
  49. package/dist/services/interpro/format.d.ts +17 -0
  50. package/dist/services/interpro/format.d.ts.map +1 -0
  51. package/dist/services/interpro/format.js +130 -0
  52. package/dist/services/interpro/format.js.map +1 -0
  53. package/dist/services/interpro/http-adapter.d.ts +11 -0
  54. package/dist/services/interpro/http-adapter.d.ts.map +1 -0
  55. package/dist/services/interpro/http-adapter.js +134 -0
  56. package/dist/services/interpro/http-adapter.js.map +1 -0
  57. package/dist/services/interpro/interpro-service.d.ts +57 -0
  58. package/dist/services/interpro/interpro-service.d.ts.map +1 -0
  59. package/dist/services/interpro/interpro-service.js +284 -0
  60. package/dist/services/interpro/interpro-service.js.map +1 -0
  61. package/dist/services/interpro/reference.d.ts +31 -0
  62. package/dist/services/interpro/reference.d.ts.map +1 -0
  63. package/dist/services/interpro/reference.js +122 -0
  64. package/dist/services/interpro/reference.js.map +1 -0
  65. package/dist/services/interpro/relationships.d.ts +38 -0
  66. package/dist/services/interpro/relationships.d.ts.map +1 -0
  67. package/dist/services/interpro/relationships.js +70 -0
  68. package/dist/services/interpro/relationships.js.map +1 -0
  69. package/dist/services/interpro/routing.d.ts +24 -0
  70. package/dist/services/interpro/routing.d.ts.map +1 -0
  71. package/dist/services/interpro/routing.js +106 -0
  72. package/dist/services/interpro/routing.js.map +1 -0
  73. package/dist/services/interpro/schemas.d.ts +192 -0
  74. package/dist/services/interpro/schemas.d.ts.map +1 -0
  75. package/dist/services/interpro/schemas.js +226 -0
  76. package/dist/services/interpro/schemas.js.map +1 -0
  77. package/dist/services/interpro/upstream-errors.d.ts +43 -0
  78. package/dist/services/interpro/upstream-errors.d.ts.map +1 -0
  79. package/dist/services/interpro/upstream-errors.js +49 -0
  80. package/dist/services/interpro/upstream-errors.js.map +1 -0
  81. package/package.json +104 -4
  82. package/server.json +91 -0
package/CLAUDE.md ADDED
@@ -0,0 +1,376 @@
1
+ # Developer Protocol
2
+
3
+ **Server:** @cyanheads/interpro-mcp-server
4
+ **Version:** 0.1.2
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.15`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` ^2.3.1
8
+ **Zod:** ^4.6.7
9
+
10
+ > **Read the framework docs first:** `node_modules/@cyanheads/mcp-ts-core/CLAUDE.md` contains the full API reference — builders, Context, error codes, exports, patterns. This file covers server-specific conventions only.
11
+
12
+ ---
13
+
14
+ ## What's Next?
15
+
16
+ When the user asks what's next or needs direction, suggest options based on the current project state. Common next steps:
17
+
18
+ 1. **Re-run the `setup` skill** — ensures CLAUDE.md, skills, structure, and metadata are populated and up to date with the current codebase
19
+ 2. **Run the `design-mcp-server` skill** — if the tool/resource surface hasn't been mapped yet, work through domain design
20
+ 3. **Add tools/resources/prompts** — scaffold new definitions using the `add-tool`, `add-app-tool`, `add-resource`, `add-prompt` skills
21
+ 4. **Add services** — scaffold domain service integrations using the `add-service` skill
22
+ 5. **Add tests** — scaffold tests for existing definitions using the `add-test` skill
23
+ 6. **Field-test definitions** — exercise tools/resources/prompts with real inputs using the `field-test` skill, get a report of issues and pain points
24
+ 7. **Run `devcheck`** — lint, format, typecheck, and security audit
25
+ 8. **Run the `security-pass` skill** — audit handlers for MCP-specific security gaps: output injection, scope blast radius, input sinks, tenant isolation
26
+ 9. **Run the `polish-docs-meta` skill** — finalize README, CHANGELOG, metadata, and agent protocol for shipping
27
+ 10. **Run the `maintenance` skill** — investigate changelogs, adopt upstream changes, and sync skills after `bun update --latest`
28
+
29
+ Tailor suggestions to what's actually missing or stale — don't recite the full list every time.
30
+
31
+ ---
32
+
33
+ ## Core Rules
34
+
35
+ - **Keep gitignored planning notes under `docs/` private.** Exclude them from git, npm, bundles, Docker images, and every other distribution surface, and never reference them from public docs.
36
+ - **Editing agents never commit, tag, push, or publish.** They hand verified working-tree changes to the orchestrator.
37
+ - **Logic throws, framework catches.** Tool/resource handlers are pure — throw on failure, no `try/catch`. Plain `Error` is fine; the framework catches, classifies, and formats. Use error factories (`notFound()`, `validationError()`, etc.) when the error code matters.
38
+ - **Use `ctx.log`** for request-scoped logging. No `console` calls.
39
+ - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
40
+ - **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.
41
+ - **Secrets in env vars only** — never hardcoded.
42
+ - **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.
43
+ - **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.
44
+
45
+ ---
46
+
47
+ ## Patterns
48
+
49
+ ### Tool
50
+
51
+ Abridged from `src/mcp-server/tools/definitions/interpro-get-entry.tool.ts`. All six tools share this shape: a service call through `service.begin(ctx)`, `ctx.enrich` for notices, a per-tool `errors` contract, and the shared `formatInterpro` formatter.
52
+
53
+ ```ts
54
+ import { tool, z } from '@cyanheads/mcp-ts-core';
55
+ import { formatInterpro } from '@/services/interpro/format.js';
56
+ import { getInterproService } from '@/services/interpro/interpro-service.js';
57
+ import { resolveEntry } from '@/services/interpro/routing.js';
58
+
59
+ export const interproGetEntry = tool('interpro_get_entry', {
60
+ title: 'InterPro entry metadata',
61
+ description: 'Retrieve one InterPro or member-database entry, including description, hierarchy, …',
62
+ annotations: { readOnlyHint: true, idempotentHint: true, openWorldHint: true },
63
+ auth: ['tool:interpro_get_entry:read'],
64
+ input: z.object({
65
+ accession: AccessionSchema.describe('InterPro or member-database entry accession, such as IPR011615 or PF00870; no URL syntax.'),
66
+ sourceDatabase: optionalString(SourceDatabaseSchema).describe('Database slug; inferred from standard accession prefixes when omitted.'),
67
+ includeThumbnail: z.boolean().default(false).describe('Include each Wikipedia thumbnail image …'),
68
+ }),
69
+ output: z.object({ accession: z.string().describe('…'), entry: EntryMetadataSchema.describe('…'), /* … */ }),
70
+ enrichment: { notice: z.string().optional().describe('Omitted Wikipedia thumbnail size and how to include it.') },
71
+ errors: [
72
+ { reason: 'entry_not_found', code: JsonRpcErrorCode.NotFound, when: '…', retryable: false,
73
+ recovery: 'Call interpro_search_entries in the correct database, or interpro_list_reference with topic accession_patterns.',
74
+ thrownBy: 'service' },
75
+ ...UPSTREAM_ERRORS,
76
+ ],
77
+
78
+ async handler(input, ctx) {
79
+ const target = resolveEntry(input.accession, input.sourceDatabase);
80
+ const service = getInterproService();
81
+ const response = await service.request(
82
+ service.begin(ctx),
83
+ ['entry', target.sourceDatabase, target.accession],
84
+ {},
85
+ detailSchema(EntryMetadataSchema),
86
+ { missing: { reason: 'entry_not_found', ...target } },
87
+ );
88
+ // …project thumbnails, ctx.enrich.notice(…)
89
+ return { ...target, entry: response.data.metadata, url: '…', sourceUrl: response.sourceUrl };
90
+ },
91
+
92
+ // format() populates content[] — the twin of structuredContent. Different clients
93
+ // read different surfaces, so both must carry the same data; the lint step checks
94
+ // that every `output` field appears in the rendered text.
95
+ format: formatInterpro,
96
+ });
97
+ ```
98
+
99
+ There are no resources or prompts and no server-specific environment variables: the InterPro API is keyless. Search/member pages clamp positive integer limits to 100, discovery to 50, with default 20 and composed notices. GO filters require the InterPro source; member recovery follows `member_databases` or `integratedInto`. Discovery requests native `extra_fields.is_fragment` on every page, binds only explicit `isFragment` selections to cursor scope, and preserves unknown status. Entry detail alone adds readable `descriptionText` through the `htmlparser2` streaming tokenizer while preserving raw descriptions and annotation flags.
100
+
101
+ ### Server identity and instructions
102
+
103
+ `src/index.ts` passes `name` and `title` as the bare `interpro-mcp-server` and server-level `instructions` sent on every `initialize`:
104
+
105
+ ```ts
106
+ await createApp({
107
+ name: 'interpro-mcp-server',
108
+ title: 'interpro-mcp-server',
109
+ tools: [/* six definitions */],
110
+ sessionMode: 'stateless',
111
+ setup() { initInterproService(); },
112
+ teardown() { disposeInterproService(); },
113
+ instructions: '…',
114
+ });
115
+ ```
116
+
117
+ `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). `teardown()` is the `setup()` counterpart; it runs after the transport stops and before the logger closes, on every shutdown path.
118
+
119
+ ---
120
+
121
+ ## Context
122
+
123
+ Handlers receive a unified `ctx` object. Key properties:
124
+
125
+ | Property | Description |
126
+ |:---------|:------------|
127
+ | `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. |
128
+ | `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). |
129
+ | `ctx.fail` | Throws a typed failure for a reason declared in the tool's `errors` contract. |
130
+ | `ctx.signal` | `AbortSignal` for cancellation; the service composes it with its per-call deadline. |
131
+ | `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
132
+ | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
133
+
134
+ ---
135
+
136
+ ## Errors
137
+
138
+ Handlers throw — the framework catches, classifies, and formats.
139
+
140
+ **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.
141
+
142
+ ```ts
143
+ import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
144
+
145
+ errors: [
146
+ { reason: 'no_match', code: JsonRpcErrorCode.NotFound,
147
+ when: 'No item matched the query',
148
+ recovery: 'Broaden the query or check the spelling and try again.' },
149
+ ],
150
+ async handler(input, ctx) {
151
+ const item = await db.find(input.id);
152
+ if (!item) throw ctx.fail('no_match', `No item ${input.id}`);
153
+ return item;
154
+ }
155
+ ```
156
+
157
+ **Declare contracts inline on each tool.** The contract is part of the tool's public surface — one file should give the full picture. Don't extract a shared `errors[]` constant; per-tool repetition is the intended cost of locality.
158
+
159
+ **Fallback (no contract entry fits):** throw via factories or plain `Error`.
160
+
161
+ ```ts
162
+ // Error factories — explicit code
163
+ import { notFound, serviceUnavailable } from '@cyanheads/mcp-ts-core/errors';
164
+ throw notFound('Item not found', { itemId });
165
+ throw serviceUnavailable('API unavailable', { url }, { cause: err });
166
+
167
+ // Plain Error — framework auto-classifies from message patterns
168
+ throw new Error('Item not found'); // → NotFound
169
+ throw new Error('Invalid query format'); // → ValidationError
170
+
171
+ // McpError — when no factory exists for the code
172
+ import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
173
+ throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
174
+ ```
175
+
176
+ See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
177
+
178
+ ---
179
+
180
+ ## Structure
181
+
182
+ ```text
183
+ src/
184
+ index.ts # createApp() entry point
185
+ services/
186
+ interpro/
187
+ interpro-service.ts # Paced, cancellable request boundary (init/accessor pattern)
188
+ http-adapter.ts # node:https HTTP/1.1 transport with 204 handling
189
+ routing.ts # Accession → database routing, fixed-origin URL building
190
+ schemas.ts # Wire and output Zod schemas
191
+ cursors.ts # Opaque cursor envelopes
192
+ budget.ts # 100,000-byte response budget and whole-item fitting
193
+ relationships.ts # Clan relationship-graph slicing
194
+ reference.ts # Static vocabulary for interpro_list_reference
195
+ format.ts # Shared content[] formatter
196
+ description-text.ts # Readable HTML fragment projection for entry detail
197
+ upstream-errors.ts # Shared upstream error contract rows
198
+ mcp-server/
199
+ tools/definitions/
200
+ interpro-[name].tool.ts # Six tool definitions
201
+ tests/
202
+ services/ # Service, adapter, and budget tests
203
+ tools/ # Tool contract tests
204
+ ```
205
+
206
+ ---
207
+
208
+ ## Naming
209
+
210
+ | What | Convention | Example |
211
+ |:-----|:-----------|:--------|
212
+ | Files | kebab-case with suffix | `interpro-get-entry.tool.ts` |
213
+ | Tool/resource/prompt names | snake_case | `interpro_get_entry` |
214
+ | Directories | kebab-case | `src/services/interpro/` |
215
+ | Descriptions | Single string or template literal, no `+` concatenation | `'Search items by query and filter.'` |
216
+
217
+ ---
218
+
219
+ ## Skills
220
+
221
+ 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.
222
+
223
+ **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.
224
+
225
+ Available skills:
226
+
227
+ | Skill | Purpose |
228
+ |:------|:--------|
229
+ | `setup` | Post-init project orientation |
230
+ | `design-mcp-server` | Design tool surface, resources, and services for a new server |
231
+ | `add-tool` | Scaffold a new tool definition |
232
+ | `add-app-tool` | Scaffold an MCP App tool + paired UI resource |
233
+ | `add-resource` | Scaffold a new resource definition |
234
+ | `add-prompt` | Scaffold a new prompt definition |
235
+ | `add-service` | Scaffold a new service integration |
236
+ | `add-test` | Scaffold test file for a tool, resource, or service |
237
+ | `field-test` | Exercise tools/resources/prompts with real inputs, verify behavior, report issues |
238
+ | `tool-defs-analysis` | Read-only audit of MCP definition language across the surface — voice, leaks, defaults, recovery hints, output descriptions |
239
+ | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
240
+ | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
241
+ | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
242
+ | `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 |
243
+ | `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 |
244
+ | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
245
+ | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
246
+ | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
247
+ | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
248
+ | `report-issue-local` | File a bug or feature request against this server's own repo via `gh` CLI |
249
+ | `techniques` | Catalog of response/data-shaping techniques — overflow handling, payload shaping, retrieval patterns |
250
+ | `api-auth` | Auth modes, scopes, JWT/OAuth |
251
+ | `api-canvas` | DataCanvas: register tabular data, run SQL, export, plus the `spillover()` helper for big result sets — Tier 3 opt-in |
252
+ | `api-config` | AppConfig, parseConfig, env vars |
253
+ | `api-context` | Context interface, RequestContext, logger, state, multi-round-trip input |
254
+ | `api-errors` | McpError, JsonRpcErrorCode, error patterns |
255
+ | `api-linter` | Definition linter rule catalog — invoked by `bun run lint:mcp` and `devcheck` |
256
+ | `api-mirror` | MirrorService: persistent self-refreshing local mirror (embedded SQLite + FTS5) of a bulk upstream dataset — Tier 3 opt-in |
257
+ | `api-services` | LLM, Speech, Graph services |
258
+ | `api-testing` | createMockContext, test patterns |
259
+ | `api-utils` | Formatting, parsing, security, pagination, scheduling, telemetry helpers |
260
+ | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
261
+ | `api-workers` | Cloudflare Workers runtime |
262
+
263
+ **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.
264
+
265
+ When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
266
+
267
+ ---
268
+
269
+ ## Commands
270
+
271
+ **Runtime:** Scripts use Bun's native TypeScript execution — `bun run <cmd>` is the standard invocation. `npm run <cmd>` also works (npm delegates to bun).
272
+
273
+ | Command | Purpose |
274
+ |:--------|:--------|
275
+ | `bun run build` | Compile TypeScript |
276
+ | `bun run rebuild` | Clean + build |
277
+ | `bun run clean` | Remove build artifacts |
278
+ | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
279
+ | `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` |
280
+ | `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` |
281
+ | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
282
+ | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
283
+ | `bun run list-skills` | Print the skill registry |
284
+ | `bun run tree` | Generate directory structure doc |
285
+ | `bun run format` | Auto-fix formatting (safe fixes only) |
286
+ | `bun run format:unsafe` | Also apply Biome's unsafe autofixes — review the diff; they can change behavior |
287
+ | `bun run test` | Run tests (Vitest — use `bun run test`, not `bun test`) |
288
+ | `bun run test:coverage` | Run tests with Istanbul coverage |
289
+ | `bun run start` | Run the built server with the configured transport |
290
+ | `bun run start:stdio` | Production mode (stdio) |
291
+ | `bun run start:http` | Production mode (HTTP) |
292
+ | `bun run release:github` | Create the GitHub Release from the annotated tag |
293
+ | `bun run publish-mcp` | Publish `server.json` to the MCP Registry |
294
+ | `bun run changelog:build` | Regenerate `CHANGELOG.md` from `changelog/*.md` |
295
+ | `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
296
+ | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
297
+
298
+ **Waived `devcheck` warnings.** `bun run devcheck` emits six `format-parity-depth-limit` warnings, for the `…fragments[].start`, `…fragments[].end`, and `…fragments[].dc-status` output fields of `interpro_find_proteins_by_domain` and `interpro_get_protein_domains`. The schema is finite but deeper than the framework's depth-8 parity walker, and tests prove both surfaces render those fields. The owner waived exactly these six, pending [cyanheads/mcp-ts-core#531](https://github.com/cyanheads/mcp-ts-core/issues/531). Don't flatten or weaken the schema, and don't add suppressions to clear them. Any other warning, or a seventh of this kind, still blocks shipping.
299
+
300
+ **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.
301
+
302
+ ---
303
+
304
+ ## Bundling
305
+
306
+ `npm run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. 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.
307
+
308
+ **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": ""`.
309
+
310
+ **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`.
311
+
312
+ ---
313
+
314
+ ## Changelog
315
+
316
+ Directory-based, grouped by minor series via the `.x` semver-wildcard convention. Source of truth: `changelog/<major.minor>.x/<version>.md` (e.g. `changelog/0.1.x/0.1.0.md`) — one file per release, shipped in the npm package. At release, author the per-version file with a concrete version and date, then run `npm run changelog:build` to regenerate the rollup. `changelog/template.md` is a **pristine format reference** — never edited or moved; read it for the frontmatter + section layout when scaffolding. `CHANGELOG.md` is a **navigation index** (header + link + summary per version), regenerated by `npm run changelog:build` — devcheck hard-fails on drift; never hand-edit it.
317
+
318
+ Each per-version file opens with YAML frontmatter:
319
+
320
+ ```markdown
321
+ ---
322
+ summary: "One-line headline, ≤350 chars" # required — powers the rollup index
323
+ breaking: false # optional — true flags breaking changes
324
+ security: false # optional — true ONLY for a source-code security fix, never a dependency CVE bump
325
+ ---
326
+
327
+ # 0.1.0 — YYYY-MM-DD
328
+ ...
329
+ ```
330
+
331
+ `breaking: true` renders a `· ⚠️ Breaking` badge — use it when consumers must update code on upgrade (signature changes, removed APIs, config renames). `security: true` renders a `· 🛡️ Security` badge and pairs with a `## Security` body section — set it only for a security fix in this server's *own source code*, never for a routine dependency or transitive CVE bump (record those under `## Dependencies`). When both are set, badges render `· ⚠️ Breaking · 🛡️ Security`.
332
+
333
+ `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.
334
+
335
+ **Section order:** the Keep a Changelog sequence — Added, Changed, Deprecated, Removed, Fixed, Security — then `Dependencies` last. Include only sections with entries — don't ship empty headers.
336
+
337
+ **Tag annotations** render as GitHub Release bodies via `--notes-from-tag`. They must be structured markdown — never a flat comma-separated string. Subject omits the version number (GitHub prepends it). See `changelog/template.md` for the full format reference.
338
+
339
+ ---
340
+
341
+ ## Publishing
342
+
343
+ Every release goes through a release PR — `git-wrapup`'s "Release PR mode", mode `straight-through`. Run `git-wrapup` and `release-and-publish` sequentially. Open `release/<version>` as a PR and fast-forward it to `main` locally with `git merge --ff-only`; never use the GitHub merge button or `gh pr merge`. There is no independent review gate. CodeQL, required checks, and security alerts must still pass before release.
344
+
345
+ ---
346
+
347
+ ## Imports
348
+
349
+ ```ts
350
+ // Framework — z is re-exported, no separate zod import needed
351
+ import { tool, z } from '@cyanheads/mcp-ts-core';
352
+ import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
353
+
354
+ // Server's own code — via path alias
355
+ import { getMyService } from '@/services/my-domain/my-service.js';
356
+ ```
357
+
358
+ ---
359
+
360
+ ## Checklist
361
+
362
+ - [ ] Zod schemas: all fields have `.describe()`, only JSON-Schema-serializable types (no `z.custom()`, `z.date()`, `z.transform()`, `z.bigint()`, `z.symbol()`, `z.void()`, `z.map()`, `z.set()`, `z.function()`, `z.nan()`)
363
+ - [ ] Optional nested objects: handler guards for empty inner values from form-based clients (`if (input.obj?.field && ...)`, not just `if (input.obj)`). When regex/length constraints matter, use `z.union([z.literal(''), z.string().regex(...).describe(...)])` — literal variants are exempt from `describe-on-fields`.
364
+ - [ ] JSDoc `@fileoverview` + `@module` on every file
365
+ - [ ] `ctx.log` for logging, `ctx.state` for storage
366
+ - [ ] Handlers throw on failure — error factories or plain `Error`, no try/catch
367
+ - [ ] `format()` renders all data the LLM needs — different clients forward different surfaces (Claude Code → `structuredContent`, Claude Desktop → `content[]`); both must carry the same data
368
+ - [ ] If wrapping external API: raw/domain/output schemas reviewed against real upstream sparsity/nullability before finalizing required vs optional fields
369
+ - [ ] If wrapping external API: normalization and `format()` preserve uncertainty; do not fabricate facts from missing upstream data
370
+ - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
371
+ - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
372
+ - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
373
+ - [ ] `.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
374
+ - [ ] `.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
375
+ - [ ] `.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`
376
+ - [ ] `npm run devcheck` passes
package/Dockerfile ADDED
@@ -0,0 +1,186 @@
1
+ # ==============================================================================
2
+ # Build Stage
3
+ #
4
+ # This stage installs all dependencies (including dev), builds the TypeScript
5
+ # source code into JavaScript, and prepares the production assets.
6
+ #
7
+ # Pinned to $BUILDPLATFORM rather than the target platform: `bun run build` emits
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
+ #
13
+ # The constraint this assumes: the build stage produces platform-independent
14
+ # output. A stage that compiles a native addon needs the target-arch toolchain
15
+ # and cannot cross-compile this way — drop the flag there.
16
+ # ==============================================================================
17
+ FROM --platform=$BUILDPLATFORM oven/bun:1.4.4 AS build
18
+
19
+ WORKDIR /usr/src/app
20
+
21
+ # Copy dependency manifests for optimized layer caching
22
+ COPY package.json bun.lock ./
23
+
24
+ # Install all dependencies (including dev dependencies for building).
25
+ # The BuildKit cache mount persists Bun's global package cache across builds.
26
+ RUN --mount=type=cache,target=/root/.bun/install/cache \
27
+ bun install --frozen-lockfile --ignore-scripts
28
+
29
+ # Copy the rest of the source code
30
+ COPY . .
31
+
32
+ # Build the application
33
+ RUN bun run build
34
+
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.4 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. Anything this server
78
+ # actually imports belongs in its own `dependencies`, so nothing needed at
79
+ # 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. A server on a
101
+ # musl (Alpine) runtime image drops these two lines.
102
+ COPY scripts/prune-musl-packages.ts ./scripts/
103
+ RUN bun scripts/prune-musl-packages.ts
104
+
105
+ # The seeded scanner served only the installs above; keep it out of the image.
106
+ RUN rm -rf node_modules/@socketsecurity/bun-security-scanner
107
+
108
+
109
+ # ==============================================================================
110
+ # Production Stage
111
+ #
112
+ # This stage creates a minimal, optimized, and secure image for running the
113
+ # application. It uses a slim base image and only includes production
114
+ # dependencies and build artifacts. Its only Bun invocations are HEALTHCHECK
115
+ # and CMD, which run on the real target at container start.
116
+ # ==============================================================================
117
+ FROM oven/bun:1.4.4-slim AS production
118
+
119
+ WORKDIR /usr/src/app
120
+
121
+ # Set the environment to production for performance.
122
+ ENV NODE_ENV=production
123
+
124
+ # OCI image metadata (https://github.com/opencontainers/image-spec/blob/main/annotations.md)
125
+ ARG APP_VERSION
126
+ LABEL org.opencontainers.image.title="interpro-mcp-server"
127
+ LABEL org.opencontainers.image.description="Search InterPro entries, map protein domains and functional sites, and find proteins by domain via MCP. STDIO or Streamable HTTP."
128
+ LABEL org.opencontainers.image.licenses="Apache-2.0"
129
+ LABEL org.opencontainers.image.version="${APP_VERSION}"
130
+ LABEL org.opencontainers.image.source="https://github.com/cyanheads/interpro-mcp-server"
131
+
132
+ # The manifest comes from the build context: the deps stage's copy was rewritten
133
+ # by the OTel install, and the runtime reads only its name, version, and type.
134
+ COPY package.json ./
135
+ COPY --from=deps /usr/src/app/node_modules ./node_modules
136
+
137
+ # Copy the compiled application code from the build stage
138
+ COPY --from=build /usr/src/app/dist ./dist
139
+
140
+ # Mirror CLI (MirrorService adopters only — Tier 3, opt-in):
141
+ # Copy your mirror lifecycle scripts and emit a runtime tsconfig so Bun resolves
142
+ # the @/ path alias against ./dist/ rather than ./src/.
143
+ # See the api-mirror skill for the full recipe.
144
+ #
145
+ # COPY --from=build /usr/src/app/scripts/<your>-mirror-init.ts \
146
+ # /usr/src/app/scripts/<your>-mirror-refresh.ts \
147
+ # /usr/src/app/scripts/<your>-mirror-verify.ts \
148
+ # /usr/src/app/scripts/_mirror-context.ts \
149
+ # ./scripts/
150
+ # RUN echo '{"compilerOptions":{"baseUrl":".","paths":{"@/*":["./dist/*"]}}}' > tsconfig.json
151
+
152
+ # The 'oven/bun' image already provides a non-root user named 'bun'.
153
+ # We will use this existing user for enhanced security.
154
+
155
+ # Create and set permissions for the log directory, assigning ownership to the 'bun' user.
156
+ RUN mkdir -p /var/log/interpro-mcp-server && chown -R bun:bun /var/log/interpro-mcp-server
157
+
158
+ # Writable data dirs for on-disk SQLite stores (catalog index / observations
159
+ # mirror), owned by the runtime user. Mount a volume over either in production.
160
+ RUN mkdir -p /usr/src/app/.cache /usr/src/app/.mirror \
161
+ && chown -R bun:bun /usr/src/app/.cache /usr/src/app/.mirror
162
+
163
+ # Switch to the non-root user
164
+ USER bun
165
+
166
+ # Define an argument for the port, allowing it to be overridden at build time.
167
+ # The `PORT` variable is often injected by cloud environments at runtime.
168
+ ARG PORT
169
+
170
+ # Set runtime environment variables
171
+ # Note: PORT is an automatic variable in many cloud environments (e.g., Cloud Run)
172
+ ENV MCP_HTTP_PORT=${PORT:-3010}
173
+ ENV MCP_HTTP_HOST="0.0.0.0"
174
+ ENV MCP_TRANSPORT_TYPE="http"
175
+ ENV MCP_SESSION_MODE="stateless"
176
+ ENV MCP_LOG_LEVEL="info"
177
+ ENV LOGS_DIR="/var/log/interpro-mcp-server"
178
+
179
+ # Expose the port the server listens on
180
+ EXPOSE ${MCP_HTTP_PORT}
181
+
182
+ # Health check using a bun-native fetch (slim image ships no curl/wget)
183
+ HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 CMD bun -e "fetch('http://localhost:'+(process.env.MCP_HTTP_PORT??'3010')+'/healthz').then((r)=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"
184
+
185
+ # The command to start the server
186
+ CMD ["bun", "run", "dist/index.js"]