# Developer Protocol

**Server:** astronomy-mcp-server
**Version:** 0.5.0
**Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.18`
**Engines:** Bun ≥1.4.0, Node ≥24.0.0
**MCP SDK:** `@modelcontextprotocol/server` ^2.4.0
**Zod:** ^4.6.7

> **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.

---

## Server Surface

Observational astronomy, computed in-process. The core is keyless and offline — `astronomy-engine` plus a bundled bright-star catalog, no upstream, no `ctx.state`, deterministic for `(body, time, observer)`. The server does **not** geocode: callers resolve a place name to latitude/longitude (e.g. via openstreetmap) and a timezone (e.g. via reference-data) upstream, then pass coordinates and an optional IANA `timezone` for observer-local output.

**Five core tools** (always registered):

| Tool | What it computes |
|:-----|:-----------------|
| `astronomy_get_sky_position` | Apparent topocentric position of one body or named star — equatorial / horizontal / ecliptic, magnitude, angular diameter, phase, Sun elongation, constellation |
| `astronomy_get_rise_set` | Rise / set / transit cycles (31 per call), plus twilight bands for the Sun and `night_in_progress` when the start falls at night; circumpolar / never-rises notes |
| `astronomy_get_moon_phase` | Phase longitude, illumination, synodic age, next four quarter phases |
| `astronomy_find_events` | Next N (20 per call) of: equinox, solstice, moon_quarter, lunar/solar eclipse, opposition, conjunction (with the Sun, or two bodies via `body2`), max_elongation, perigee_apogee |
| `astronomy_list_visible` | One-call "what is up now" — naked-eye bodies (+ optional catalog stars) above the horizon, ranked, with a sky-condition gate |

Plus the `astronomy://body/{body}` resource (static reference card) and the `astronomy_stargazing_plan` prompt (chains the tools for a "plan tonight from <place>" workflow). One published skill, `skills/astronomy-guide/SKILL.md`, carries the cross-tool workflows and gates the tool descriptions can't (local-night anchoring, listed ≠ visible, Moon interference, eclipses from a place, the extension gates); `createApp({ skills: 'skills' })` serves it over MCP. A behavior change that falsifies one of its claims updates the skill in the same commit.

**Two gated, network-backed extensions** register only when their env gate is on (default deployment is keyless + offline):

- `astronomy_get_ephemeris` — small-body / spacecraft ephemeris from JPL Horizons, one page of up to 200 rows per call. Gate: `ASTRONOMY_ENABLE_HORIZONS`.
- `astronomy_get_satellite_passes` — visible passes (kept by their sunlit, dark-sky stretch, returned as `visible_*`) via a CelesTrak TLE propagated with SGP4 offline, 10 days per call. Gate: `ASTRONOMY_ENABLE_SATELLITES`.

Both extension services carry their own timeout + retry boundary, cache nothing on disk (Horizons is stateless; the satellite TLE cache is an in-process TTL `Map`), and degrade loudly — on any upstream failure they catch the framework's status-mapped `McpError` and re-throw a clean typed domain error (`{ reason, recovery }`, no `statusCode` / `responseBody` / `requestId` / internal URL), carrying the original as `cause` for server-side logs only. They never substitute core output.

**Config** (`src/config/server-config.ts`) is entirely optional — the core needs none. Every variable gates or tunes the two extensions (`ASTRONOMY_ENABLE_*`, `ASTRONOMY_*_BASE_URL`, `ASTRONOMY_DEFAULT_TIMEZONE`, `ASTRONOMY_REQUEST_TIMEOUT_MS`, `ASTRONOMY_TLE_CACHE_TTL_MS`).

---

## Core Rules

- **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.
- **Use `ctx.log`** for request-scoped logging. No `console` calls.
- **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
- **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. No handler here does — every tool is a pure computation over its arguments, which is why the server runs stateless.
- **Secrets in env vars only** — never hardcoded.
- **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.
- **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.

---

## Patterns

### Tool

