-
Verify the live surface; never describe it from memory. The removed 5-tool names and include_playbook live in model training data and get hallucinated into "here's how this MCP works" tables. After any change, run /verify-live-mcp and quote what the server returns — do not narrate the surface from recall.
-
The version string is NOT proof of a deploy. This repo has no auto version bump — package.json.version (→ health://status.version) only moves when bumped by hand, and most changes don't bump it. A change can be fully live while the version is unchanged. Prove a deploy by the tool/schema surface + the active-deployment commit, never the version number:
npx mcp-use servers get 188771a3-172e-41d0-926d-bb15bb609802
-
Deploy via deployments restart, not mcp-use deploy. npx mcp-use deploy does a GitHub-App access precheck that false-positives and hangs on an interactive browser-authorize prompt. Use:
ID=$(npx mcp-use servers get 188771a3-172e-41d0-926d-bb15bb609802 | grep 'Active deployment' | awk '{print $3}')
npx mcp-use deployments restart "$ID" --follow
The GitHub→Manufact webhook fires on push to main but can lag past CI deploy-verify's budget; deploy-verify self-heals by triggering a restart itself. Don't trust a red or green deploy-verify alone — verify with servers get + a live /verify-live-mcp smoke.
-
CI is the verification authority; do not run heavy commands locally. This Mac mini stalls under full builds/typechecks/test suites — run them through CI on the pushed branch. A single-file tsx --test tests/one.test.ts for a tight loop is fine. Git worktrees have no node_modules, so pnpm typecheck/build cannot run inside one — rely on CI there.
-
.strict() is a schema-level contract, not a wire-level guarantee. The mcp-use transport tolerates unknown request properties for every tool in this deployment (verified live: a bogus key on web-search also succeeds). So removing a public field does not hard-reject old callers — they get silent success, not an isError. Weigh that when you plan a "breaking" removal: it degrades gracefully at the wire, whatever the Zod schema says.
-
Know CI's blast radius. CI (.github/workflows/ci.yml) path-ignores root markdown, docs/**, .planning/**, license, and gitignore-only changes. Nested src/**/*.md and .claude/** do trigger CI. deploy-verify runs only on a non-doc push to main. Four parallel jobs: typecheck, unit, http, contract.
-
Interpret health snapshots, don't overfit one flag. llm_planner_ok:false is not by itself a deploy failure. We observed a fresh healthy deploy with llm_planner_ok:false, consecutive_planner_failures:1, llm_runtime_available:true, and a live get-research-consultancy call returning isError:false plus a real ## Your research brief. Treat that as a transient planner probe parse/validation blip. A real planner outage needs corroboration: repeated failures (gate threshold), runtime unavailable, and/or real calls degrading to the fallback note.
Frame → change one invariant-respecting unit → verify → ship. Details and
copy-paste recipes (add a tool, change a schema, add a client/Layer, add an env
var, deploy) are in references/change-recipes.md. The short form: