MCP

The SWU-MCP is a lifecycle-gated agile-orchestration server. It exposes 59 tools and 14 prompts to any agent that connects, and it refuses whole tools that are called in the wrong mode. This page is a dated public projection of the V1 read-only inspection of that surface. Every figure below is a past-tense observation from that pass, not a live check.

What V1 found, in one paragraph

Where the surface stands

88% of the 59 tools were observed by an actual call— V1’s rule was uncertain is write, so any action whose read/write semantics were ambiguous was deferred rather than exercised. The remaining tools carry evidence class C: their behaviour is known only from the schema they declare and from the error messages they returned, never from a body they successfully produced.

The four lifecycle modes, and what they gate

The MCP refuses whole tools that are called in the wrong mode. Transitioning between modes is itself a call, and each mode names the specific gates the next transition must clear. The mode structure below is class B — it comes from the alignment file the server publishes, not from a per-call observation.

Enforcement rules — the [BLOCK] messages the server emits

Two layers of enforcement run on every call. Mode-level allow/block lists refuse whole tools in the wrong mode (a -32002 LIFECYCLE_VIOLATION response). Content-level gates emit [BLOCK] messages when a Story lacks acceptance criteria, a RAID risk lacks a mitigation, an ADR field is too short, and so on. Each row cites the line in the alignment file where the rule is declared.

The 59 tools, grouped by what they do

The SWU-MCP itself does not declare categories; the grouping below is this page’s, derived from tool names and from the section boundaries in the alignment file (a 1044-line document). Every tool row carries the evidence class V1 assigned to it: class A means a call returned a body; class C means the tool exposes only mutating actions and was deferred entirely under the uncertain is write rule.

The 14 prompts

Prompts are named orchestration recipes the server offers agents. V1 catalogued their names and purposes from the alignment file but did not fetch or execute any of them — their parameter schemas and output shapes remain class F.

What V1 could not close from a read-only chair

V1 was deliberately read-only. Any tool whose behaviour required a mutation to observe was left for a later vector, and every such gap is named here in full rather than quietly excluded. Publishing the gap list is the point: an inspection that only reports what it could reach is not the same as an inspection that reports both.

1. Content-validation [BLOCK] rules (Story AC, Story/Ticket/Epic length, RISK mitigation, ADR fields, NFR threshold) are transcribed from alignment file lines 616–636 (class F) but not one was triggered live — all creates are mutations that V1 refused.
   Why V1 could not close it: V1 is READ-ONLY. Triggering any of these rules requires calling work_manage.create / raid_manage.create / adr_manage.create / spec_manage.create_nonfunctional with intentionally malformed payloads.
   Owned by: V3
2. Whole tool families were mode-blocked in INCEPTION and their read shapes could not be observed (verification_manage, uat_manage, cicd_manage, delivery_pipeline, living_docs_manage, most of release_manage, ticket_orchestrate).
   Why V1 could not close it: mode_manage.transition is a mutation and out of scope for V1. Cannot leave INCEPTION without writing.
   Owned by: V2
3. Seven tools expose ONLY mutating actions (agile_plan, backlog_manage, doc_builder, audit_link_external, apikey_issue, apikey_revoke, bulk_manage) — evidence class remains C (schema only) for their behavior.
   Why V1 could not close it: No read verb available; V1 rules forbid calling under uncertainty.
   Owned by: V3
4. Six probed read actions timed out with -32001 (agent_dispatch.check_auth, agent_dispatch.status, work_manage.search, label_manage.search, audit_manage.query, audit_manage.verify_chain, first time_manage.get_logged) — cannot distinguish 'empty result' from 'server unresponsive'.
   Why V1 could not close it: V1 did not retry aggressively or instrument server-side latency; timeout root cause requires load/perf investigation.
   Owned by: V5
5. Apparent contradiction observed between mode_manage.get.blocked_reason (returns empty '[]') and the _WORKFLOW footer that reports '0/9 required steps complete, blocked by I02..I10' on the SAME program run. Two authoritative surfaces disagree.
   Why V1 could not close it: V1 catalogues the disagreement but cannot resolve without inspecting server source or transitioning modes.
   Owned by: V4
6. 14 auto-emitted LESSON memory entries (from calibration_aggregator) reference persona names — Vox Novus, Vera Free, Guard Ian, Des Igner, React Ive, Api Endor, Owen Pro, Archi Tect, Query Quinn, Content Curator, Pip Line, Inna Cept, Tess Ter, Aiden Orchestr — that do NOT exist in persona_manage.list (0 entries). Dangling references. Also metadata source_phase=phase_2 mismatches content source_phase=phase_0.
   Why V1 could not close it: Fixing (or deleting) requires memory_manage.store or persona_manage.create — mutations.
   Owned by: V4
7. Reads that require an id (docs_manage.read, spec_manage.get, feature_manage.get, adr_manage.read, comment_manage.list, link_manage.get, journey_manage.get, activity_manage.get, knowledge_graph.get_node/subgraph/entity_context, agent_manage.get, verification_manage.get / can_complete, uat_manage.get_scenario / get_results / get_artifacts, historic_run.get_work / get_comments, insights_for on other URIs) could not be exercised because the current program has 0 items or the tool is mode-blocked.
   Why V1 could not close it: V1 cannot invent ids; would need work items or archived runs created upstream.
   Owned by: V2
8. The 14 prompts (agile_story_architect ... tdd_master) are catalogued from alignment file lines 727–743 only — none were fetched or executed; parameter schemas and output shapes are unknown (class F only).
   Why V1 could not close it: MCP prompts are not exposed via any listed tool; retrieval mechanism (get_prompts / prompts/list JSON-RPC) was not attempted under V1's tool-only mandate.
   Owned by: V2
9. Server-side rate limits, quotas, per-tool concurrency caps, and idempotency behavior are undocumented; work_manage limit=100 is the only cap observed (class C from error).
   Why V1 could not close it: V1 did not stress-test; would require repeated writes/reads at scale.
   Owned by: V5
10. Audit chain integrity claim (valid=true, 500 events, 0 broken sequences per INPUT B) could not be independently re-verified in this probe pass — audit_manage.verify_chain timed out both times V1 called it.
    Why V1 could not close it: Only INPUT B carries this claim (class A originally, but V1's own retry failed); needs a fresh run.
    Owned by: V5

Evidence-class glossary

Every claim on this page carries a class marker. The taxonomy is the same one the catalogue itself uses; it is included in the page rather than linked out, because a glossary a reader has to click to open is a glossary most readers never see.

What was taken out of this page