@cyanheads/mcp-ts-core 0.9.7 → 0.9.9

package/skills/multi-server-orchestration/references/release-and-publish-pass.md

@@ -70,7 +70,7 @@ One sub-agent per target. Quick verification gate before any version bump or wra
 
 > Run `bun run devcheck`. Then run `bun run test:all` if it exists in `package.json` scripts, otherwise `bun run test`. Both must pass green. Halt and report the failing step's verbatim output if anything fails — do not attempt fixes from inside this phase. If neither `test:all` nor `test` exists in `package.json` scripts, note it and continue — devcheck-only is acceptable (though uncommon for a project shipping a release).
 
-Any red target halts the orchestration. The user fixes locally and re-invokes from Phase 2.
+Any red target halts the orchestration for that target. The user fixes locally and re-invokes Phase 2 for the failing target(s) only — other targets that passed don't need to re-run.
 
 ### Phase 3: README review fanout
 
@@ -80,7 +80,7 @@ One sub-agent per target reads the full README plus key adjacent docs, identifie
 
 > Read `README.md` from front to back. Identify content stale relative to the current code: tool/resource counts, version badges, feature lists, configuration tables, version mentions in install snippets. Fold updates in naturally — don't rewrite sections that are already accurate. Do NOT commit. Leave changes in the working tree for the next phase.
 >
-> If `polish-docs-meta` skill is available and the change spans more than just the README (e.g., new env vars, new tools), invoke that skill instead — it handles README plus `server.json`, `package.json`, agent protocol, and `.env.example` in one pass.
+> If `polish-docs-meta` skill is available (`skills/polish-docs-meta/SKILL.md`) and the change spans more than just the README (e.g., new env vars, new tools), invoke that skill instead — it handles README plus `server.json`, `package.json`, agent protocol, and `.env.example` in one pass.
 >
 > If the README is already accurate, report "no changes needed" and exit cleanly.
 
@@ -88,32 +88,20 @@ For a small patch bump, this phase is often a no-op. That's fine.
 
 ### Phase 4: Wrap-up fanout (Bash git only)
 
-Run only after user authorizes commits.
+Runs on the authorization captured in Pre-flight Step 5 — no separate authorization needed for wrap-up.
 
-One sub-agent per target. The agent executes the wrapup steps via Bash git — the same workflow `git_wrapup_instructions` walks through, but per-target absolute paths instead of session state.
+One sub-agent per target. The agent reads and executes the standalone `git-wrapup` skill (`skills/git-wrapup/SKILL.md`) — the skill contains the complete protocol for version bump, changelog, verification, commit, and annotated tag.
 
 **Task body:**
 
