MCP Tool Reference — Phase 0

Status (R82 Wave 2, 2026-04-19): Phase 0 is sealed at 28/28 (R75 Wave I, commit d5f6a1ff); 14 MCP tools ship over stdio. This document originated at R74.5 as a 19-tool plan and was reconciled to the 14 shipped in R75 Wave H and again in R82 Wave 2 (this revision). Phantom and donor placeholders that appeared in the R74.5 plan were struck per ADR-004 R75 Wave H amendment. The shipped tool list is authoritative here:

Shipped tool list (14): server_ping, server_health, skill_list, task_create, task_list, task_get, task_update, task_next_actions, thought_record, thought_record_list, audit_session_start, audit_verify_chain, merkle_finalize, merkle_root.

Total Phase 0 tools (shipped): 14 across 5 concepts (α/γ system, β task pipeline, ε skill registry, ζ decision trail, η proof store). All tools accept Zod-validated input, write to the ζ Decision Trail audit tables (where applicable), and return typed JSON responses. agent_spawn, agent_status, skill_get, and the entire δ router family are not Phase 0 tools — δ shipped as Phase 0 library-only stubs in Wave I per ADR-005 §Decision (no MCP tools registered); agent_* + skill_get remain deferred to Phase 1.5.

Reading this document

Each tool section includes:

• Signature — TypeScript function-style definition
• Input schema — Zod-compatible type definition with validation rules
• Output schema — Return type structure
• HTTP semantics — Status codes and error responses
• Example — Realistic call (request body) and response

Error responses always use this envelope:

{
  "error": {
    "code": "ERR_CODE",
    "message": "Human-readable message",
    "details": { "field": "value" }
  }
}

---

Category 1: Task Management (5 tools)

task_create

Purpose: Create a new task in the backlog.

Signature:

task_create(input: TaskCreateInput): Promise<TaskCreateOutput>

Input schema:

interface TaskCreateInput {
  title: string;             // Required, 1–256 chars, non-empty
  description?: string;      // Optional, markdown body (0–8000 chars)
  project: string;           // Required, project slug (e.g., "colibri")
  parent_id?: string;        // Optional, parent task ID for sub-tasks
  priority?: 'low' | 'normal' | 'high' | 'critical';  // Default: 'normal'
  labels?: string[];         // Optional, freeform tags (0–20 items)
  assignee?: string;         // Optional, agent ID or user ID; default "unassigned"
  estimate_hours?: number;   // Optional, planning estimate (0–1000)
}

Output schema:

interface TaskCreateOutput {
  task_id: string;           // Colibri-assigned ID (format: "T-{monotonic}")
  status: 'backlog';         // Always starts in backlog
  created_at: string;        // ISO-8601 timestamp (UTC)
  created_by: string;        // Agent ID or user ID of creator
  sequence: number;          // Monotonic counter scoped to project
}

HTTP semantics:

• 200 OK — Task created successfully
• 400 Bad Request — Invalid input (ERR_INVALID_INPUT)
• 404 Not Found — Project not found (ERR_PROJECT_NOT_FOUND)

Example:

Request:

{
  "title": "Wire up task_create MCP handler",
  "description": "Implement P0.3.2 per task-breakdown.md\n\n- Accept TaskCreateInput\n- Validate with Zod\n- Store in tasks table\n- Return TaskCreateOutput",
  "project": "colibri",
  "priority": "high",
  "labels": ["phase-0", "mcp", "backend"],
  "estimate_hours": 4
}

Response:

{
  "task_id": "T-0042",
  "status": "backlog",
  "created_at": "2026-04-08T22:15:30Z",
  "created_by": "agent-alice",
  "sequence": 42
}

---

task_update

Purpose: Update task fields (status, progress, description, assignee, etc.) and enforce valid state transitions.

Signature:

task_update(input: TaskUpdateInput): Promise<TaskUpdateOutput>

Input schema:

