Loading ToolBench
Open-source coding-agent harness you can actually change — own the loop (prompts, gates, routing, skills, terminal states), use any model, run long tasks while you're away.
Two tools with reasonable descriptions but significant schema and parameter documentation gaps. get_runtime_state has a well-written description (180+ chars) explaining use cases and views, but lacks explicit input schema documentation in the source. agent tool description is adequate but vague on parameter constraints and error handling. Neither tool shows complete JSON Schema with type definitions for all parameters. Parameter descriptions exist but lack format constraints, ranges, and validation rules expected in production tools.
Dispatch a child agent (subagent) to handle a task. The child inherits the parent's tool surface unless constrained by an agent type. Supports delegation, parallel execution, and budget enforcement.
Inspect what the runtime knows about this session: identity (sessionId, surface, depth, parent), tool affordances (currently-enabled tool names and MCP server summary), delegation state (active subagent handles, background jobs), and git workspace state (branch, HEAD SHA, dirty count, remote URL). Returns a compact JSON snapshot. Use when uncertain about: your current nesting depth, whether a tool you want is actually available right now, what MCP servers are wired, whether earlier subagents you dispatched are still running, or what git branch / commit the session started on. Views: - `self` — identity + model + permissions + cwd only - `tools` — enabled tool names + MCP server summary only - `subagents` — active subagent handles + background jobs only - `workspace` — git state (branch, headSha, dirty, dirtyCount, remoteUrl) - `all` — union of the four above (default) This is a read-only, in-memory inspection. It does not probe the file system or network. Fields the runtime does not know (e.g. depth for a top-level session) come back as `null` rather than synthesised defaults.
Input schemas lack explicit type definitions and constraints. get_runtime_state view parameter shows enum but no formal JSON Schema visible; agent parameters (model, max_turns, max_tool_use_iterations) lack type declarations, ranges, and validation rules.
Output schemas not documented. Neither tool describes what fields are returned, their types, or structure. LLMs cannot plan downstream calls or extract required data without knowing response shape.
agent tool description lacks clarity on error handling and recovery. No guidance on what happens if agent_type is unknown, task fails, or budget is exceeded. Missing actionable error messages.
Parameter descriptions lack format constraints and ranges. agent's max_turns and max_tool_use_iterations have no min/max bounds stated; model parameter has no enum of supported models; task parameter has no length limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
get_runtime_state description mentions views but does not document what each view returns (field names, types, structure). Users cannot predict response shape without reading implementation.