메뉴
Use when adding, removing, renaming, or moving an MCP tool between profiles in apps/web-server/mcp/tools.ts, or when the MCP smoke test fails with a tool-count or unknown-tool mismatch.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | cl_add-mcp-tool |
| description | Use when adding, removing, renaming, or moving an MCP tool between profiles in apps/web-server/mcp/tools.ts, or when the MCP smoke test fails with a tool-count or unknown-tool mismatch. |
A tool change touches a sync triangle: the profile arrays in tools.ts, the mirror
arrays in the smoke test, and (sometimes) the agent-facing instructions. The mirror
arrays are the #1 forgotten step. Background: docs/ARCHITECTURE.md → MCP Layer +
Keep-in-Sync Invariants.
apps/web-server/mcp/tools.ts. Reuse the REST
route via app.inject() — never duplicate orchestrator logic. Author-profile
tools call apps/web-server/src/features/config/logic/feature-authoring.ts directly.CanaryLabMcpToolName union (top of tools.ts).REPAIR_TOOLS, VERIFY_TOOLS,
AUTHOR_TOOLS, or FULL_ONLY_TOOLS (tools.ts:240–307). A tool may appear in
several workflow arrays if it genuinely belongs to several workflows
(e.g. list_features). FULL_TOOLS auto-dedupes the union — never edit it.
registerCanaryLabTools throws at registration if a tool is in no profile.apps/web-server/mcp/server.smoke.test.ts — the test
keeps its own copies of the profile arrays so SDK shape changes are caught.
Update every array you touched in step 3.confirm: z.literal(true) in the input schema
(pattern: abort_run, write_envset).nextSteps via healWaitNext so result-driven
agents block on wait_for_heal_task, and handle boot-only runs with
bootSessionValue/isActiveBootRun so they don't dead-wait.cl_sync-agent-surfaces before finishing.npx vitest run apps/web-server/mcp/server.smoke.test.ts, then the
full suite per cl_verify-changes.| Mistake | Consequence |
|---|---|
| Skipping the smoke-test mirror arrays | Smoke test fails with a tool-count mismatch — or silently passes with stale coverage if you also "fixed" the count |
Editing FULL_TOOLS directly | It's computed; the edit is dead code and the next reader is misled |
| Duplicating route logic inside the tool | Drifts from the REST behavior (admission, collision, envset apply all live in the route) |
| New result shape without updating instructions/skills | External agents invent their own loop — that's the bug INSTRUCTIONS_BY_PROFILE exists to prevent |
Use when creating or extending a Canary Lab feature by hand — "create a feature for X", "add test cases to <feature>", "capture the env files", "switch the feature's branch" — through the author MCP tools (create_feature, capture_feature_env_files, write_envset, start/update/apply_external_draft, get_feature_repo_status, checkout_feature_repo_branch). For docs/PRD/coverage use canary-lab-coverage; for full onboarding of a bare repo use canary-lab (flight).
Use when working the Canary Lab semantic coverage ledger — "what's actually tested?", "map coverage for <feature>", "refresh the PRD summary", "close the coverage gaps", "add this plan/spec to the feature docs" — through the coverage MCP tools (write/list/delete_feature_doc, start/submit_external_summary, start/submit_external_coverage, get_feature_coverage, clear_prd_summary). For writing new tests use canary-lab-author.
Use when exporting a Canary Lab run as an evaluation — "export the evaluation", "produce the report for run 7cvh", "give me the evaluation archive", "review what the run proved" — through the export MCP tools (start/submit_external_evaluation_export, get/list/download_evaluation_export). The run must be terminal (passed, failed, or aborted).
Use when making a Canary Lab feature concurrency-ready — "portify <feature>", "make the ports injectable", "why can't these run concurrently", "undo the portification" — through the portify MCP tools (start/submit_external_portify, get_portify, save_portify, cancel_portify, remove_portification, list_portify_status).
Use when running or healing an EXISTING Canary Lab feature locally — "run <feature>", "fix the failing run", "rerun 7cvh", "drive the heal loop" — through the repair MCP tools (start_run, wait_for_heal_task, signal_run, get_heal_context, pause_run, cancel_heal, abort_run). Fix failing runs by editing app/service code, not tests. For end-to-end onboarding of a new repo use canary-lab (flight); for deployed-environment checks use canary-lab-verify.
Use when the user wants Canary Lab to take a product repo end to end — "test this app", "onboard this repo", "run a flight", "evaluate what I just built" — through the flight pipeline (start_flight / get_flight / respond_flight_checkpoint over MCP). One conducted background pipeline goes from bare repo(s) to a green, covered, healed run ending in an evaluation export. For a single capability use the focused skills instead — canary-lab-run (run + heal), canary-lab-verify (deployed-env verification), canary-lab-author (create feature + specs), canary-lab-coverage (PRD summary + coverage ledger), canary-lab-portify (concurrency-readiness), canary-lab-export (evaluation export).