interface TaskUpdateInput {
  task_id: string;           // Required, must exist
  status?: 'backlog' | 'todo' | 'in_progress' | 'blocked' | 'review' | 'done' | 'cancelled';
  progress?: number;         // Optional, 0–100 (percentage complete)
  description?: string;      // Optional, replace full description
  priority?: 'low' | 'normal' | 'high' | 'critical';
  assignee?: string;         // Optional, update assignee
  labels?: string[];         // Optional, replace all labels
  blocked_reason?: string;   // Required if status='blocked', optional otherwise
}

Output schema:

interface TaskUpdateOutput {
  task_id: string;
  status: string;
  progress: number;
  updated_at: string;        // ISO-8601 timestamp (UTC)
  updated_by: string;        // Agent ID of updater
  previous_status?: string;  // Status before transition
  warnings?: string[];       // E.g., ["Progress set to 100% but status != 'done'"]
}

State transition validation:

Valid transitions (others rejected):

• backlog → todo | cancelled
• todo → in_progress | blocked | cancelled
• in_progress → review | blocked | cancelled
• blocked → todo | in_progress | cancelled
• review → done | backlog | blocked | cancelled
• done → (terminal, no outbound transitions)
• cancelled → (terminal, no outbound transitions)

HTTP semantics:

• 200 OK — Update successful
• 400 Bad Request — Invalid state transition or malformed input (ERR_INVALID_TRANSITION)
• 404 Not Found — Task not found (ERR_TASK_NOT_FOUND)

Example:

Request:

{
  "task_id": "T-0042",
  "status": "in_progress",
  "progress": 45,
  "assignee": "agent-bob"
}

Response:

{
  "task_id": "T-0042",
  "status": "in_progress",
  "progress": 45,
  "updated_at": "2026-04-08T22:30:15Z",
  "updated_by": "agent-alice",
  "previous_status": "todo"
}

---

task_get

Purpose: Retrieve a single task by ID with all metadata.

Signature:

task_get(input: TaskGetInput): Promise<TaskGetOutput>

Input schema:

interface TaskGetInput {
  task_id: string;           // Required, task ID to retrieve
  include_thought_trail?: boolean;  // Optional, default false; include decision history
  include_dependents?: boolean;     // Optional, default false; include child tasks
}

Output schema:

interface TaskGetOutput {
  task_id: string;
  title: string;
  description: string;
  project: string;
  status: string;
  priority: string;
  progress: number;
  assignee: string;
  labels: string[];
  estimate_hours?: number;
  created_at: string;
  updated_at: string;
  created_by: string;
  updated_by: string;
  parent_id?: string;
  blocked_reason?: string;
  thought_trail?: string[];  // If include_thought_trail=true
  dependents?: string[];     // If include_dependents=true (child task IDs)
}

HTTP semantics:

• 200 OK — Task retrieved
• 404 Not Found — Task not found (ERR_TASK_NOT_FOUND)

Example:

Request:

{
  "task_id": "T-0042",
  "include_dependents": true
}

Response:

{
  "task_id": "T-0042",
  "title": "Wire up task_create MCP handler",
  "description": "Implement P0.3.2 per task-breakdown.md...",
  "project": "colibri",
  "status": "in_progress",
  "priority": "high",
  "progress": 45,
  "assignee": "agent-bob",
  "labels": ["phase-0", "mcp", "backend"],
  "estimate_hours": 4,
  "created_at": "2026-04-08T22:15:30Z",
  "updated_at": "2026-04-08T22:30:15Z",
  "created_by": "agent-alice",
  "updated_by": "agent-alice",
  "dependents": ["T-0043", "T-0044"]
}

---

task_list

Purpose: List tasks with flexible filtering and pagination.

Signature:

task_list(input: TaskListInput): Promise<TaskListOutput>

Input schema:

interface TaskListInput {
  project?: string;          // Optional, filter by project
  status?: string[];         // Optional, filter by status (e.g., ["todo", "in_progress"])
  priority?: string[];       // Optional, filter by priority
  assignee?: string;         // Optional, filter by assignee
  label?: string;            // Optional, filter by single label (AND semantics)
  created_after?: string;    // Optional, ISO-8601 timestamp
  created_before?: string;   // Optional, ISO-8601 timestamp
  search?: string;           // Optional, full-text search on title + description
  limit?: number;            // Optional, default 50, max 500
  offset?: number;           // Optional, default 0 (for pagination)
  sort_by?: 'created' | 'updated' | 'priority' | 'progress';  // Default: 'updated'
  sort_order?: 'asc' | 'desc';  // Default: 'desc'
}

