Loading ToolBench
A standalone Next.js 16 demo for visualizing context window budget across workspace files and installed skills.
OpenClaw Context Doctor exposes 2 tools via HTTP API routes. Both tools have meaningful descriptions (140-180 chars, within the 10-1024 baseline), but critical gaps exist in schema documentation, parameter descriptions, and error handling. The server provides input validation in the route handlers (e.g., parseCtxSize, path security checks) but does NOT document expected output schemas in the tool definitions themselves, making it difficult for LLMs to understand what fields to extract from responses. Parameter descriptions are present but minimal (under 50 chars each). No evidence of enum constraints, validation error messages for self-correction, or idempotency markers. Tool names follow verb_noun convention (scan_, get_), which is good, but the overall schema visibility and parameter detail fall well below production baseline (94% of A+ tools have full param descriptions; 100% have documented return types).
Returns a bundled demo snapshot showing two workspaces (one healthy, one warning-heavy) to demonstrate context window budget visualization without requiring filesystem access.
Scans a workspace directory and extracts context window budget information including workspace files, installed skills, and bootstrap context overhead. Returns structured snapshot of file sizes, token counts, and health metrics.
Output schemas not documented. scan_workspace and get_mock_snapshot lack explicit response field definitions. LLMs cannot plan downstream operations or extract specific data without knowing the shape of returned objects (e.g., what fields are in the snapshot, how to access file metadata, what 'health metrics' contain).
Parameter descriptions are too generic. 'Absolute path to the workspace directory to scan. Optional; falls back to CONTEXT_DOCTOR_WORKSPACE environment variable if not provided.' (workspacePath) lacks format constraints (must be absolute? string length limits?). 'Context window size in tokens. Must be a positive integer. Optional; defaults to CONTEXT_DOCTOR_CTX_SIZE or 200000.' (ctxSize) states 'positive integer' but provides no min/max bounds (reasonable range is 1 - 10,000,000?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
No enum constraints or validation error messages. The server validates inputs and rejects invalid ctxSize (parseCtxSize returns null if not a positive number), but the tool definition does NOT declare enums or pattern constraints. When the LLM passes an invalid value, error messages ('ctxSize must be a positive integer') are buried in HTTP 400 responses, not in the tool schema where the LLM can see constraints upfront.
Error handling does not guide recovery. HTTP 400/403/404/500 responses return plain-text error messages (e.g., 'Missing workspacePath...', 'Workspace path must stay inside CONTEXT_DOCTOR_ALLOWED_ROOTS...'). While readable, they lack guidance on what the LLM should do next: retry, call a different tool, or escalate to the user. No recovery hint (e.g., 'Check CONTEXT_DOCTOR_ALLOWED_ROOTS config or try get_mock_snapshot() instead.').
No tool annotations for safety. Neither tool declares readOnlyHint, destructiveHint, or idempotentHint. Both are read-only operations (no state modification), but the tool definitions lack explicit hints. scan_workspace might be slow on large directories (agent should be warned to expect latency).
No pagination or result-limiting declaration. scan_workspace description states it 'returns structured snapshot of file sizes, token counts, and health metrics' but does not clarify: is the result a single object, an array, paginated? If files are large, are results truncated? If a workspace has 10,000 files, does the tool return all summaries or cap at N items? Absence of limits invites runaway agents and context window exhaustion.