```ts
import { tool, z } from '@cyanheads/mcp-ts-core';
import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
import { getEphemerisService } from '@/services/ephemeris/ephemeris-service.js';

export const getMoonPhaseTool = tool('astronomy_get_moon_phase', {
  title: 'astronomy-mcp-server: get moon phase',
  description:
    'Report the Moon phase for an instant: illuminated fraction, phase name, synodic age, phase longitude, and the next four quarter phases.',
  annotations: { readOnlyHint: true, openWorldHint: false, idempotentHint: true },
  input: z.object({
    time: z.string().optional().describe('Instant to evaluate as an ISO 8601 UTC string. Defaults to now.'),
    timezone: z.string().optional().describe('IANA timezone for localized output. UTC-only when omitted.'),
  }),
  output: MoonPhaseOutput,
  errors: [
    { reason: 'time_out_of_range', code: JsonRpcErrorCode.InvalidParams,
      when: "The instant is outside the engine's high-accuracy span (≈1900–2100).",
      recovery: 'Use a date between 1900 and 2100 and retry.' },
  ],

  // Core handler is synchronous — astronomy-engine computes in-process, no upstream.
  handler(input, ctx) {
    const svc = getEphemerisService();
    const phase = svc.moonPhase(svc.resolveTime(input.time), svc.resolveTimezone(input.timezone));
    ctx.log.info('Computed moon phase', { phaseName: phase.phaseName });
    return toMoonPhaseOutput(phase);
  },

  // format() populates content[] — the markdown twin of structuredContent.
  // Different clients read different surfaces (Claude Code → structuredContent,
  // Claude Desktop → content[]); both must carry the same data.
  // Enforced at lint time: every field in `output` must appear in the rendered text.
  format: (r) => [{ type: 'text', text: `## Moon — ${r.phase_name}\n**Illuminated:** ${(r.illuminated_fraction * 100).toFixed(1)}%` }],
});
```

`tool()` stores `input` with `.strict()` applied, so an argument key the schema does not declare is rejected by name before the handler runs rather than stripped. Root level only — a nested `z.object()` still strips unless it is strict itself — and an input that already declares a catchall is left alone. `astronomy_get_satellite_passes` uses that carve-out: it calls `.strict()` itself so its `.meta({ oneOf })` exclusivity survives onto the advertised `inputSchema`, which a framework-applied `.strict()` would drop when it rebuilds the schema.

`error` is a reserved name on `output` and `enrichment` — that key is the wire's failure envelope, and `tool()` throws at definition time on a collision.

### Resource

```ts
import { resource, z } from '@cyanheads/mcp-ts-core';
import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
import { BODY_META } from '@/services/ephemeris/body-data.js';
import { BODY_NAMES, type BodyName } from '@/services/ephemeris/types.js';

export const bodyResource = resource('astronomy://body/{body}', {
  name: 'astronomy-body-reference',
  title: 'astronomy-mcp-server: body reference card',
  description: 'Static reference card for a solar-system body: name, type, mean radius (km), and naked-eye visibility.',
  mimeType: 'application/json',
  cacheHint: { ttlMs: 86_400_000, cacheScope: 'public' }, // static table — see Caching below
  params: z.object({ body: z.string().describe('One of sun, moon, mercury … pluto.') }),
  output: BodyCardOutput,
  errors: [
    { reason: 'unknown_body', code: JsonRpcErrorCode.NotFound,
      when: 'The {body} segment is not a supported body.',
      recovery: 'Use one of: sun, moon, mercury … pluto.' },
  ],
  handler(params, ctx) {
    const key = params.body.trim().toLowerCase();
    if (!(BODY_NAMES as readonly string[]).includes(key)) {
      throw ctx.fail('unknown_body', `Unknown body "${params.body}".`);
    }
    const meta = BODY_META[key as BodyName];
    return { body: key, name: meta.name, type: meta.type, mean_radius_km: meta.meanRadiusKm, naked_eye: meta.nakedEye };
  },

  list: () => ({ resources: BODY_NAMES.map((b) => ({ uri: `astronomy://body/${b}`, name: BODY_META[b].name })) }),
});
```

### Prompt

```ts
import { prompt, z } from '@cyanheads/mcp-ts-core';