Output schema:

interface TaskListOutput {
  tasks: Array<{
    task_id: string;
    title: string;
    project: string;
    status: string;
    priority: string;
    progress: number;
    assignee: string;
    created_at: string;
    updated_at: string;
  }>;
  total_count: number;       // Total matching tasks (for pagination)
  returned_count: number;    // Number of tasks in this response
  offset: number;
  limit: number;
}

HTTP semantics:

• 200 OK — List returned successfully
• 400 Bad Request — Invalid filter or sort parameter (ERR_INVALID_INPUT)

Example:

Request:

{
  "project": "colibri",
  "status": ["todo", "in_progress"],
  "sort_by": "priority",
  "sort_order": "desc",
  "limit": 10
}

Response:

{
  "tasks": [
    {
      "task_id": "T-0001",
      "title": "Package Setup",
      "project": "colibri",
      "status": "in_progress",
      "priority": "critical",
      "progress": 80,
      "assignee": "agent-alice",
      "created_at": "2026-04-01T10:00:00Z",
      "updated_at": "2026-04-08T14:20:00Z"
    }
  ],
  "total_count": 47,
  "returned_count": 1,
  "offset": 0,
  "limit": 10
}

---

task_next_actions

Purpose: Return all unblocked tasks in todo status, prioritized for execution.

Signature:

task_next_actions(input: TaskNextActionsInput): Promise<TaskNextActionsOutput>

Input schema:

interface TaskNextActionsInput {
  project?: string;          // Optional, default to active project context
  limit?: number;            // Optional, default 20, max 100
  include_blocked?: boolean; // Optional, default false; include blocked tasks with reasons
}

Output schema:

interface TaskNextActionsOutput {
  next_actions: Array<{
    task_id: string;
    title: string;
    priority: string;
    assignee: string;
    estimate_hours?: number;
    parent_id?: string;       // Non-null if this is a sub-task
    dependencies_unmet?: number;  // Count of unfinished dependencies
  }>;
  count: number;
  project: string;
  blocked?: Array<{           // If include_blocked=true
    task_id: string;
    title: string;
    blocked_reason: string;
  }>;
}

HTTP semantics:

• 200 OK — List returned
• 404 Not Found — Project not found (ERR_PROJECT_NOT_FOUND)

Example:

Request:

{
  "project": "colibri",
  "limit": 5
}

Response:

{
  "next_actions": [
    {
      "task_id": "T-0042",
      "title": "Wire up task_create MCP handler",
      "priority": "high",
      "assignee": "agent-bob",
      "estimate_hours": 4,
      "dependencies_unmet": 0
    },
    {
      "task_id": "T-0045",
      "title": "Write task_create tests",
      "priority": "high",
      "assignee": "unassigned",
      "estimate_hours": 2,
      "dependencies_unmet": 1
    }
  ],
  "count": 2,
  "project": "colibri"
}

---

Category 2: Thought & Audit (6 tools)

thought_record

Purpose: Append a hash-chained decision record to the audit trail. Each record references the previous record’s hash, forming a tamper-evident chain.

Signature:

thought_record(input: ThoughtRecordInput): Promise<ThoughtRecordOutput>

Input schema:

interface ThoughtRecordInput {
  task_id: string;           // Required, task this decision pertains to
  type: 'reflection' | 'decision' | 'discovery' | 'risk' | 'blockers';
  content: string;           // Required, decision text (1–5000 chars)
  branch?: string;           // Optional, git branch name (for context)
  commit_sha?: string;       // Optional, git commit (for traceability)
  tests_run?: string[];      // Optional, list of tests executed
  blockers?: string[];       // Optional, list of blocking issues
  metadata?: Record<string, any>;  // Optional, arbitrary JSON
}