-> Run the version-bump wrapup via Bash `git` (no `git-mcp-server` tools — see the orchestration skill's Hard Rule 1).
+> Read and follow the `git-wrapup` skill — check `skills/git-wrapup/SKILL.md` first; fall back to `.claude/skills/git-wrapup/SKILL.md` if not found. Apply a `[patch/minor/major]` version bump.
 >
-> 1. **Inspect state:** `git status`, `git log --oneline -5`, `git diff --stat` on the working tree.
-> 2. **Determine the new version:** start from the current `package.json` `version`, apply the bump intent (`[patch/minor/major or explicit string]`). For a patch, e.g., `0.1.1 → 0.1.2`.
-> 3. **Author the changelog:** create `changelog/<major.minor>.x/<version>.md` per the directory-based convention. YAML frontmatter (`summary:` required, ≤350 chars, no markdown; `breaking:` and `security:` optional, default false). Grouped sections: Added / Changed / Fixed / Removed. Use the format reference at `changelog/template.md` — never edit, rename, or move that file.
-> 4. **Regenerate:** `bun run changelog:build` (rebuilds `CHANGELOG.md` rollup) and `bun run tree` (regenerates `docs/tree.md`).
-> 5. **Bump every version-bearing file:** `package.json` `version`, `server.json` `version` at the top level AND every `packages[].version` entry, any README badge that references the version. Use `grep -rn "<current-version>"` to find any you missed; resolve case by case.
-> 6. **Stage and commit.** Conventional Commits subject. Per the global protocol: version bumps ride with the change that warrants them — for a focused patch this is one commit. Subject style: `feat: <version> — <one-line theme>` or `chore(release): v<version> — <theme>`. Plain `-m` only, no heredoc, no `Co-authored-by` or `Generated with` trailers.
-> 7. **Annotated tag** `v<version>` (`-a`, NOT lightweight): terse message with release theme, notable changes, and dep arrows in `pkg ^old → ^new` form if applicable. Not a CHANGELOG copy.
+> Additional constraints for orchestrated runs:
+> - **Bash `git` only.** Do not use `git-mcp-server` (`mcp__git-mcp-server__*`) tools — session state leaks across parallel agents in the same orchestrator session.
+> - **Do NOT push.** Phase 5 handles the push as part of `release-and-publish`.
+> - If `v<version>` already exists as a tag, **halt and surface the conflict** to the orchestrator. Do NOT `git tag -d` without authorization.
 >
-> **Do NOT push.** Phase 5 handles the push as part of `release-and-publish`'s verification gate flow.
->
-> **Verify state at the end:**
-> ```bash
-> git log --oneline -1
-> git show v<version> --stat | head -20
-> git status   # should be clean
-> ```
->
-> Constraints: Bash git only. NEVER `git stash`. NEVER `reset --hard` / `restore .` / `clean -f` / `checkout -- .`. No marketing adjectives ("comprehensive", "robust", "enhanced", "seamless", "improved") in commit or tag messages. Be concise and accurate.
+> Output for the orchestrator: commit SHA, tag name, tag annotation subject.
 
 After this fanout, each target has a clean working tree with the wrap-up commit + annotated tag locally; nothing has been pushed.
 
@@ -132,7 +120,7 @@ Each target invokes the `release-and-publish` skill end-to-end. Execution mode d
 
 > Read `skills/release-and-publish/SKILL.md` (or `.claude/skills/release-and-publish/SKILL.md`). Run it end-to-end:
 >
-> 1. Sanity-check wrapup outputs (working tree clean, HEAD tagged `v<version>` from Phase 4)
+> 1. Sanity-check wrapup outputs (working tree clean, HEAD tagged `v<version>` from Phase 4). If either check fails, halt and report to the orchestrator — do not re-run Phase 4 from inside Phase 5
 > 2. Verification gate: `bun run devcheck`, `bun run rebuild`, `bun run test:all` (or `test`)
 > 3. Push commits and tags to origin via Bash git
 > 4. `bun publish --access public` (npm — uses the configured bypass token)
@@ -143,7 +131,7 @@ Each target invokes the `release-and-publish` skill end-to-end. Execution mode d
 >
 > Honor the skill's retry/halt protocol — transient network errors retry up to 2× with backoff; idempotent-success signals ("version already exists", "cannot publish duplicate version") are treated as success and proceed. Bash git for all git ops. Never skip the verification gate.
 
-**Serial mode:** the orchestrator runs `release-and-publish` against each target sequentially in its own session, handling OTP prompts interactively as they appear.
+**Serial mode:** the orchestrator spawns one sub-agent at a time per target — each runs `release-and-publish` end-to-end, completing before the next target starts. This prevents OTP prompt interleaving.
 
 After Phase 5, collect per-target status: which destinations succeeded, which (if any) halted with partial state. The user re-invokes Phase 5 for any failed targets only — completed destinations hit the idempotent-success signal and skip naturally.
 
@@ -178,7 +166,7 @@ Skip Phase 6 for any target whose Phase 5 didn't complete — there's nothing to
 | 9 | Sub-agent uses `git-mcp-server` instead of Bash git in Phase 4 or 5 | Hard Rule 1 restated explicitly in every fanout prompt that touches git |
 | 10 | Failed publish leaves a tag pushed but no npm package — looks shipped, isn't | Collect per-destination status per target in Phase 5 roll-up; surface partial-state targets explicitly to the user before Phase 6 |
 | 11 | `gh release create --notes-from-tag` fails with `--repo` flag | `gh` CLI limitation. Always `cd` into the target repo dir for `gh release` commands instead of using `--repo` |
-| 12 | Post-version doc changes (install badges, description fixes) land after the version commit — tag points at stale content | Move the tag forward: delete remote release, delete remote+local tag, recreate tag at new HEAD with same annotation, re-push, recreate release with `.mcpb`. This is authorized within the pipeline for same-day follow-ups |
+| 12 | Post-version doc changes (install badges, description fixes) land after the version commit — tag points at stale content | Move the tag forward: delete remote release, delete remote+local tag, recreate tag at new HEAD with same annotation, re-push, recreate release with `.mcpb`. This requires explicit user confirmation before executing — ask at runtime |
 | 13 | `mcpb pack` fails because `manifest.json` `user_config` entries are missing `title`/`type` fields | Verify `manifest.json` `user_config` entries during Phase 3 or a pre-Phase-5 check; the `polish-docs-meta` skill's cross-file consistency section covers this |
 
 ## Checklist
@@ -189,6 +177,7 @@ Skip Phase 6 for any target whose Phase 5 didn't complete — there's nothing to
 - [ ] Phase 3: README review fanout — updates folded, no commits
 - [ ] Phase 4: wrap-up fanout (Bash git only) — version bumped, changelog authored, rollup regenerated, commit + annotated tag per target — **NOT pushed**
 - [ ] Working tree clean per target; `git show v<version>` succeeds per target
+- [ ] Version-bearing files consistent across `package.json`, `server.json`, README badge, and `Dockerfile` OCI labels per target — no doc changes pending after the tag
 - [ ] Phase 5: release publish — completed per target via `release-and-publish` (parallel or serial based on 2FA mode); per-target status captured
 - [ ] All targets: deployed artifact URLs reported (npm / MCP Registry / GHCR as applicable)
 - [ ] **If GH issue map captured:** Phase 6: issue closure fanout — relevant issues commented and closed per target whose Phase 5 succeeded

package/skills/multi-server-orchestration/references/wrapup-pass.md

@@ -62,6 +62,8 @@ Phase 3 is optional — skip when the change is small enough that the README/doc
 
 ## Phase details
 
+> **Orient block:** the standard preamble instructing sub-agents to read `~/.claude/CLAUDE.md`, workspace `CLAUDE.md`, project `CLAUDE.md`, and run `bun run list-skills` — defined in `../SKILL.md`. Every sub-agent prompt starts with this block before the task body.
+
 ### Phase 2: Verification fanout
 
 One sub-agent per target. Quick verification gate before any version bump or wrap-up.
@@ -80,60 +82,27 @@ One sub-agent per target reads the README plus adjacent docs, identifies stale c
 
 > Read `README.md` from front to back. Identify content stale relative to the current code: tool/resource counts, version badges, feature lists, configuration tables, version mentions in install snippets. Fold updates in naturally — don't rewrite sections that are already accurate. Do NOT commit. Leave changes in the working tree for the next phase.
 >
-> If `polish-docs-meta` skill is available and the change spans more than just the README (e.g., new env vars, new tools), invoke that skill instead — it handles README plus `server.json`, `package.json`, agent protocol, and `.env.example` in one pass.
+> If `polish-docs-meta` skill is available (`skills/polish-docs-meta/SKILL.md`) and the change spans more than just the README (e.g., new env vars, new tools), invoke that skill instead — it handles README plus `server.json`, `package.json`, agent protocol, and `.env.example` in one pass.
 >
 > If the README is already accurate, report "no changes needed" and exit cleanly.
 
-For a small patch, this phase is often a no-op. That's fine — skip it entirely if pre-flight confirmed no user-facing change.
+For a small patch, this phase is often a no-op. Skip Phase 3 when the diff introduces no new tools, resources, env vars, or behavior changes visible to the user.
 
 ### Phase 4: Wrap-up fanout (Bash git only)
 
-Run only after user authorizes commits.
+Runs on the authorization captured in Pre-flight Step 4 — no separate authorization needed for wrap-up.
 
-One sub-agent per target. The agent executes the seven acceptance criteria via Bash `git` — no `git-mcp-server` (per the parent SKILL.md's Hard Rule 1, the MCP server's session state leaks across parallel agents).
+One sub-agent per target. The agent reads and executes the standalone `git-wrapup` skill (`skills/git-wrapup/SKILL.md`) — the skill contains the complete protocol for version bump, changelog, verification, commit, and annotated tag.
 
 **Task body:**
 
-> Execute the wrap-up protocol against this target. Acceptance criteria — strict on goals, generic on mechanism — but for `@cyanheads/mcp-ts-core` consumers, mechanism is concrete:
->
-> 1. **Diff reviewed.** `git status`, `git log v<latest-tag>..HEAD --oneline`, `git diff --stat`. Understand what's about to ship.
-> 2. **Version bump.** Start from current `package.json` `version`; apply the bump intent (`[patch/minor/major or explicit string]`). Bump every place version is declared:
->    - `package.json` `version`
->    - `server.json` `version` at the top level AND every `packages[].version` entry
->    - `manifest.json` (if present) `version`. Also verify `name` doesn't include the npm scope prefix — it should be the bare package name (e.g. `bls-mcp-server`, not `@cyanheads/bls-mcp-server`)
->    - README version badge and any hero pinning
->    - Dockerfile OCI labels (if pinned to version)
->    - Any agent-instruction file (`CLAUDE.md`, `AGENTS.md`) that pins the version
->    
->    Run `grep -rn "<current-version>" .` to catch stragglers; resolve case by case (some hits are historical changelog entries — leave those).
-> 3. **Changelog authored.** Create `changelog/<major.minor>.x/<version>.md` per the directory-based convention. YAML frontmatter (`summary:` required, ≤350 chars, no markdown; `breaking:` and `security:` optional, default false). Section order (Keep a Changelog): Added / Changed / Deprecated / Removed / Fixed / Security. Include only sections with entries. Use `changelog/template.md` as the format reference — never edit, rename, or move it.
-> 4. **Regenerate derived artifacts.** `bun run changelog:build` (rebuilds `CHANGELOG.md` rollup from per-version files); `bun run tree` (regenerates `docs/tree.md` if the file structure changed).
-> 5. **Verification gate.** `bun run devcheck` must pass against the tree being committed. `bun run test:all` if it exists, otherwise `bun run test`. Both green. Halt if not green — do NOT bypass.
-> 6. **Atomic Conventional Commits.** Version bumps ride with the change that warrants them. For a focused patch, this is ONE commit covering the work + the version bump + changelog + regenerated artifacts. Subject form: `feat: <version> — <one-line theme>` or `chore(release): v<version> — <theme>`. Plain `-m` only — no heredoc, no `Co-authored-by`, no `Generated with` trailers. No marketing adjectives.
-> 7. **Annotated tag** `v<version>` (`-a`, NOT lightweight). The tag body renders as the GitHub Release page via `--notes-from-tag` — it must be structured markdown, never a flat comma-separated string. Format:
->    - **Subject line:** release theme — omit version number (GitHub prepends `v<VERSION>:`)
->    - **Prose intro:** 1-2 sentences — what this release does, why it matters
->    - **Sections:** Keep a Changelog names (Dependency bumps / Added / Changed / Fixed / Removed) — only sections with entries, each with bulleted items
->    - **Dep arrows:** `pkg ^old → ^new` form, one per line
->    - **Footer:** test count + devcheck status
->    - **Backlinks:** link framework issues where relevant (`cyanheads/mcp-ts-core#50`)
->    - Not a CHANGELOG copy — terse, scannable. No marketing adjectives. Length is earned.
+> Read and follow the `git-wrapup` skill — check `skills/git-wrapup/SKILL.md` first; fall back to `.claude/skills/git-wrapup/SKILL.md` if not found. Apply a `[patch/minor/major]` version bump.
 >
-> Constraints:
+> Additional constraints for orchestrated runs:
 > - **Bash `git` only.** Do not use `git-mcp-server` (`mcp__git-mcp-server__*`) tools — session state leaks across parallel agents in the same orchestrator session.
-> - **Do NOT push.** Wrap-up is local only. Push is a separate authorized step (`release-and-publish-pass.md` Phase 5, or the standalone `release-and-publish` skill).
-> - NEVER `git stash`. NEVER `git reset --hard`, `git restore .`, `git clean -f`, or `git checkout -- .` — these violate the global protocol.
-> - No marketing adjectives ("comprehensive", "robust", "enhanced", "seamless", "improved") in commit or tag messages. State the change.
-> - If `v<version>` already exists as a tag, **halt and surface the conflict**. Do NOT `git tag -d` without orchestrator authorization.
+> - If `v<version>` already exists as a tag, **halt and surface the conflict** to the orchestrator. Do NOT `git tag -d` without authorization.
 >
-> **Verify state at the end:**
-> ```bash
-> git log --oneline -1
-> git show v<version> --stat | head -20
-> git status   # should be clean
-> ```
->
-> Output for the orchestrator: commit SHA, tag name, tag annotation subject. The orchestrator parses these for Phase 5.
+> Output for the orchestrator: commit SHA, tag name, tag annotation subject.
 
 ### Phase 5: Roll-up (orchestrator)
 
@@ -146,6 +115,8 @@ for d in <target paths>; do
 done
 ```
 
+Spot-check commit and tag quality: `git log --format='%s%n%b' -1` for marketing adjectives in commit messages, `git show v<version>` for tag annotation structure.
+
 Then produces a consolidated report:
 
 1. **Per-target headline** — target → new version → tag annotation subject → commit SHA
@@ -176,3 +147,4 @@ Then produces a consolidated report:
 - [ ] Tags exist locally; nothing pushed to remotes
 - [ ] Phase 5: orchestrator verification — `git log --oneline -1`, `git tag --points-at HEAD`, `git status --short` per target
 - [ ] Consolidated report presented to user with per-target headlines, outliers, next steps
+- [ ] Orchestrator has NOT advanced to push, publish, or any remote operation — wrap-up is complete

package/skills/polish-docs-meta/SKILL.md

@@ -72,7 +72,9 @@ Compare `.env.example` against the server config Zod schema. Add any missing ser
 
 Check for empty or placeholder metadata fields. Read `references/package-meta.md` for which fields matter and why. Fill in anything still missing — skip fields that are already correct.
 
-Key fields: `description`, `repository`, `author`, `homepage`, `bugs`, `keywords`.
+Key fields: `name`, `description`, `repository`, `author`, `homepage`, `bugs`, `keywords`.
+
+**`name` must communicate the server's domain at a glance.** See `references/package-meta.md` for the naming convention — ambiguous abbreviations and acronym-only names fail the scannability test for humans and agents alike.
 
 **`description` is the canonical source.** Every other surface (README header, `server.json`, Dockerfile OCI label, GitHub repo description) derives from it. Write it here first, then propagate.
 

package/skills/polish-docs-meta/references/package-meta.md

@@ -6,7 +6,7 @@ Fields that may still be empty or generic from scaffolding. Check each one and f
 
 | Field | Default / Scaffolded | What It Should Be |
 |:------|:---------------------|:------------------|
-| `name` | `{{PACKAGE_NAME}}` (substituted by init) | Verify it's correct. Use scoped name if publishing (`@org/my-server`). |
+| `name` | `{{PACKAGE_NAME}}` (substituted by init) | Verify it communicates the server's domain at a glance. A human or agent scanning a list should know what this server does from the name alone. Prefer full names over ambiguous abbreviations (`libofcongress` not `loc`, `federal-reserve` not `fred`). Non-obvious acronyms get a descriptive suffix (`eia-energy`, `bls-labor`). Use scoped name if publishing (`@org/my-server`). |
 | `version` | `0.1.0` | Keep for initial development. Bump via the `release-and-publish` skill. |
 | `mcpName` | _(often missing)_ | Reverse-domain identifier: `"io.github.{owner}/{repo}"`. Used in `server.json` `name` field and Dockerfile OCI labels. |
 | `description` | `""` (empty) | One **action-first** sentence — lead with the actions/workflows, end with `via MCP. STDIO or Streamable HTTP.` (or the transports that apply). Example: `"Search projects, manage tasks, track teams via MCP. STDIO or Streamable HTTP."` Avoid `"MCP server for/that …"` framings. Appears on npm and in `npm search`; the README header tagline and `server.json` `description` derive from this (server.json drops the `via MCP …` suffix). |

package/skills/release-and-publish/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Ship a release end-to-end across every registry the project targets (npm, MCP Registry, GitHub Releases for `.mcpb` bundles, GHCR). Runs the final verification gate, pushes commits and tags, then publishes to each applicable destination. Assumes git wrapup (version bumps, changelog, commit, annotated tag) is already complete — this skill is the post-wrapup publish workflow. Retries transient network failures on publish steps; halts with a partial-state report when retries are exhausted or the failure is terminal.
 metadata:
   author: cyanheads
-  version: "2.5"
+  version: "2.6"
   audience: external
   type: workflow
 ---
@@ -73,7 +73,7 @@ If working tree is dirty or HEAD isn't on `v<version>`, halt.
 
 ### 2. Run the verification gate
 
-All three must succeed. Use `test:all` if the script exists in `package.json`, otherwise fall back to `test`:
+All three must succeed. Check `package.json` `scripts` for `test:all`; if absent, fall back to `test`:
 
 ```bash
 bun run devcheck
@@ -85,7 +85,7 @@ Any non-zero exit → halt with the failing command's output.
 
 ### 3. Push to origin
 
-Use your git tools to push commits and tags to origin. If the remote rejects either push, halt.
+Use your git tools to push the branch commits first, then push tags to origin. If the remote rejects either push, halt.
 
 ### 4. Publish to npm
 
@@ -106,13 +106,13 @@ Halt on publish error other than "version already exists" (which means this step
 
 ### 5. Publish to MCP Registry
 
-Only if `server.json` exists at the repo root (otherwise skip).
+Only if `server.json` exists at the repo root (otherwise skip). Note: `server.json` (MCP Registry metadata) and `manifest.json` (MCPB bundle manifest, step 6) are independent — a project may have either, both, or neither.
 
 ```bash
 bun run publish-mcp
 ```
 
-If `publish-mcp` isn't defined in `package.json`, add it (macOS):
+If `publish-mcp` isn't defined in `package.json`, add it permanently (one-time setup, macOS):
 
 ```json
 "publish-mcp": "mcp-publisher login github -token \"$(security find-generic-password -a \"$USER\" -s mcp-publisher-github-pat -w)\" && mcp-publisher publish"
@@ -171,14 +171,14 @@ docker buildx build --platform linux/amd64,linux/arm64 \
   --push .
 ```
 
-If the project uses a non-GHCR registry or a custom image name, respect the project's convention. Halt on build or push failure.
+If the project uses a non-GHCR registry or a custom image name, respect the project's convention. If push fails with a 401/403, prompt the user to authenticate (`echo $GITHUB_TOKEN | docker login ghcr.io -u <OWNER> --password-stdin`) and retry. Halt on build failure or non-auth push failure.
 
 ### 8. Report the deployed artifacts
 
 Print clickable URLs for every destination that succeeded:
 
 - npm: `https://www.npmjs.com/package/<package.json#name>/v/<version>`
-- MCP Registry: `https://registry.modelcontextprotocol.io/v0/servers?search=<package.json#mcpName>`
+- MCP Registry: `https://registry.modelcontextprotocol.io/v0.1/servers/<mcpName>/versions/<version>` — `mcpName` is the `name` field from `server.json` (URL-encode the `/` as `%2F`)
 - GitHub Release: `https://github.com/<OWNER>/<REPO>/releases/tag/v<VERSION>` (with `.mcpb` asset attached)
 - GHCR: `ghcr.io/<OWNER>/<REPO>:<VERSION>`
 
@@ -189,7 +189,7 @@ Skip any destination that was skipped in its step.
 Confirm each published artifact is actually live — don't rely on a successful push exit code alone. For each destination that succeeded:
 
 - **npm**: `npm view <package.json#name>@<version> version` — must return the version string
-- **MCP Registry**: `curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=<mcpName>"` — response must include `<version>` for the `io.github.cyanheads/<repo>` entry
+- **MCP Registry**: `curl -s "https://registry.modelcontextprotocol.io/v0.1/servers/<mcpName>/versions/<version>"` — must return HTTP 200 with `server.version` matching `<version>` (`mcpName` is the `name` field from `server.json`; URL-encode `/` as `%2F`). The search endpoint (`/v0.1/servers?search=`) paginates and may not include the latest version for packages with many releases — always use the direct version lookup.
 - **GitHub Release**: `gh release view v<VERSION> -R <OWNER>/<REPO> --json assets --jq '.assets[].name'` — must list the `.mcpb` file
 - **GHCR**: fetch an anonymous bearer token, then `curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $TOKEN" "https://ghcr.io/v2/<OWNER>/<REPO>/manifests/<VERSION>"` — must return HTTP 200
 
@@ -197,7 +197,7 @@ If any check fails, halt and report which destination is unreachable. A successf
 
 ## Checklist
 
-- [ ] Working tree clean; HEAD tagged `v<version>`
+- [ ] Working tree clean; HEAD tagged `v<version>`; current branch name noted for push
 - [ ] `bun run devcheck` passes
 - [ ] `bun run rebuild` succeeds
 - [ ] `bun run test:all` (or `test`) passes
@@ -208,4 +208,5 @@ If any check fails, halt and report which destination is unreachable. A successf
 - [ ] `bun run bundle` + `gh release create --verify-tag --notes-from-tag` succeeds (if `manifest.json` present)
 - [ ] Docker buildx multi-arch push succeeds (if `Dockerfile` present)
 - [ ] All published artifacts verified reachable (npm, MCP Registry, GH Release asset, GHCR manifest)
+- [ ] On re-invocation: idempotent-success signals recognized for already-published destinations
 - [ ] Deployed artifact URLs reported to the user

package/skills/report-issue-framework/SKILL.md

@@ -180,12 +180,12 @@ Combine labels: `--label "bug" --label "regression"`.
 
 ### Attaching logs or stack traces
 
-For long output, write to a file and attach:
+For long output, write to a file and attach. Note: `--body-file` replaces the entire body — it does not supplement a `--body` flag. For structured bugs with logs, either embed the log content in the `Additional context` section of a normal `--body`, or file the issue first and add the log as a comment:
 
 ```bash
 bun run rebuild && bun run start:stdio 2>&1 | head -100 > /tmp/mcp-error.log
 
-# As part of a new issue
+# As part of a new issue (the log becomes the entire body — no template fields)
 gh issue create -R cyanheads/mcp-ts-core \
   --title "bug(transport): stdio crashes on large payload" \
   --label "bug" \
@@ -287,4 +287,6 @@ gh issue list -R cyanheads/mcp-ts-core --author @me
 - [ ] Running latest (or documented) framework version
 - [ ] Searched existing issues — no duplicate found
 - [ ] All secrets, credentials, and tokens redacted
-- [ ] Issue filed with: version, runtime, repro code, actual vs expected behavior
+- [ ] Primary label assigned (`bug` / `enhancement` / `documentation`)
+- [ ] If bug: version, runtime, repro code, actual vs expected behavior included
+- [ ] If feature: Proposal and Scope sections present; Out of scope defined

package/skills/report-issue-local/SKILL.md

@@ -32,7 +32,7 @@ For general `gh` CLI workflows outside issue filing (PRs, workflows, API access)
 gh repo view --json nameWithOwner -q '.nameWithOwner'
 ```
 
-2. **Search existing issues**:
+2. **Search existing issues** — if a close match exists (same symptom, different tool; same tool, different symptom; closed issue that might cover the new case), add a comment on that issue instead of filing a new one — unless the symptom or scope is distinct enough to warrant separate tracking:
 
 ```bash
 gh issue list --search "your error message or keyword"
@@ -176,17 +176,19 @@ gh label create surplus-token-idea --color FF10F0 --description "Worth exploring
 
 ### Attaching logs or large output
 
+Note: `--body-file` replaces the entire body — it does not supplement a `--body` flag. For structured bugs with logs, either embed the log content in the `Additional context` section of a normal `--body`, or file the issue first and add the log as a comment:
+
 ```bash
 bun run rebuild && bun run start:stdio 2>&1 | head -200 > /tmp/server-error.log
 
-# As part of a new issue
+# As part of a new issue (the log becomes the entire body — no template fields)
 gh issue create \
   --title "bug(ingest): crashes on large payload" \
   --label "bug" \
   --assignee "@me" \
   --body-file /tmp/server-error.log
 
-# Or as a comment on an existing issue
+# Or as a comment on an existing issue (preferred — keeps the structured body intact)
 gh issue comment <number> --body-file /tmp/server-error.log
 ```
 
@@ -294,6 +296,9 @@ gh issue close <number> --reason completed --comment "Fixed in <commit or PR>"
 ## Checklist
 
 - [ ] Confirmed bug is in server code, not the framework
-- [ ] Searched existing issues — no duplicate found
+- [ ] Searched existing issues — no duplicate found; close matches commented instead of duplicated
 - [ ] All secrets, credentials, and tokens redacted
-- [ ] Issue filed with: version, runtime, repro steps, actual vs expected behavior
+- [ ] Title follows `type(scope): description` format
+- [ ] Primary label assigned (`bug` / `enhancement` / `documentation`)
+- [ ] If bug: version, runtime, repro steps, actual vs expected behavior included
+- [ ] If feature: Proposal and Scope sections present; Out of scope defined

package/skills/setup/SKILL.md

@@ -17,8 +17,8 @@ This skill assumes `bunx @cyanheads/mcp-ts-core init [name]` has already run. Th
 
 The init CLI generates both `CLAUDE.md` and `AGENTS.md` with the same purpose. Keep one authoritative file for the agent you actually use:
 
-- **Claude Code** — keep `CLAUDE.md`, discard `AGENTS.md`
-- **All other agents** (Codex, Cursor, Windsurf, etc.) — keep `AGENTS.md`, discard `CLAUDE.md`
+- **Claude Code** — keep `CLAUDE.md`, delete `AGENTS.md`
+- **All other agents** (Codex, Cursor, Windsurf, etc.) — keep `AGENTS.md`, delete `CLAUDE.md`
 
 Both files serve the same purpose: project-specific agent instructions. Prefer committing one authoritative copy rather than trying to keep both in sync by hand.
 
@@ -94,7 +94,7 @@ After init:
 
 1. **Clean up what you don't need.** If your server has no prompts, delete the echo prompt and its registration in `src/index.ts`. Same for resources, or the app-tool pair if you're not targeting UI-capable clients.
 2. **Rename and replace what you keep.** The echo definitions and their tests show the pattern — swap them out for your real tools/resources/prompts.
-3. **Definitions register directly in `src/index.ts`.** No barrel files, just import and add to the `tools` / `resources` / `prompts` arrays.
+3. **Definitions register directly in `src/index.ts`.** The init scaffold uses direct imports — no barrel files yet. As the definition count grows, the `add-tool`/`add-resource`/`add-prompt` skills introduce `definitions/index.ts` barrels per the framework convention.
 
 See the `add-tool`, `add-app-tool`, `add-resource`, `add-prompt`, `add-service`, and `add-test` skills for the scaffolding patterns when you start adding real definitions.
 
@@ -126,11 +126,13 @@ This step is the **bootstrap** — it creates the agent directory. From then on,
 
 ## Project Scaffolding
 
-After `bun install`, complete these one-time setup tasks:
+Complete these one-time setup tasks:
 
-1. **Update dependencies to latest** — `bun update --latest`. The scaffolded `package.json` pins minimum versions from when the framework was published; updating ensures you start with the latest compatible releases.
-2. **Initialize git** — use your git tools: init the repo, stage all files, and commit with message `chore: scaffold from @cyanheads/mcp-ts-core`
-3. **Verify the substituted server name** — when `init` runs without a `[name]` argument, the package name defaults to the cwd directory name. If that's not what you want as the published server name, update `package.json`, `CLAUDE.md`/`AGENTS.md`, and `server.json` to your actual server name.
+1. **Install dependencies** — `bun install`
+2. **Update dependencies to latest** — `bun update --latest`. The scaffolded `package.json` pins minimum versions from when the framework was published; updating ensures you start with the latest compatible releases.
+3. **Initialize git** — use your git tools: init the repo, stage all files, and commit with message `chore: scaffold from @cyanheads/mcp-ts-core`
+4. **Verify the substituted server name** — when `init` runs without a `[name]` argument, the package name defaults to the cwd directory name. If that's not what you want as the published server name, update `package.json`, `CLAUDE.md`/`AGENTS.md`, and `server.json` to your actual server name.
+5. **Verify the scaffold builds clean** — `bun run devcheck`. Fix any issues before starting real work.
 
 ## Changelog Convention
 
@@ -153,7 +155,10 @@ Skip or reorder as the project calls for it. The agent protocol's "What's Next?"
 
 ## Checklist
 
-- [ ] Agent protocol file selected — keep one authoritative file (`CLAUDE.md` or `AGENTS.md`)
+- [ ] Agent protocol file selected — one authoritative file kept (`CLAUDE.md` or `AGENTS.md`), the other deleted
+- [ ] `bun install` run
+- [ ] Dependencies updated (`bun update --latest`)
+- [ ] Git repo initialized and initial commit made (`chore: scaffold from @cyanheads/mcp-ts-core`)
 - [ ] Substituted server name verified in `package.json`, agent protocol file, and `server.json`
 - [ ] Framework docs read (`node_modules/@cyanheads/mcp-ts-core/CLAUDE.md`)
 - [ ] Unused echo definitions cleaned up (and unregistered from `src/index.ts`)

package/skills/tool-defs-analysis/SKILL.md

@@ -22,7 +22,7 @@ This skill is the **review-time pass** for that drift. Read each definition the
 | `security-pass` | Injection, scopes, input sinks |
 | `tool-defs-analysis` (this) | LLM-facing language across the existing surface |
 
-`field-test` already audits descriptions for implementation leaks, meta-coaching, and consumer-aware phrasing during its catalog step — that's a fast shallow pass alongside live tool calls. This skill is the deeper review: 10 categories, every field, every recovery hint, every default value, with file:line citations.
+`field-test` already audits descriptions for implementation leaks, meta-coaching, and consumer-aware phrasing during its catalog step — that's a fast shallow pass alongside live tool calls. This skill is the deeper review: 12 categories, every field, every recovery hint, every default value, with file:line citations.
 
 **Read-only.** This skill produces a report; the maintainer applies fixes. While running it, do not run git, do not stage or commit, do not update the changelog, do not run `devcheck`, do not invoke wrapup or release workflows. Fixes flow through the normal authoring path (edit the definition, then re-run this skill if you want to verify).
 
@@ -161,7 +161,7 @@ Prior art: #33.
 
 #### 11. Mutator observability
 
-**Look in:** tool definitions without `annotations.readOnlyHint: true` (writes/updates/deletes/appends/patches).
+**Look in:** mutator tools — any tool that writes, updates, deletes, appends, or patches (i.e., definitions without `annotations.readOnlyHint: true`).
 
 **Check:** `output` carries a state-change discriminator (`created`, `updated`, `mutated`, `unchanged`) or before/after observable state the agent can use to confirm intent-effect match. The server reports what it observed; the agent decides whether it matches what it meant.
 
@@ -218,8 +218,11 @@ End with:
 ## Checklist
 
 - [ ] Scope confirmed (whole server / module / specific files)
+- [ ] Severity floor applied — nits suppressed if user requested
 - [ ] Inventory built — every `*.tool.ts`, `*.app-tool.ts`, `*.resource.ts`, `*.app-resource.ts`, `*.prompt.ts` listed
-- [ ] Each file walked through all 10 categories (per-file, not 10 separate passes)
+- [ ] Each file walked through all 12 categories (per-file, not 12 separate passes)
 - [ ] **Read-only:** no git, no commits, no changelog edits, no `devcheck`, no wrapup invoked during the audit
 - [ ] Findings carry file:line citation, excerpt, issue, fix
 - [ ] Report: summary → grouped-by-category findings → numbered options
+- [ ] Options section produced — numbered, one-per-file, severity tagged, cherry-pickable
+- [ ] If no findings: summary states "no findings"; Findings and Options sections omitted

package/templates/CLAUDE.md

@@ -50,6 +50,7 @@ Tailor suggestions to what's actually missing or stale — don't recite the full
 - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
 - **Check `ctx.elicit` / `ctx.sample`** for presence before calling.
 - **Secrets in env vars only** — never hardcoded.
+- **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed before moving on. The comment is for future readers — state the concrete changes, not the conversation that produced them.
 
 ---
 

package/dist/logs/combined.log

@@ -1,7 +0,0 @@
-{"level":40,"time":1779554652742,"env":"testing","version":"0.9.7","pid":56972,"transport":"http","requestId":"5DGIW-LONS7","timestamp":"2026-05-23T16:44:12.741Z","operation":"TransportManager.start","component":"HttpTransportSetup","msg":"MCP_ALLOWED_ORIGINS is not set — CORS is wildcard for CLI clients; browser Origin headers are restricted to loopback. Set MCP_ALLOWED_ORIGINS for production deployments accepting remote browser origins."}
-{"level":40,"time":1779554654681,"env":"testing","version":"0.9.7","pid":56972,"transport":"http","requestId":"5DGIW-LONS7","timestamp":"2026-05-23T16:44:12.741Z","operation":"TransportManager.start","component":"HttpTransportSetup","sessionId":"not-a-real-session-1779554654681","msg":"Session validation failed - invalid or hijacked session"}
-{"level":50,"time":1779554658688,"env":"testing","version":"0.0.0-test","pid":57052,"requestId":"KD5VX-QNDSK","timestamp":"2026-05-23T16:44:18.688Z","operation":"HandleToolRequest","critical":false,"errorCode":-32005,"originalErrorType":"McpError","finalErrorType":"McpError","sessionId":"eca1f32c9116477ca19cd419874e3d2189fa58a29e6868d4454379f09d08c761","toolName":"scoped_echo","tenantId":"authz-tenant","auth":{"sub":"authz-user","scopes":["tool:other:read"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"errorData":{"sessionId":"eca1f32c9116477ca19cd419874e3d2189fa58a29e6868d4454379f09d08c761","toolName":"scoped_echo","requestId":"KD5VX-QNDSK","timestamp":"2026-05-23T16:44:18.688Z","tenantId":"authz-tenant","operation":"HandleToolRequest","auth":{"sub":"authz-user","scopes":["tool:other:read"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"originalErrorName":"McpError","originalMessage":"Insufficient permissions.","originalStack":"McpError: Insufficient permissions.\n    at forbidden (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:84:58)\n    at withRequiredScopes (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/lib/authUtils.js:68:15)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:146:17)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Insufficient permissions.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:184:26)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)","msg":"Error in tool:scoped_echo: Insufficient permissions."}
-{"level":50,"time":1779554658696,"env":"testing","version":"0.0.0-test","pid":57052,"requestId":"0T35D-7ME6T","timestamp":"2026-05-23T16:44:18.696Z","operation":"HandleToolRequest","critical":false,"errorCode":-32005,"originalErrorType":"McpError","finalErrorType":"McpError","sessionId":"5c8698220b504698a993704832e28f177cbcea7ed9d4ee20b1755f87ff2be9d8","toolName":"scoped_echo","tenantId":"authz-tenant","auth":{"sub":"authz-user","scopes":["openid","email","profile","offline_access"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"errorData":{"sessionId":"5c8698220b504698a993704832e28f177cbcea7ed9d4ee20b1755f87ff2be9d8","toolName":"scoped_echo","requestId":"0T35D-7ME6T","timestamp":"2026-05-23T16:44:18.696Z","tenantId":"authz-tenant","operation":"HandleToolRequest","auth":{"sub":"authz-user","scopes":["openid","email","profile","offline_access"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"originalErrorName":"McpError","originalMessage":"Insufficient permissions.","originalStack":"McpError: Insufficient permissions.\n    at forbidden (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:84:58)\n    at withRequiredScopes (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/lib/authUtils.js:68:15)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:146:17)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Insufficient permissions.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:184:26)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)","msg":"Error in tool:scoped_echo: Insufficient permissions."}
-{"level":50,"time":1779554659793,"env":"testing","version":"0.9.7","pid":57092,"requestId":"710FM-RJENE","timestamp":"2026-05-23T16:44:19.792Z","operation":"httpErrorHandler","critical":false,"errorCode":-32006,"originalErrorType":"McpError","finalErrorType":"McpError","path":"/mcp","method":"POST","errorData":{"path":"/mcp","method":"POST","requestId":"710FM-RJENE","timestamp":"2026-05-23T16:44:19.792Z","operation":"httpErrorHandler","originalErrorName":"McpError","originalMessage":"Missing or invalid Authorization header. Bearer scheme required.","originalStack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at unauthorized (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:86:61)\n    at authMiddleware (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/authMiddleware.js:64:19)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpTransport.js:232:22)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at cors2 (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/middleware/cors/index.js:79:11)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpErrorHandler.js:59:39)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:26:25)\n    at processTicksAndRejections (native:7:39)","msg":"Error in httpTransport: Missing or invalid Authorization header. Bearer scheme required."}
-{"level":50,"time":1779554659808,"env":"testing","version":"0.9.7","pid":57092,"requestId":"9GLH9-PHGBC","timestamp":"2026-05-23T16:44:19.808Z","operation":"httpErrorHandler","critical":false,"errorCode":-32006,"originalErrorType":"McpError","finalErrorType":"McpError","path":"/mcp","method":"POST","errorData":{"path":"/mcp","method":"POST","requestId":"9GLH9-PHGBC","timestamp":"2026-05-23T16:44:19.808Z","operation":"httpErrorHandler","originalErrorName":"McpError","originalMessage":"Token has expired.","originalStack":"McpError: Token has expired.\n    at unauthorized (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:86:61)\n    at handleJoseVerifyError (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/lib/claimParser.js:72:11)\n    at verify (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/strategies/jwtStrategy.js:91:13)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Token has expired.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpErrorHandler.js:59:39)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:26:25)\n    at processTicksAndRejections (native:7:39)","msg":"Error in httpTransport: Token has expired."}
-{"level":50,"time":1779554659811,"env":"testing","version":"0.9.7","pid":57092,"requestId":"T10IM-N5OHM","timestamp":"2026-05-23T16:44:19.811Z","operation":"httpErrorHandler","critical":false,"errorCode":-32006,"originalErrorType":"McpError","finalErrorType":"McpError","path":"/mcp","method":"GET","errorData":{"path":"/mcp","method":"GET","requestId":"T10IM-N5OHM","timestamp":"2026-05-23T16:44:19.811Z","operation":"httpErrorHandler","originalErrorName":"McpError","originalMessage":"Missing or invalid Authorization header. Bearer scheme required.","originalStack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at unauthorized (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:86:61)\n    at authMiddleware (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/authMiddleware.js:64:19)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpTransport.js:232:22)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at cors2 (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/middleware/cors/index.js:79:11)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpErrorHandler.js:59:39)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:26:25)\n    at processTicksAndRejections (native:7:39)","msg":"Error in httpTransport: Missing or invalid Authorization header. Bearer scheme required."}

package/dist/logs/error.log

@@ -1,5 +0,0 @@
-{"level":50,"time":1779554658688,"env":"testing","version":"0.0.0-test","pid":57052,"requestId":"KD5VX-QNDSK","timestamp":"2026-05-23T16:44:18.688Z","operation":"HandleToolRequest","critical":false,"errorCode":-32005,"originalErrorType":"McpError","finalErrorType":"McpError","sessionId":"eca1f32c9116477ca19cd419874e3d2189fa58a29e6868d4454379f09d08c761","toolName":"scoped_echo","tenantId":"authz-tenant","auth":{"sub":"authz-user","scopes":["tool:other:read"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"errorData":{"sessionId":"eca1f32c9116477ca19cd419874e3d2189fa58a29e6868d4454379f09d08c761","toolName":"scoped_echo","requestId":"KD5VX-QNDSK","timestamp":"2026-05-23T16:44:18.688Z","tenantId":"authz-tenant","operation":"HandleToolRequest","auth":{"sub":"authz-user","scopes":["tool:other:read"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"originalErrorName":"McpError","originalMessage":"Insufficient permissions.","originalStack":"McpError: Insufficient permissions.\n    at forbidden (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:84:58)\n    at withRequiredScopes (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/lib/authUtils.js:68:15)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:146:17)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Insufficient permissions.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:184:26)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)","msg":"Error in tool:scoped_echo: Insufficient permissions."}
-{"level":50,"time":1779554658696,"env":"testing","version":"0.0.0-test","pid":57052,"requestId":"0T35D-7ME6T","timestamp":"2026-05-23T16:44:18.696Z","operation":"HandleToolRequest","critical":false,"errorCode":-32005,"originalErrorType":"McpError","finalErrorType":"McpError","sessionId":"5c8698220b504698a993704832e28f177cbcea7ed9d4ee20b1755f87ff2be9d8","toolName":"scoped_echo","tenantId":"authz-tenant","auth":{"sub":"authz-user","scopes":["openid","email","profile","offline_access"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"errorData":{"sessionId":"5c8698220b504698a993704832e28f177cbcea7ed9d4ee20b1755f87ff2be9d8","toolName":"scoped_echo","requestId":"0T35D-7ME6T","timestamp":"2026-05-23T16:44:18.696Z","tenantId":"authz-tenant","operation":"HandleToolRequest","auth":{"sub":"authz-user","scopes":["openid","email","profile","offline_access"],"clientId":"authz-client","tenantId":"authz-tenant","token":"[REDACTED]"},"originalErrorName":"McpError","originalMessage":"Insufficient permissions.","originalStack":"McpError: Insufficient permissions.\n    at forbidden (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:84:58)\n    at withRequiredScopes (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/lib/authUtils.js:68:15)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:146:17)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Insufficient permissions.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/tools/utils/toolHandlerFactory.js:184:26)\n    at executeToolHandler (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:231:34)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/node_modules/@modelcontextprotocol/sdk/dist/esm/server/mcp.js:126:43)\n    at processTicksAndRejections (native:7:39)","msg":"Error in tool:scoped_echo: Insufficient permissions."}
-{"level":50,"time":1779554659793,"env":"testing","version":"0.9.7","pid":57092,"requestId":"710FM-RJENE","timestamp":"2026-05-23T16:44:19.792Z","operation":"httpErrorHandler","critical":false,"errorCode":-32006,"originalErrorType":"McpError","finalErrorType":"McpError","path":"/mcp","method":"POST","errorData":{"path":"/mcp","method":"POST","requestId":"710FM-RJENE","timestamp":"2026-05-23T16:44:19.792Z","operation":"httpErrorHandler","originalErrorName":"McpError","originalMessage":"Missing or invalid Authorization header. Bearer scheme required.","originalStack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at unauthorized (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:86:61)\n    at authMiddleware (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/authMiddleware.js:64:19)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpTransport.js:232:22)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at cors2 (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/middleware/cors/index.js:79:11)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpErrorHandler.js:59:39)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:26:25)\n    at processTicksAndRejections (native:7:39)","msg":"Error in httpTransport: Missing or invalid Authorization header. Bearer scheme required."}
-{"level":50,"time":1779554659808,"env":"testing","version":"0.9.7","pid":57092,"requestId":"9GLH9-PHGBC","timestamp":"2026-05-23T16:44:19.808Z","operation":"httpErrorHandler","critical":false,"errorCode":-32006,"originalErrorType":"McpError","finalErrorType":"McpError","path":"/mcp","method":"POST","errorData":{"path":"/mcp","method":"POST","requestId":"9GLH9-PHGBC","timestamp":"2026-05-23T16:44:19.808Z","operation":"httpErrorHandler","originalErrorName":"McpError","originalMessage":"Token has expired.","originalStack":"McpError: Token has expired.\n    at unauthorized (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:86:61)\n    at handleJoseVerifyError (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/lib/claimParser.js:72:11)\n    at verify (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/strategies/jwtStrategy.js:91:13)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Token has expired.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpErrorHandler.js:59:39)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:26:25)\n    at processTicksAndRejections (native:7:39)","msg":"Error in httpTransport: Token has expired."}
-{"level":50,"time":1779554659811,"env":"testing","version":"0.9.7","pid":57092,"requestId":"T10IM-N5OHM","timestamp":"2026-05-23T16:44:19.811Z","operation":"httpErrorHandler","critical":false,"errorCode":-32006,"originalErrorType":"McpError","finalErrorType":"McpError","path":"/mcp","method":"GET","errorData":{"path":"/mcp","method":"GET","requestId":"T10IM-N5OHM","timestamp":"2026-05-23T16:44:19.811Z","operation":"httpErrorHandler","originalErrorName":"McpError","originalMessage":"Missing or invalid Authorization header. Bearer scheme required.","originalStack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at unauthorized (/Users/casey/Developer/github/mcp-ts-core/dist/types-global/errors.js:86:61)\n    at authMiddleware (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/auth/authMiddleware.js:64:19)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpTransport.js:232:22)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:22:23)\n    at cors2 (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/middleware/cors/index.js:79:11)\n    at processTicksAndRejections (native:7:39)"},"stack":"McpError: Missing or invalid Authorization header. Bearer scheme required.\n    at handleError (/Users/casey/Developer/github/mcp-ts-core/dist/utils/internal/error-handler/errorHandler.js:170:23)\n    at <anonymous> (/Users/casey/Developer/github/mcp-ts-core/dist/mcp-server/transports/http/httpErrorHandler.js:59:39)\n    at dispatch (/Users/casey/Developer/github/mcp-ts-core/node_modules/hono/dist/compose.js:26:25)\n    at processTicksAndRejections (native:7:39)","msg":"Error in httpTransport: Missing or invalid Authorization header. Bearer scheme required."}