export const stargazingPlanPrompt = prompt('astronomy_stargazing_plan', {
  title: 'astronomy-mcp-server: plan stargazing session',
  description:
    'Structure a "plan tonight\'s stargazing from <place>" workflow, chaining the astronomy tools and naming the cross-server geocoding and weather steps.',
  args: z.object({
    location: z.string().describe('The place to stargaze from, e.g. "Mount Rainier".'),
    date: z.string().optional().describe('Target date (YYYY-MM-DD). Defaults to tonight.'),
  }),
  generate: (args) => {
    const when = args.date ? ` on ${args.date}` : ' tonight';
    return [{ role: 'user', content: { type: 'text', text: `Plan a stargazing session from ${args.location}${when}: resolve coordinates upstream, find the dark-sky window with astronomy_get_rise_set on the sun, check astronomy_get_moon_phase, then astronomy_list_visible just after astronomical dusk.` } }];
  },
});
```

### Server config

```ts
// src/config/server-config.ts — lazy-parsed, separate from framework config
import { z } from '@cyanheads/mcp-ts-core';
import { parseEnvConfig } from '@cyanheads/mcp-ts-core/config';

const ServerConfigSchema = z.object({
  enableHorizons: z.stringbool().default(false),
  enableSatellites: z.stringbool().default(false),
  horizonsBaseUrl: z.string().default('https://ssd.jpl.nasa.gov/api/horizons.api'),
  celestrakBaseUrl: z.string().default('https://celestrak.org/NORAD/elements/gp.php'),
  defaultTimezone: z.string().optional(),
  requestTimeoutMs: z.coerce.number().default(15000),
  tleCacheTtlMs: z.coerce.number().default(7200000),
});

let _config: z.infer<typeof ServerConfigSchema> | undefined;
export function getServerConfig() {
  _config ??= parseEnvConfig(ServerConfigSchema, {
    enableHorizons: 'ASTRONOMY_ENABLE_HORIZONS',
    enableSatellites: 'ASTRONOMY_ENABLE_SATELLITES',
    horizonsBaseUrl: 'ASTRONOMY_HORIZONS_BASE_URL',
    celestrakBaseUrl: 'ASTRONOMY_CELESTRAK_BASE_URL',
    defaultTimezone: 'ASTRONOMY_DEFAULT_TIMEZONE',
    requestTimeoutMs: 'ASTRONOMY_REQUEST_TIMEOUT_MS',
    tleCacheTtlMs: 'ASTRONOMY_TLE_CACHE_TTL_MS',
  });
  return _config;
}
```

`parseEnvConfig` maps Zod schema paths → env var names so errors name the variable (`ASTRONOMY_REQUEST_TIMEOUT_MS`) not the path (`requestTimeoutMs`). Throws `ConfigurationError`, which the framework prints as a clean startup banner.

For env booleans use `z.stringbool()`, never `z.coerce.boolean()` — `Boolean("false")` is `true`, so a coerced flag can't be disabled through the environment. `z.stringbool()` parses `true/false/1/0/yes/no/on/off` and rejects anything else, so `=false` actually disables.

### Server identity and instructions

`createApp()` accepts optional identity fields forwarded to the SDK's `initialize` response and the server manifest (`/.well-known/mcp.json`):

```ts
await createApp({
  name: 'my-mcp-server',
  title: 'My Server',                         // human-readable display name
  websiteUrl: 'https://github.com/owner/repo', // canonical homepage URL
  description: 'One-line description.',        // wins over MCP_SERVER_DESCRIPTION
  icons: [{ src: 'https://example.com/icon.png', sizes: ['48x48'], mimeType: 'image/png' }],
  instructions: 'Use shortcut alpha for the most common case.', // session-level context
});
```

`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.

### Caching

Nothing this server advertises varies by caller, so `createApp({ cacheHints })` declares the list operations (`tools/list`, `prompts/list`, `resources/list`, `resources/templates/list`, `server/discover`) cacheable for an hour with `cacheScope: 'public'`. They are all decided once at startup — the tool array by the two extension gates, the rest by literals — and an hour bounds how long a client can hold a catalog from a build whose gates have since changed. `resources/read` is deliberately left off that map: `bodyResource` carries its own 24-hour `cacheHint`, and a server-wide default would silently extend that policy to whichever resource is added next. Hints exist only on protocol revision 2026-07-28; a 2025-era response is unchanged either way.