Output schema:

interface ThoughtRecordOutput {
  thought_id: string;        // Unique identifier (format: "Θ-{id}")
  task_id: string;
  type: string;
  hash: string;              // SHA-256 of this record
  previous_hash: string;     // SHA-256 of prior record in chain (or null if first)
  recorded_at: string;       // ISO-8601 timestamp
  recorded_by: string;       // Agent ID
  chain_position: number;    // Position in this task's thought chain (1-indexed)
}

Hash calculation:

hash = SHA256(
  JSON.stringify({
    task_id,
    type,
    content,
    previous_hash,
    recorded_at,
    recorded_by
  })
)

HTTP semantics:

• 201 Created — Record appended to chain
• 400 Bad Request — Invalid input (ERR_INVALID_INPUT)
• 404 Not Found — Task not found (ERR_TASK_NOT_FOUND)

Example:

Request:

{
  "task_id": "T-0042",
  "type": "reflection",
  "content": "Completed task_create MCP handler implementation. All tests passing. Zod validation working correctly for edge cases.",
  "branch": "feature/task-create",
  "commit_sha": "a3f7d9b2c",
  "tests_run": ["task_create.test.ts"],
  "blockers": []
}

Response:

{
  "thought_id": "Θ-0047",
  "task_id": "T-0042",
  "type": "reflection",
  "hash": "7e4c...92af",
  "previous_hash": "5a2b...11cc",
  "recorded_at": "2026-04-08T23:15:00Z",
  "recorded_by": "agent-bob",
  "chain_position": 3
}

---

thought_record_list

Purpose: Retrieve the complete thought chain for a task or session (all decision records in order). Shipped in Wave C (P0.7.1) — the R74.5 plan called this thought_list; the shipped name is thought_record_list.

Signature:

thought_record_list(input: ThoughtRecordListInput): Promise<ThoughtRecordListOutput>

Input schema:

interface ThoughtRecordListInput {
  task_id?: string;          // Optional, filter by task
  session_id?: string;       // Optional, filter by audit session
  type?: string;             // Optional, filter by thought type
  limit?: number;            // Optional, default 100, max 500
  verify_chain?: boolean;    // Optional, default false; verify hash integrity
}

Output schema:

interface ThoughtRecordListOutput {
  task_id?: string;
  session_id?: string;
  thought_count: number;
  thoughts: Array<{
    thought_id: string;
    type: string;
    content: string;
    hash: string;
    previous_hash: string;
    recorded_at: string;
    recorded_by: string;
    chain_position: number;
  }>;
  chain_valid?: boolean;     // If verify_chain=true
  invalid_links?: number[];  // Positions of broken links (if any)
}

HTTP semantics:

• 200 OK — Chain retrieved
• 404 Not Found — Task not found (ERR_TASK_NOT_FOUND)

Example:

Request:

{
  "task_id": "T-0042",
  "verify_chain": true
}

Response:

{
  "task_id": "T-0042",
  "thought_count": 3,
  "thoughts": [
    {
      "thought_id": "Θ-0045",
      "type": "decision",
      "content": "Decided to use Zod for input validation...",
      "hash": "5a2b...11cc",
      "previous_hash": null,
      "recorded_at": "2026-04-08T22:30:00Z",
      "recorded_by": "agent-alice",
      "chain_position": 1
    }
  ],
  "chain_valid": true
}

---

audit_session_start

Purpose: Begin a formal audit session. All subsequent operations are tracked under this session until audit_verify_chain is called.

Signature:

audit_session_start(input: AuditSessionStartInput): Promise<AuditSessionStartOutput>

Input schema:

interface AuditSessionStartInput {
  task_id: string;           // Required, task being audited
  auditor_id: string;        // Required, who is conducting the audit
  reason?: string;           // Optional, audit reason (e.g., "proof review", "compliance check")
  scope?: 'shallow' | 'deep'; // Optional, default 'shallow'; shallow = task only, deep = task + dependents
}

Output schema:

