tzero-mcp

orchestrate_agent_swarm

Dispatch autonomous multi-agent swarms to decompose and execute coding goals, reach Byzantine fault-tolerant consensus on proposals, or diagnose and patch failing tests.

Instructions

Coordinates autonomous multi-agent task execution, goal decomposition, Byzantine fault-tolerant (PBFT) consensus voting, and self-healing error recovery, distinguishing from 'manage_memory_store' and 'audit_code_quality' by dispatching autonomous multi-agent workflows rather than managing memory stores or auditing code quality.

Parameters:

goal (str, required): High-level goal description, swarm proposal, or failing test traceback to heal.
orchestration_mode (str, optional, default='goal_execute'): Orchestration mode: 'goal_execute' for autonomous goal planning and execution, 'swarm_consensus' for Byzantine fault-tolerant voting, 'self_healing' for AST error diagnosis and automated patching.
agents (str, optional, default=''): Comma-separated list of agent roles participating in swarm execution (e.g. 'architect,coder,tester').
project_root (str, optional, default='.'): Workspace root for swarm execution (default: current directory).

Behavior:

State execution: Dispatches sub-tasks, coordinates consensus rounds, and executes self-healing patches.
Non-idempotent: Execution results reflect dynamic agent responses and patch attempts.
100% Offline: Executes deterministic local multi-agent workflows without unverified cloud relays.
Auth & Rate Limits: Zero credentials or external blockchain relays required; completes in <100ms.
Error Handling: Quorum isolation automatically detects and neutralizes Byzantine faults.

Usage Guidelines:

When to use: Execute high-level complex coding goals across multi-agent swarms, validate proposals via Byzantine consensus voting (3f+1 quorum), or diagnose and heal test failures.
When NOT to use: Do not use for querying or managing long-term agent memory (use 'query_memory_store' and 'manage_memory_store' instead); do not use for auditing codebase quality before task execution (use 'audit_code_quality' instead).

Returns: Orchestration summary with phased execution plan, agent task allocations, consensus voting tallies, or self-healing patch results.

Input Schema

Name	Required	Description	Default
`goal`	Yes	High-level goal description, swarm proposal, or failing test traceback to heal.
`agents`	No	Comma-separated list of agent roles participating in swarm execution (e.g. 'architect,coder,tester').
`project_root`	No	Workspace root for swarm execution (default: current directory).	.
`orchestration_mode`	No	Orchestration mode: 'goal_execute' for autonomous goal planning and execution, 'swarm_consensus' for Byzantine fault-tolerant voting, 'self_healing' for AST error diagnosis and automated patching.	goal_execute

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv7.3.2Oct 24, 2026
Removedv7.0.1Oct 24, 2026
Addedv7.0.0Oct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real context beyond the annotations: non-idempotent mutation, fully offline execution, no credentials/relay, sub-100ms completion, and quorum-isolation error handling. However, 'Non-idempotent' and 'Offline' largely restate idempotentHint=false and openWorldHint=false, so part of the disclosure duplicates structured data rather than extending it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Sectioned with headers and front-loaded with purpose, but there is wasted space: the sibling differentiation appears both in the opening paragraph and again in 'When NOT to use', and the four-bullet parameter list is a verbatim copy of the schema. Marketing-style claims ('100% Offline', '<100ms') pad the behavior block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, non-idempotent, multi-mode orchestration tool, the definition covers mode selection, agent role input, auth/rate-limit posture, error handling, and a returns summary. An output schema exists, so detailed return structure need not be spelled out, and the remaining guidance is sufficient to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all four parameters; the description's parameter block repeats the schema text almost verbatim, including the orchestration_mode value list. Baseline 3 applies since the schema does the heavy lifting and the description adds no syntax, constraints, or interaction rules.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb set (coordinates, decomposes goals, runs PBFT consensus, self-heals) over a named resource (multi-agent swarm), and explicitly names the sibling tools it is not. An agent can pick this out from query_memory_store or audit_code_quality on name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'When to use' conditions (complex coding goals, consensus validation with 3f+1 quorum, test-failure healing) and a 'When NOT to use' section that routes to query_memory_store, manage_memory_store, and audit_code_quality by name. No inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server