### Session mode

`stateless`, declared in `src/index.ts` via `createApp({ sessionMode: 'stateless' })`, set in the `Dockerfile`, and set actively in `.env.example`. The `src/` declaration is the durable form — the posture travels with the source rather than with whatever a deployment happens to export — and `MCP_SESSION_MODE` still wins when it carries a meaningful value, which is how an operator overrides it. The mode a stateless server gives up is the 2025-era multi-round-trip shim, and no handler here calls `ctx.requestInput` — every tool is a pure function of its arguments — so there is nothing to give up. That absent call site is also why `require: 'stateful'` is not declared: there is no capability worth failing startup over. stdio and 2026-07-28 clients behave identically under either mode, so a green field test says nothing about this choice; the absent call site is the reason.

No service allocates a watcher, socket, or ref'd timer — the satellite TLE cache is a plain `Map` whose entries expire on read — so `createApp({ teardown })` is deliberately not declared. Add it the moment a service grows a handle that outlives a request.

---

## Context

Handlers receive a unified `ctx` object. Key properties:

| Property | Description |
|:---------|:------------|
| `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. |
| `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). |
| `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. |
| `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). |
| `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. |
| `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). |
| `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`. |
| `ctx.signal` | `AbortSignal` for cancellation. |
| `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
| `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |

---

## Errors

Handlers throw — the framework catches, classifies, and formats.

**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.