interface AuditSessionStartOutput {
  session_id: string;        // Unique session identifier (format: "A-{id}")
  task_id: string;
  auditor_id: string;
  started_at: string;        // ISO-8601 timestamp
  scope: string;
}

HTTP semantics:

• 201 Created — Audit session opened
• 404 Not Found — Task not found (ERR_TASK_NOT_FOUND)

Example:

Request:

{
  "task_id": "T-0042",
  "auditor_id": "agent-auditor",
  "reason": "Proof review before finalization",
  "scope": "deep"
}

Response:

{
  "session_id": "A-0002",
  "task_id": "T-0042",
  "auditor_id": "agent-auditor",
  "started_at": "2026-04-08T23:30:00Z",
  "scope": "deep"
}

---

audit_verify_chain

Purpose: Verify the integrity of the audit trail and thought chain for a task or session.

Signature:

audit_verify_chain(input: AuditVerifyChainInput): Promise<AuditVerifyChainOutput>

Input schema:

interface AuditVerifyChainInput {
  session_id?: string;       // Optional, verify specific audit session
  task_id?: string;          // Optional, verify task's thought chain
  full_trace?: boolean;      // Optional, default false; include all hashes in output
}

Output schema:

interface AuditVerifyChainOutput {
  session_id?: string;
  task_id?: string;
  chain_valid: boolean;
  total_records: number;
  integrity_score: number;   // 0–100, percentage of verified links
  broken_links: Array<{
    position: number;
    expected_hash: string;
    actual_hash: string;
  }>;
  verified_at: string;       // ISO-8601 timestamp
}

HTTP semantics:

• 200 OK — Verification complete (chain valid or invalid)
• 400 Bad Request — Must provide either session_id or task_id (ERR_INVALID_INPUT)
• 404 Not Found — Session or task not found (ERR_NOT_FOUND)

Example:

Request:

{
  "session_id": "A-0002"
}

Response:

{
  "session_id": "A-0002",
  "chain_valid": true,
  "total_records": 8,
  "integrity_score": 100,
  "broken_links": [],
  "verified_at": "2026-04-08T23:35:00Z"
}

---

merkle_finalize

Purpose: Build and lock a Merkle tree from all records in a session, then freeze the root. Used to prove the immutability of a completed audit.

Signature:

merkle_finalize(input: MerkleFinalizeInput): Promise<MerkleFinalizeOutput>

Input schema:

interface MerkleFinalizeInput {
  session_id: string;        // Required, session to finalize
  task_id?: string;          // Optional, include only task-scoped records
}

Output schema:

interface MerkleFinalizeOutput {
  session_id: string;
  merkle_root: string;       // SHA-256 of final root node
  tree_depth: number;        // Height of the tree
  leaf_count: number;        // Total leaf nodes
  finalized_at: string;      // ISO-8601 timestamp
  frozen: boolean;           // Always true on success
}

Merkle tree construction:

• Leaf nodes: hash of each record (thought_record, task_update, etc.)
• Internal nodes: hash of SHA256(left_child + right_child)
• Root: top of the tree

HTTP semantics:

• 200 OK — Tree finalized and locked
• 404 Not Found — Session not found (ERR_SESSION_NOT_FOUND)
• 409 Conflict — Session already finalized (ERR_ALREADY_FINALIZED)

Example:

Request:

{
  "session_id": "A-0002"
}

Response:

{
  "session_id": "A-0002",
  "merkle_root": "8f3c...7d2a",
  "tree_depth": 4,
  "leaf_count": 8,
  "finalized_at": "2026-04-09T00:00:00Z",
  "frozen": true
}

---

merkle_root

Purpose: Retrieve the current Merkle root for a session (the cryptographic fingerprint of all audit data).

Signature:

merkle_root(input: MerkleRootInput): Promise<MerkleRootOutput>

Input schema:

interface MerkleRootInput {
  session_id: string;        // Required, session to query
}

Output schema:

interface MerkleRootOutput {
  session_id: string;
  merkle_root: string;       // SHA-256 of current root
  is_finalized: boolean;     // true if merkle_finalize has been called
  as_of: string;             // ISO-8601 timestamp of last change
}

