Loading ToolBench
MCP Server for cross-session orchestration, monitoring, and control of Claude Code sessions. Provides read-only monitoring (Phase 1), decision advisory and logging (Phase 2), control flags (Phase 3), and remote control via WebSocket (Phase 4).
Claude Conductor has 14 well-named tools with clear verb-noun patterns (list_, get_, set_, make_, send_, discover_, cleanup). Descriptions are present and substantive (avg ~150 chars), explaining WHAT each tool does and WHEN to use it. Input schemas are properly structured with types and required fields. However, output schemas are entirely undocumented, no tool specifies what fields it returns, forcing LLMs to guess. Error handling is absent: no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Parameter descriptions are good but lack format constraints (e.g., session_id format, message length limits). Risk annotations (READ_ONLY, WRITE) are present but not formalized as tool annotations per MCP spec. No idempotency hints despite several write operations that could be retried.
Purge stale data: orphaned goals (session no longer alive), old decisions, and disconnected RC sessions from the discovery cache. Run after restarting terminals.
Remove the control flag for a session, returning it to normal operation.
Find all Remote Control sessions by reading bridge-pointer.json files and querying the Anthropic API. Returns server-side session IDs with friendly project names and connection status. Filters to connected-only by default.
Get recent messages and tool calls from a specific session. Returns the last N conversation entries with timestamps, user messages, assistant responses, and tool calls.
Find all sessions currently waiting for user input. Returns the assistant's last message and what user said before it. Use this on a loop to catch sessions that need attention.
List all active control flags across sessions.
No output schemas documented. Tools return data but LLMs cannot plan downstream calls or extract fields. E.g., list_sessions returns session objects but structure is undocumented.
No error handling guidance. Tools lack recovery hints (retryable vs fatal), actionable error messages, or suggestions for next steps. E.g., 'session not found' should suggest calling list_sessions.
Parameter format constraints missing. session_id, message, and event parameters lack length limits, format patterns, or examples. LLMs may pass invalid values without guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
List all registered session goals with their risk levels.
Get detailed status of a specific session: is it processing, waiting for user input, or idle? If waiting, shows what it's asking.
List all Claude Code sessions. Shows PID, project directory, alive/dead status, duration, and last user message for each. Use this to see what all terminals are working on.
Append an event to the conductor activity log (log.md). Use for session state changes, decisions, stalls — anything worth remembering across context compression or overnight.
For a stalled session, read its goal + recent activity and return an approve/escalate recommendation with reasoning. The conductor uses this to decide whether to advise approval or alert the founder.
Send a message/task to a Remote Control session. The message appears in the target session as if the user typed it. Use server-side session IDs (session_* format from discover_rc_sessions).
Set a control flag for a session. The conductor-guard hook reads these flags before every tool call. Use 'block' to pause a session, 'proceed' to explicitly allow, 'block_tool' to block a specific tool type.
Register or update the goal for a session. The conductor calls this after reading a session's initial messages to record what it's working on. Used by make_decision to evaluate if actions are within scope.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) not formalized in schema. Risk levels are documented in comments but not exposed as MCP tool annotations.
Destructive operations lack confirmation/dry-run support. set_flag(block), cleanup, and send_task are irreversible but offer no confirmation step or preview.