Loading ToolBench
AI Development Environment - Multi-agent orchestration for Claude Code, OpenCode, and Codex CLI. Provides MCP tools for code analysis, memory management, decision tracking, and project surveying.
Aide demonstrates strong tool coverage with 22 well-organized tools spanning memory management, state, decisions, messaging, and code analysis. Most tools have complete input schemas with typed parameters and detailed descriptions (averaging 150-250 chars). However, output schemas are largely undocumented in the provided source, and several tools lack clear error handling guidance. Tool naming follows verb_noun patterns consistently (memory_search, code_read_check, findings_accept). Parameter descriptions are generally thorough but some lack constraint specifications (e.g., no min/max for limit parameters). The memory and decision management tools are particularly well-designed with sophisticated tagging and multi-scope support. Code analysis tools have good composition with separate concerns (symbols, outline, read, search, references). Main gaps: (1) output schemas not documented in source code review; (2) error handling responses not detailed; (3) some parameters could be more constrained (limit values, enum options); (4) no tool annotations (readOnlyHint, destructiveHint, idempotentHint visible in provided code).
Get the structure of a file (outline/AST view) — function signatures, class definitions, imports, etc.
Read raw file contents (exact bytes). Useful for reading configs, data files, or raw source when you need the exact format.
Read the definition of a specific symbol (function, class, type, etc.) from a file.
Find all references to a symbol across the codebase.
Full-text search across a checkout for code patterns, identifiers, or comments.
Extract symbol definitions from a file — functions, classes, types, constants, etc. Useful for understanding what's exported or defined in a source file.
Retrieve a decision by topic. Returns the current decision in force (may come from this project or inherited from parents/peers depending on anchoring and subscriptions).
Output schemas are not documented in provided source code. Tools lack explicit return type specifications, making it unclear what fields the LLM should expect. This violates the 'Document the output schema' pattern and forces LLMs to infer structure from examples.
Numeric limit parameters (memory_list, findings_list, survey_list) lack min/max constraints. Parameter descriptions do not specify valid ranges (e.g., 'limit must be 1-100'). This invites LLMs to pass unbounded or invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get full history of a decision topic (all versions in chronological order).
List all decisions in force at this project. Optionally include decisions inherited from parent anchors or peer subscriptions.
Mark a finding as reviewed/accepted.
List all findings/issues from analysis.
Search for issues, findings, or analysis results from previous passes.
Store a new memory — a persistent, cross-session fact about the user or project. Memories are short, durable, self-contained factual statements that future sessions can recall via memory_search. Record user preferences, coding conventions, architectural facts, known issues, and blockers as you discover them.
List all stored memories, optionally filtered by category. Returns all memories (not just matching ones) with timestamps. Prefer most recent when answering questions about preferences or decisions.
Search project memories — learned facts, discoveries, issues, and blockers accumulated across sessions. Memories include: user preferences, coding patterns discovered, issues encountered, architectural decisions (use decision_get for formal decisions), and blockers. Supports fuzzy matching (1 edit distance), multi-word OR queries, prefix and substring matching.
Acknowledge a message (mark as read).
List messages sent to your agent. Optionally include already-acknowledged messages.
Send a message to another agent or broadcast to all agents.
Get a state value (global or agent-specific). State keys include 'mode', 'modelTier', 'activeSkill', or custom keys.
List all state values (global and/or agent-specific).
List project survey results (structure, dependencies, architecture info).
Search project survey results — repository structure, architecture, dependencies, etc.
message_send type parameter description lists example types but does not restrict to an enum. LLMs may hallucinate invalid types like 'notify', 'alert', 'escalation'. Should declare as enum: ["status", "request", "response", "blocker", "completion", "handoff"].
No tool annotations visible in source (readOnlyHint, destructiveHint, idempotentHint). This omission prevents clients from reasoning about side effects. Destructive operations like findings_accept and memory_add (WRITE risk) should be annotated.
Error handling and recovery guidance not documented in tool descriptions. No mention of 'what to do if the query returns nothing' or 'how to handle missing resources'. Patterns like recovery-guide are absent.
state_get and state_list descriptions are vague. 'State keys include mode, modelTier, activeSkill, or custom keys' does not explain what these keys control or how agents should use them. Descriptions should guide when to call state_get vs. state_list and what to do with the result.