MCP server for orchestrating Claude Code CLI and Gemini CLI sessions to perform coding tasks. Provides tools for managing coding agents, task execution, and state persistence. Perfect for automating complex coding workflows across multiple AI assistants.
This MCP server has significant definition quality gaps. Tools have descriptions and basic schemas, but lack clarity on mutually exclusive parameters, error handling guidance, and output documentation. Parameter descriptions are generic and do not include constraints or dependency information. Many tools are write/destructive operations without confirmation patterns. Schema completeness varies: some tools have proper input definitions, but output schemas are not documented anywhere. Per-tool average: 42.
Checks the current status of tasks, agents, or system state
Cleans up and resets the application state, removing old tasks and sessions
Creates a new coding task to be executed by Claude Code or Gemini CLI
Terminates an active coding task and collects final results
Retrieves a coding prompt template for a specific category or use case
Generates a report on the status and results of a completed task
Updates the state or parameters of an existing task
No documented output schemas for any tool. LLMs cannot determine what fields to expect in responses, forcing unstructured parsing and downstream failures.
Destructive operations (clean_state, end_task, update_task) lack confirmation or dry-run patterns. Agents risk unrecoverable state loss without explicit guards.
Parameter descriptions are generic and lack constraint information. E.g., 'scope' in clean_state has values [all, completed, failed] but no explanation of what each does or consequences of each choice.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 62 | 2025-06-18+ | v1 |
update_task has optional parameters (status, metadata) with unclear semantics. Description does not explain: Can both be updated together? What are valid status values? Are there side effects?
No error handling guidance. Tools do not specify: what errors are retryable? What should the LLM do if task_id is not found? Should it search for alternatives?
create_task omits 'tool' from required parameters in schema, but description says it is required. This mismatch will cause LLMs to omit the parameter in some calls.
No indication of idempotency. If an agent retries create_task, does it create a duplicate task or return the existing one? This risks duplicate side effects.
check_status returns different data structures depending on 'context' parameter, but the tool description does not explain what each context type returns or which fields are present.