Loading ToolBench
Model Context Protocol server for the Orcho pipeline engine. Exposes run control, observation, resources, authoring helpers, and supervisor-backed lifecycle tools to MCP-speaking clients such as Claude Code, Cursor, and Zed.
Orcho MCP demonstrates solid foundational quality with 30 well-named tools covering a coherent domain (run orchestration, workspace management, delivery gates). All tools have descriptions (avg ~150 chars, within baseline 194 chars). Input schemas are present and typed via Pydantic. However, parameter descriptions are sparse, many parameters lack explanatory text beyond the name. Output schemas are not documented in the visible code. Error handling guidance is minimal. Tool composition is strong (each tool has one responsibility), but descriptions could be more LLM-optimized per the 50-200 char guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in the metadata.
Record a criterion decision for a run.
Record a delivery decision for a run.
Project delivery gate status for a run.
Reconcile a delivery record after a run.
Record an operator's phase-handoff decision for a paused run.
Validate an architect plan document.
List available Orcho profiles.
Parameter descriptions are sparse. Many parameters (e.g., 'limit', 'decision', 'run_id') lack explanatory text beyond the name. LLMs cannot infer parameter semantics from names alone, 'decision' could mean approval, rejection, or a structured choice.
Output schemas are not documented in visible code. Tool descriptions state what they return (e.g., 'Get metrics for a completed run') but do not specify the structure of the response. LLMs cannot plan downstream tool calls without knowing what fields to expect.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata. Tools marked WRITE or DESTRUCTIVE should carry annotations so clients can warn users or enforce policies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Resolve a prompt template through the project/workspace/core chain.
Request advice from the operator during a run.
Cancel a running or paused run.
Get diagnostic information about a run.
Get a diff of changes made during a run.
Get a bounded summary of events from a run.
Get evidence slices from a run (findings, artifacts, etc.).
Get the history of recent runs.
Get live status card for a run.
Get metrics for a completed run.
Run a project in typed silent mode (synchronous).
Resume a paused run that is awaiting a phase-handoff decision.
Start a new Orcho run against a project directory with optional task description, profile, and mock mode.
Get the current status of a run by run_id.
Long-poll watch a run for state changes and handoff decisions.
List available skills in a project.
Start a project in typed silent mode (asynchronous).
List available workflow recipes.
Confirm and execute workspace cleanup.
Get a workspace cleanup report.
Return where orcho reads/writes runs and which projects appear in recent history. Useful as an initial discovery call so the client knows whether other tools that need ``project_dir`` will succeed.
List the runs awaiting an operator phase-handoff decision. The typed way for a captain to recover pending operator decisions *without chat memory*: it scans the workspace runs directory for runs on ``status=awaiting_phase_handoff`` and returns one bounded row per run.
Return advisory MCP workspace state — last observed cursor per run. Reads ``<ORCHO_WORKSPACE>/mcp/state.json`` (written by every ``orcho_run_events_summary`` and ``orcho_run_watch`` call). Useful for reconnect after a client/session restart: instead of replaying from ``since_seq=0``, callers pick the run's ``last_seq`` and pass it back as ``since_seq``. **Advisory only.** The canonical truth is each run's ``events.jsonl`` + ``meta.json``. A missing or corrupt state file is recreated as an empty envelope on the next observation, so this tool never fails on that account. The state file contains no raw event payloads, prompts, findings, env, or credentials — it is deliberately a small reconnect index.
Error handling guidance is minimal. Tool descriptions do not explain what errors can occur, when to retry, or what the LLM should do next. E.g., 'orcho_run_start' does not document what happens if project_dir is invalid.
Parameter constraints are not documented. E.g., 'limit' parameters lack min/max bounds; 'profile' and 'decision' parameters lack enum constraints or valid value lists. LLMs will guess at valid values.