HTTP semantics:

• 200 OK — Root retrieved
• 404 Not Found — Session not found (ERR_SESSION_NOT_FOUND)

Example:

Request:

{
  "session_id": "A-0002"
}

Response:

{
  "session_id": "A-0002",
  "merkle_root": "8f3c...7d2a",
  "is_finalized": true,
  "as_of": "2026-04-09T00:00:00Z"
}

---

Category 3: Skill (1 tool)

Phase 0 scope. ε Skill Registry’s only Phase 0 MCP surface is skill_list. The registry is populated by parsing the SKILL.md frontmatter of the 23 canonical colibri-* files in .agents/skills/ at startup (P0.6.1 acceptance criterion). There is no JSON manifest substrate — SKILL.md on disk is the source of truth.

Not in Phase 0. Per-skill fetch (skill_get) is a Phase 1 refinement. Sub-agent spawning (agent_spawn, agent_status) has no Phase 0 domain: there is no src/domains/agents/ in the Phase 0 target tree, and agent runtime responsibilities are deferred to Phase 1.5 when δ Model Router lands. See S17 §1 and ADR-005.

skill_list

Purpose: List all skills currently loaded from .agents/skills/*/SKILL.md into the ε Skill Registry, with frontmatter metadata.

Signature:

skill_list(input: SkillListInput): Promise<SkillListOutput>

Input schema:

interface SkillListInput {
  search?: string;           // Optional, substring match on skill name or description
  capability?: string;       // Optional, filter by one of the skill's declared capabilities
}

Output schema:

interface SkillListOutput {
  skills: Array<{
    name: string;            // Directory name under .agents/skills/ (e.g., "colibri-tier1-chains")
    version: string;
    description: string;
    capabilities: string[];  // From SKILL.md frontmatter
    path: string;            // Repo-relative path to the SKILL.md file
  }>;
  total_count: number;
}

HTTP semantics:

• 200 OK — List returned
• 400 Bad Request — Invalid filter (ERR_INVALID_INPUT)

Example:

Request:

{
  "search": "tier1"
}

Response:

{
  "skills": [
    {
      "name": "colibri-tier1-chains",
      "version": "1.0.0",
      "description": "Canonical Tier 1 (Sigma) round and writeback chains.",
      "capabilities": ["round-plan", "writeback-audit"],
      "path": ".agents/skills/colibri-tier1-chains/SKILL.md"
    }
  ],
  "total_count": 1
}

---

Category 4: System & Control (2 tools shipped)

R82 Wave 2 reconciliation. The R74.5 draft of this section enumerated a planned set of AMS-donor and Phase 1+ system tools; those names were struck from this document in R75 Wave H and again in R82 Wave 2. The shipped Phase 0 system surface is two tools: server_ping and server_health. See ADR-004 R75 Wave H amendment for the canonical shipped-vs-deferred status and the list of struck phantoms.

server_ping

Purpose: Liveness check. Returns { ok: true } within 100 ms over the stdio transport; verifies the MCP wire is alive and the server process is responsive.

Signature:

server_ping(input: {}): Promise<{ ok: true; timestamp: string }>

HTTP semantics:

• 200 OK — Server is alive.

server_health

Purpose: Detailed health report. Returns DB open/closed state, migration user_version, middleware stage registry, runtime mode (FULL | READONLY | TEST | MINIMAL), tool count, uptime, and a light set of process metrics. Subsumes the richer status probe the R74.5 plan envisioned as a separate tool.

Signature:

server_health(input: {}): Promise<ServerHealthOutput>

Output schema (representative — see source for the authoritative Zod schema):

interface ServerHealthOutput {
  status: 'ok' | 'degraded';
  mode: 'FULL' | 'READONLY' | 'TEST' | 'MINIMAL';
  uptime_ms: number;
  db: {
    open: boolean;
    user_version: number;
    path: string;
  };
  middleware: { stages: string[] };
  tools: { registered: number };
  version: string;
  timestamp: string;
}

HTTP semantics:

• 200 OK — Health report returned.

---

Error Response Envelope

All 14 Phase 0 shipped tools use a consistent error response format:

{
  "error": {
    "code": "ERR_CODE",
    "message": "Human-readable message",
    "details": {
      "field": "problematic_value",
      "constraint": "rule_violated"
    }
  }
}

Common error codes:

• ERR_INVALID_INPUT — Zod validation failed
• ERR_NOT_FOUND — Resource not found (task, session, agent, skill)
• ERR_INVALID_TRANSITION — Task state transition not allowed
• ERR_CIRCULAR_DEPENDENCY — Circular link detected
• ERR_PROJECT_NOT_FOUND — Project does not exist
• ERR_TASK_NOT_FOUND — Task does not exist
• ERR_SESSION_NOT_FOUND — Audit session not found
• ERR_SKILL_NOT_FOUND — Skill not found
• ERR_AGENT_NOT_FOUND — Agent not found
• ERR_ALREADY_FINALIZED — Merkle tree already frozen
• ERR_INVALID_MODE — Runtime mode not recognized
• ERR_CONFIG_INVALID — Environment configuration invalid
• ERR_INIT_FAILED — Initialization failed

---

Cross-Reference: Donor Extraction Files

Heritage note: These extractions describe donor algorithms (AMS / CogniMesh / Phoenix) that Colibri is peeking at for inspiration, not cloning. Each Phase 0 implementation must still earn its schema and behavior through the 5-step executor chain and its own acceptance criteria.

Topic	Extraction File
Task state machine (7 states, transitions, checkpointing)	docs/reference/extractions/beta-task-pipeline-extraction.md
Merkle tree construction, Merkle proofs	docs/reference/extractions/lambda-proof-system-extraction.md
Hash chain integrity, tamper detection	docs/reference/extractions/kappa-audit-trail-extraction.md
Domain controller pattern, MCP server architecture	docs/reference/extractions/alpha-system-core-extraction.md

---

Implementation Dependencies

Tool introduction order follows the Phase 0 sub-task sequence in docs/guides/implementation/task-breakdown.md. The pipeline groups are not themselves named “Phase 0.1 / 0.2 / 0.3” — Phase 0 is divided into P0.1 – P0.9, each with its own sub-tasks.

System & Control surface (P0.2.1) — shipped

• server_ping, server_health

Task Management surface (P0.3.1 – P0.3.4, β Task Pipeline) — shipped

• task_create, task_get, task_update (accepts status; routes through state-machine), task_list, task_next_actions

Skill surface (P0.6.1 – P0.6.3, ε Skill Registry) — shipped

• skill_list (SKILL.md parser-backed)

Thought & Audit surface (P0.7.1 – P0.7.3, ζ Decision Trail) — shipped (axis closed Wave G)

• thought_record, thought_record_list
• audit_session_start, audit_verify_chain

Proof surface (P0.8.1 – P0.8.3, η Proof Store) — shipped (axis complete Wave F)

• merkle_finalize, merkle_root

---

Summary

This document specifies the 14 concrete Phase 0 MCP tools that shipped (Phase 0 sealed at 28/28 in R75 Wave I, commit d5f6a1ff, 2026-04-18). Each tool entry carries:

• TypeScript-style input/output schemas
• HTTP status codes and error envelopes
• Validation rules and state machines
• Realistic request/response examples

All 14 tools are registered in src/server.ts (delegating to src/tools/*.ts and src/domains/*/*.ts), validated with Zod v3.23, and — where applicable — write to the ζ Decision Trail audit tables. agent_spawn, agent_status, and skill_get are explicitly not in this surface; δ router library stubs shipped in Wave I per ADR-005 §Decision but register no MCP tools.

---

Last updated: 2026-04-19 (R82 Wave 2)
Canonical source: docs/reference/mcp-tools-phase-0.md
Link: [[reference/mcp-tools|MCP Tools Overview]] · [[reference/index|Reference Index]] · [[guides/implementation/task-breakdown|Task Breakdown]]