Loading ToolBench
Graph-first cognitive daemon with MCP tools, CLI, dashboard, Explorer, and VS Code integration
DreamGraph exposes 4 local support tools with mixed quality. All tools have descriptions and input schemas, but several descriptions are verbose and include implementation details rather than LLM-optimized context. Naming is clear (run_command, modify_entity, write_file, read_local_file) and verb-first. However, descriptions exceed recommended length (10-1024 chars) and some contain example values that LLMs may reuse literally. Error handling guidance is present but inconsistent. Output schemas are not documented. The tools appear designed as fallbacks to MCP equivalents rather than primary operations, which is reflected in descriptions but limits their autonomy.
[Support tool — edit fallback] Replace a code entity in a file. Use as FALLBACK when MCP edit_entity fails. Prefer edit_entity (MCP) first — it validates against the knowledge graph. This tool uses VS Code symbol provider to locate entities precisely and is resilient to whitespace differences.
[Support tool — read fallback] Read a local file. Use only when MCP daemon is unavailable or for quick verification after edits. Prefer query_resource and read_source_code (MCP entity mode) for normal operations. Optionally specify startLine/endLine for a range (1-based, inclusive).
[Support tool — execution] Execute a shell command to build, test, or verify changes. Use after code modifications to run build tools (npm run build, tsc), test runners (vitest, jest), linters (eslint). No MCP equivalent exists for this. Returns exit code and keyword-filtered relevant output.
[Support tool — file creation] Create or overwrite a file. After creating a file, ALWAYS call enrich_seed_data (MCP) to register the new module/feature in the knowledge graph. Parent directories are created automatically. IMPORTANT: content must be under 300 KB. For large files (plans, docs), write in sections: create the file with the first section, then append remaining sections using subsequent write_file calls. Do NOT generate the entire large file inline in a single tool call — this causes output token exhaustion and silent hangs.
Descriptions are verbose (150-250+ chars) and include implementation details ('VS Code symbol provider', 'keyword-filtered') that distract from LLM decision-making. Rubric baseline is 34-392 chars with optimal ~194 chars; these are near the ceiling.
Descriptions include example values (npm run build, tsc --noEmit, eslint) that LLMs may reuse literally instead of adapting to context. Rubric states: 'Do not put example values in the description.'
write_file description prescribes implementation strategy ('write in sections', 'do NOT generate the entire large file inline') rather than focusing on what the tool does. This couples the LLM to a specific implementation approach, reducing flexibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
modify_entity description labels it as 'FALLBACK' to MCP edit_entity, positioning it as secondary. This may bias the LLM away from using it even when appropriate, limiting tool autonomy and composability.
Output schemas are not documented for any tool. The rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' Currently undefined what run_command, modify_entity, write_file, and read_local_file return.
read_local_file and modify_entity accept file paths (absolute or workspace-relative) but do not document path traversal prevention or validation. Rubric: 'Treat all agent-provided input as untrusted. Sanitize against SQL injection, command injection, and path traversal.'
run_command has timeoutMs parameter (default 60s, max 300s) but no guidance on what happens if timeout is hit. Does it return partial output, an error, or kill the process? Error handling should guide recovery: 'If timeout occurs, try increasing timeoutMs or breaking the command into smaller steps.'
write_file's 300 KB size limit is documented in the description, but there is no guidance on what the tool returns if the limit is exceeded. Does it reject the call, or truncate? An LLM needs to know how to recover.