Most of this server's declared reasons are raised below the handler — `EphemerisService.resolveTime()` / `resolveTimezone()` / `lookupStar()`, `resolveBody()` / `resolvePair()`, and the two extension services — and carry their hint inline because those call sites take no `ctx` — except `resolveTime()`'s `time_out_of_range`, which carries none, so each calling tool's declared `recovery` fills it (the `start` tools say "start date", and `get_satellite_passes` names the element set's epoch). Those entries are marked `thrownBy: 'service'`; the handler-local preconditions (`find_events`'s `incomplete_observer` and `body_required`, `invalid_target`, the `get_ephemeris` argument gates, `unknown_body`) are the ones that throw through `ctx.fail`. A contract entry whose hint is written at a service throw site must repeat that string verbatim, since nothing links the two — `tests/tools/error-contract-coverage.test.ts` holds both halves of that line.

```ts
import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';

errors: [
  { reason: 'no_match', code: JsonRpcErrorCode.NotFound,
    when: 'No item matched the query',
    recovery: 'Broaden the query or check the spelling and try again.' },
],
async handler(input, ctx) {
  const item = await db.find(input.id);
  if (!item) throw ctx.fail('no_match', `No item ${input.id}`);
  return item;
}
```

**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.

**Fallback (no contract entry fits):** throw via factories or plain `Error`.

```ts
// Error factories — explicit code
import { notFound, serviceUnavailable } from '@cyanheads/mcp-ts-core/errors';
throw notFound('Item not found', { itemId });
throw serviceUnavailable('API unavailable', { url }, { cause: err });

// Plain Error — framework auto-classifies from message patterns
throw new Error('Item not found');           // → NotFound
throw new Error('Invalid query format');     // → ValidationError

// McpError — when no factory exists for the code
import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
```

See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.

---

## Structure

```text
src/
  index.ts                              # createApp() entry point
  config/
    server-config.ts                    # Server-specific env vars (Zod schema)
  services/
    [domain]/
      [domain]-service.ts               # Domain service (init/accessor pattern)
      types.ts                          # Domain types
  mcp-server/
    tools/definitions/
      [tool-name].tool.ts               # Tool definitions
    resources/definitions/
      [resource-name].resource.ts       # Resource definitions
    prompts/definitions/
      [prompt-name].prompt.ts           # Prompt definitions
```

---

## Naming

| What | Convention | Example |
|:-----|:-----------|:--------|
| Files | kebab-case with suffix | `search-docs.tool.ts` |
| Tool/resource/prompt names | snake_case | `search_docs` |
| Directories | kebab-case | `src/services/doc-search/` |
| Descriptions | Single string or template literal, no `+` concatenation | `'Search items by query and filter.'` |

---

## Skills

Two skill trees live at the project root, written for different readers:

| Tree | For | Written by |
|:-----|:----|:-----------|
| `framework-skills/` | The agent developing this server — framework skills (`metadata.audience: external`) plus any development-time skills of the server's own | `init` and the `maintenance` sync (framework skills); you (your own) |
| `skills/` | The agents that install the server and call its tools — tool chains, identifier sources, gates | You, deliberately, with the `add-skill` skill. Absent by default; usually none is needed |

Development skills are modular instructions. 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. Their 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/` — this one ships both — would hand them to every agent that installs it.

A published skill in root `skills/` reaches plugin installs and the `.mcpb` bundle as-is, ships in the npm package and the Docker image, and reaches MCP clients when the server opts in with `createApp({ skills: 'skills' })`. `lint:packaging` validates the tree.

**Agent skill directory:** Copy `framework-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.

Available skills:

| Skill | Purpose |
|:------|:--------|
| `setup` | Post-init project orientation |
| `design-mcp-server` | Design tool surface, resources, and services for a new server |
| `add-tool` | Scaffold a new tool definition |
| `add-app-tool` | Scaffold an MCP App tool + paired UI resource |
| `add-resource` | Scaffold a new resource definition |
| `add-prompt` | Scaffold a new prompt definition |
| `add-skill` | Author a skill the server publishes in root `skills/` for the agents that use it — when one earns its place, structure, validation, delivery |
| `add-service` | Scaffold a new service integration |
| `add-test` | Scaffold test file for a tool, resource, or service |
| `field-test` | Exercise tools/resources/prompts with real inputs, verify behavior, report issues |
| `tool-defs-analysis` | Read-only audit of MCP definition language across the surface — voice, leaks, defaults, recovery hints, output descriptions |
| `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
| `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
| `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
| `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 |
| `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 |
| `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
| `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
| `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
| `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
| `report-issue-local` | File a bug or feature request against this server's own repo via `gh` CLI |
| `techniques` | Catalog of response/data-shaping techniques — overflow handling, payload shaping, retrieval patterns |
| `api-auth` | Auth modes, scopes, JWT/OAuth |
| `api-canvas` | DataCanvas: register tabular data, run SQL, export, plus the `spillover()` helper for big result sets — Tier 3 opt-in |
| `api-config` | AppConfig, parseConfig, env vars |
| `api-context` | Context interface, RequestContext, logger, state, multi-round-trip input |
| `api-errors` | McpError, JsonRpcErrorCode, error patterns |
| `api-linter` | Definition linter rule catalog — invoked by `bun run lint:mcp` and `devcheck` |
| `api-mirror` | MirrorService: persistent self-refreshing local mirror (embedded SQLite + FTS5) of a bulk upstream dataset — Tier 3 opt-in |
| `api-services` | LLM, Speech, Graph services |
| `api-testing` | createMockContext, test patterns |
| `api-utils` | Formatting, parsing, security, pagination, scheduling, telemetry helpers |
| `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
| `api-workers` | Cloudflare Workers runtime |

**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.

When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).

---

## Commands

**Runtime:** Scripts use Bun's native TypeScript execution — `bun run <cmd>` is the standard invocation. `npm run <cmd>` also works (npm delegates to bun).

