Loading ToolBench
Control plane for Claude Code agents. Starts, stops, wakes, and observes per-agent streaming Claude Code sessions from a local cabinet-style dashboard.
Teamfuse exposes 12 agent-control tools via HTTP Next.js routes. All tools have names starting with action verbs (get_, start_, stop_, list_, reset_, wake_, master_control_) and descriptions (avg ~120 chars). Input schemas are present with type declarations for all parameters. However, parameter descriptions are sparse or missing entirely in several tools, output schemas are not documented, and error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Composition is reasonable, tools are single-purpose, but descriptions lack the depth needed for LLM selection confidence.
Returns context entries for an agent including instructions, memory, MCP config, skills, and referenced SOPs. Each entry includes load mode, file path, size, and existence status.
Returns agent logs from .orchestrator/agent-loop.log with pagination support. Returns log content, file size, current offset, and next offset for polling.
Scans and returns available skills for an agent from project-scoped and user-scoped skill directories. Returns skill name, description, scope, and path.
Returns the agent's last-reported MCP tools snapshot from .orchestrator/tools.json. Agents refresh this file on ticks where it's missing or >60min old.
Platform-wide heartbeat. Returns count of agents running (pid alive) vs. agents with recent status.json writes. Includes per-agent heartbeat timestamps and process status.
Aggregates Claude Code usage per agent by scanning ~/.claude/projects/<slug>/*.jsonl and recent rate-limit hits from agent-loop.log. Results are lightly cached by file mtime+size.
Output schemas not documented. Tools return data structures (agent config, logs, skills, tools, heartbeat, usage) but LLMs cannot see what fields to expect. This forces agents to guess field names and risks extraction errors.
Parameter descriptions missing or minimal. 'id' parameter appears in 9 tools with identical description 'Agent ID', no guidance on format, valid values, or how to obtain one. 'offset' in get_agent_logs lacks units/constraints. 'window' in reset_usage has enum but no explanation of what 5h vs 7d means.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Returns list of all agents with their configuration, status, and process information.
Fan-out control: starts or stops all agents in the fleet. Resets the 5-hour usage baseline when starting if no agents are running.
Resets or clears usage baseline for a time window (5h or 7d). Setting baseline to NOW zeros out the usage bar; clearing removes the baseline entirely.
Starts an agent process. Returns process ID and status. Logs the action to agent lifecycle events.
Stops an agent process using SIGTERM or SIGKILL if timeout occurs. Logs the action to agent lifecycle events.
Sends SIGUSR1 signal to the agent wrapper process to interrupt sleep and start the next tick immediately. No-op if agent is not sleeping.
No tool annotations despite clear risk classifications. start_agent, stop_agent, wake_agent, master_control_agents, and reset_usage are WRITE operations that modify state, but lack destructiveHint or idempotentHint annotations. LLMs cannot distinguish safe-to-retry from irreversible operations.
No error handling guidance. Tools return HTTP status codes but no recovery hints. E.g., if start_agent fails because the agent is already running, what should the LLM do? Retry? Call a different tool? No guidance provided.
Composition risk: master_control_agents performs a fan-out operation (start/stop ALL agents) with a single parameter. No confirmation step or dry-run mode. An LLM mistake could halt the entire fleet. Consider adding a 'confirm' parameter or splitting into separate tools.