Loading ToolBench
A code investigation and repair system with MCP server integration, LSP support, and multi-agent investigation capabilities
StratumCode defines 11 tools with explicit schemas and descriptions, but quality is uneven. Investigation tools (clearify, audit_investigation, record_investigation_findings, resolve_unknowns, reopen_investigation_unknown) have detailed, domain-specific schemas with nested objects and enums, but descriptions are lengthy (200-400+ chars) and assume deep familiarity with investigation workflows. Light agent tools (run_investigation, run_write_loop, run_full_pipeline, run_subagent) have minimal descriptions (50-100 chars) and vague semantics ('run the existing...') that don't clearly distinguish when to use each. lsp_tool has good action-based naming and clear enum constraints. Parameter descriptions are present across all tools but often assume context. Error handling guidance is absent, tools don't explain recovery paths. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (READ_ONLY vs WRITE). Output schemas are not documented in the source.
Review coverage and cross-question consistency, trusting accepted node findings. Do not rerun node acceptance. Each new gap must be a new root (parent_id=null); use related_unknown_ids for provenance. Incomplete domains must identify pending questions.
Clarify investigation unknowns through targeted questioning
Finish the investigation with final conclusions
Manage LSP (language server) availability for semantic code navigation. Use operation 'status' to check whether the mason environment is available and which LSP servers exist for a language. Use operation 'install' to install the most suitable LSP server for a language (or a specific server by name). When mason is unavailable, install is skipped and LSP is simply not used.
Record findings and register child questions BEFORE investigating them. A verified collection requires one unanswered question per subject; a synthesis requires separate factual concerns. These are grounded dependencies, not speculative planning. Supply reason, new_unknowns and next_inquiry_reason; runtime slots record findings.
Light agent tools (run_investigation, run_write_loop, run_full_pipeline) have vague, context-dependent descriptions that don't clearly distinguish their purpose or when to use each. 'Run the existing...' assumes the LLM knows internal state. Descriptions should explain the semantic difference and preconditions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels documented in FEATURES. Investigation tools marked WRITE should declare destructiveHint=true; READ_ONLY tools should declare readOnlyHint=true. This helps LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Exceptional correction: reopen only for newly observed evidence contradicting an accepted conclusion. Missing coverage must become a new root through audit_investigation, not a reopened answer.
Record explicit resolutions for investigation unknowns using existing observation or belief ids only.
Run the existing full workflow for the original user request from the analyzer entry: analysis, investigation, design, patch planning, implementation, and validation. The runtime preserves the original request, not a narrowed paraphrase. To continue an existing investigation, use run_write_loop with its investigation_source instead.
Run the existing investigation state for complex read-only codebase investigation. Use this when simple read/grep/code_nav is not enough. Delegate intermittent bugs, cross-layer lifecycle/persistence issues, or a failed previous fix after minimal routing; identifying the root cause belongs inside this investigation.
Run an existing StratumCode subagent and return its final streamed result.
Run the existing rigorous write loop from the design state. Requires the light agent to reference investigation_source returned by a previous delegate; runtime restores its original analysis and investigation without model transcription. Legacy explicit analysis and investigation are also supported. This tool never runs analyzer or investigation itself. Returns validation-centered output instead of raw patch output.
Output schemas are not documented in tool definitions. Investigation tools return complex nested objects (e.g., audit_investigation returns new_unknowns array with nested objects), but the response structure is not visible in the schema. LLMs cannot plan downstream calls without knowing what fields to expect.
Error handling lacks recovery guidance. Tools do not document what errors are retryable, what user actions are needed, or what to do next. E.g., finish_investigation could fail if investigation is incomplete, but the error response doesn't guide the LLM to audit_investigation or clarify.
Investigation tool descriptions are 200-400+ characters, exceeding the 10-200 char baseline for LLM-optimized descriptions. Long descriptions waste tokens and bury key intent. E.g., audit_investigation's description is 280+ chars; condense to 'Review investigation coverage and consistency, identify gaps as new unknowns.'