| Command | Purpose |
|:--------|:--------|
| `bun run build` | Compile TypeScript |
| `bun run rebuild` | Clean + build |
| `bun run clean` | Remove build artifacts |
| `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
| `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` |
| `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` |
| `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
| `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity, `.mcpbignore` coverage, plugin manifests, the published `skills/` tree (run by devcheck) |
| `bun run list-skills` | Print the skill registry |
| `bun run tree` | Generate directory structure doc |
| `bun run format` | Auto-fix formatting (safe fixes only) |
| `bun run format:unsafe` | Also apply Biome's unsafe autofixes — review the diff; they can change behavior |
| `bun run test` | Run tests (Vitest — use `bun run test`, not `bun test`) |
| `bun run start:stdio` | Production mode (stdio) |
| `bun run start:http` | Production mode (HTTP) |
| `bun run changelog:build` | Regenerate `CHANGELOG.md` from `changelog/*.md` |
| `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
| `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |

---

**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.

## Bundling

`bun run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. `mcpb pack` reads `.mcpbignore`, not `.gitignore`, so every root path the bundle must not ship — source, tests, docs, caches, logs, agent docs, plugin manifests, gitignored local files such as `/CITATION.cff` and `/.tsbuildinfo` — needs a root-anchored line there (`/docs/`, never `docs/`, which also strips `node_modules/*/docs/`); `lint:packaging` names each missing or unanchored line. Root `skills/` ships on purpose. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips four classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`), the directory trees matched only at a package root because the MCP SDK loads its own `dist/ext/skills/` at startup ([cyanheads/mcp-ts-core#794](https://github.com/cyanheads/mcp-ts-core/issues/794)); platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on; node-gyp build output beside a `binding.gyp`, which records the packing machine's paths; and build-only package files — the framework's `changelog/`, `scripts/`, `templates/`, `CLAUDE.md`, `AGENTS.md`, and config bases. `tests/scripts/packaging-regexes.test.ts` pins the cleaner's and the linter's matchers against each other. 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.

**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": ""`.

**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`.

---

## Changelog

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.

Each per-version file opens with YAML frontmatter:

```markdown
---
summary: "One-line headline, ≤350 chars"  # required — powers the rollup index
breaking: false                            # optional — true flags breaking changes
security: false                            # optional — true ONLY for a source-code security fix, never a dependency CVE bump
---

# 0.1.0 — YYYY-MM-DD
...
```

`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`.

`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.

**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.

**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.

---

## Publishing

**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 release digest: theme line, `## Changes`, `## Gates`, changelog link last); `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.

---

## Imports

```ts
// Framework — z is re-exported, no separate zod import needed
import { tool, z } from '@cyanheads/mcp-ts-core';
import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';

// Server's own code — via path alias
import { getMyService } from '@/services/my-domain/my-service.js';
```

---

## Checklist

- [ ] 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()`)
- [ ] 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`.
- [ ] JSDoc `@fileoverview` + `@module` on every file
- [ ] `ctx.log` for logging, `ctx.state` for storage
- [ ] Handlers throw on failure — error factories or plain `Error`, no try/catch
- [ ] `format()` renders all data the LLM needs — different clients forward different surfaces (Claude Code → `structuredContent`, Claude Desktop → `content[]`); both must carry the same data
- [ ] If wrapping external API: raw/domain/output schemas reviewed against real upstream sparsity/nullability before finalizing required vs optional fields
- [ ] If wrapping external API: normalization and `format()` preserve uncertainty; do not fabricate facts from missing upstream data
- [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
- [ ] Registered in `createApp()` arrays (directly or via barrel exports)
- [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
- [ ] `plugin.json` + `mcp.json` (Agent Plugins 1.0.0 — read by Codex, Cursor, GitHub Copilot, VS Code, Kiro) populated — `plugin.json` `name` = the unscoped repo name (lowercase `a-z`, `0-9`, `-`, `.` only); `version`, `description`, `author`, `homepage`, `repository`, `license`, `keywords` from `package.json`; no other top-level field, `extensions` included. `mcp.json` holds one `"type": "stdio"` entry keyed by the unscoped name, `npx -y <full package name>`, and the same fixed `env` as `.codex-plugin/mcp.json`. Neither file carries a user-supplied variable (no `""`, no `${…}` besides `${PLUGIN_ROOT}`/`${PLUGIN_DATA}`): keys reach Codex through `.codex-plugin/mcp.json` `env_vars`, which works only while `.codex-plugin/plugin.json` keeps `"mcpServers": "./.codex-plugin/mcp.json"`
- [ ] `.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
- [ ] `.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
- [ ] `.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`
- [ ] Any new root dev path has a root-anchored line in `.mcpbignore`; `bun run bundle` and `lint:packaging` pass
- [ ] If the server publishes a skill in root `skills/`: `lint:packaging` passes, and `field-test` verified every gate and identifier claim in it against live tool behavior
- [ ] `npm run devcheck` passes