Loading ToolBench
Minimal workflow and terminal intelligence for Claude Code, Codex CLI, and Antigravity CLI. Provides output reduction, context continuity, and memory management for coding agents.
weave-mcp has 8 tools with explicit schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (get_policy, memory_save, memory_load, memory_list, memory_show, discover, gain, prompt). Descriptions exist but are terse (avg ~80 chars, well below the 194-char baseline). Most critically: NO parameter descriptions anywhere. The inputSchema objects declare properties and types but omit 'description' fields entirely. This violates the core pattern:tool-description rule, LLMs cannot infer parameter meaning from names alone. For example, 'cwd' appears in 6 tools with no explanation of what it controls or when to use it. The 'mode' enum is undocumented. The 'prompt' tool has 9 parameters with zero descriptions. Error handling is absent, no guidance on what to do if a memory load fails or a directory is invalid. Output schemas are not documented; callers must infer structure from tool names. Security: memory_save and memory_load write to .weave/ directories with minimal validation (only assertValidDir checks). No audit trail, no permission gates, no rate limiting.
Estimate output reduction missed in past Claude Code sessions for this project, not wrapped by Weave.
Report this project's recorded Weave terminal-output reduction (from .weave/runs/).
Return the Weave engineering policy text for a given mode.
List saved memories in this project
Load a memory snapshot from .weave/memories/<name>.md into .weave/state.md
Save a memory snapshot into .weave/memories/<name>.md
Show content of a saved memory snapshot
Zero parameter descriptions across all 8 tools. Every parameter (cwd, mode, name, file, task, budget, etc.) lacks a description field in inputSchema. LLMs cannot infer what 'cwd' means or when to pass it vs omit it.
No output schema documentation. Tools return text responses via text() helper, but callers have no formal schema for what fields/structure to expect. Breaks downstream tool chaining and forces LLMs to parse unstructured output.
Minimal error handling. callTool() throws generic Error objects with no recovery guidance. E.g., 'invalid directory' or 'invalid mode' give no hint on what to do next. No categorization of retryable vs fatal errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Generate a structured Weave SuperPrompt: request contract, 5-pillar operational memory, budgeted reasoning protocol, and the 6-question fidelity gate. Emits clean Markdown text by default, or XML when xml: true.
Weak input validation. toolCwd() only checks if directory exists; no sanitization against path traversal. memory_save accepts arbitrary 'name' and 'file' strings with minimal guards. LLMs could be tricked into writing outside .weave/.
Terse tool descriptions (avg ~80 chars vs 194-char baseline). Descriptions like 'Report this project's recorded Weave terminal-output reduction' lack context on WHEN to call the tool or what the output means. No dependency hints (e.g., 'Call gain() first to see if runs exist').