Loading ToolBench
Automated ADR (Architecture Decision Records) for AI Coding Agents - MCP server with SQL-backed decision repository
Mixed quality across 8 tools. Strengths: most tools have descriptions and action-based parameter enums (decision, constraint, suggest, queue); tool names follow verb patterns (project, help, example, use_case). Weaknesses: (1) No visible input schemas in source code, all parameter definitions are inferred from migration files and tool-schemas.ts references, not from actual schema objects; (2) Description quality varies widely, some are thorough (suggest, example, use_case) but others are vague (constraint='Architectural Rules...') without explaining when to use them; (3) Parameters like _sqlew_project are complex nested objects documented only in text, no JSON Schema validation visible; (4) No output schemas documented anywhere; (5) WRITE-risk tools (decision, constraint, queue) lack error recovery guidance or confirmation patterns; (6) project tool's 'ref' parameter is explained as 'e.g. "sqlew_proj_3"', a problematic example that LLMs may reuse literally. This server is STDIO-only, capping protocol readiness at 50. Definition quality reflects visible schema definitions, which are sparse.
Architectural Rules - Define and manage project constraints with priorities. Use action: "help" for documentation.
Context Management - Store decisions with versioning and metadata. Use action: "help" for documentation.
Example System - Browse and search code examples for sqlew tools. Returns working code snippets with explanations (token-efficient).
Help System - Query action documentation, parameters, and workflow guidance. Returns only requested information (80-95% token reduction vs legacy help).
Project Resolution - Target a specific project per tool call (desktop AI agents / multi-project). Actions: current (show active project), resolve (register/resolve project by root path or name), list (list all registered projects), validate (check whether a root/name/ref resolves cleanly). Desktop flow: call project.resolve { root } once, then pass _sqlew_project: { ref } on subsequent decision/constraint calls.
Queue management - list, clear, and remove items from the action queue.
No input schemas visible in source code. Parameter definitions exist as enums and text descriptions but no actual JSON Schema objects (type, properties, required fields) are shown. Inferred from migration files and tool-schemas.ts references only.
No output schemas documented. Tools return data but the structure (field names, types, required fields, nested objects) is never declared. LLMs cannot plan downstream calls or extract fields reliably.
Tool names are mostly nouns, not verb_noun pattern (decision, constraint, help, example, use_case, queue). This reduces LLM clarity on the action that will occur. Recommend: get_decision, set_constraint, search_examples, list_use_cases, manage_queue.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Intelligent Decision/Constraint Suggestion System - Find related decisions by key pattern, tags, or full context. Prevents duplicates and ensures consistency. Uses hybrid scoring with configurable relevance thresholds.
Use Case Catalog - Browse and search complete workflow scenarios. Returns end-to-end workflows with executable code examples and step-by-step guidance.
Complex _sqlew_project parameter (nested object with root, name, ref, allow_create) lacks JSON Schema type constraints and detailed descriptions per field. Example value 'sqlew_proj_3' in description may be reused literally by LLMs. No validation rules documented.
WRITE-risk tools (decision, constraint, queue with clear/remove actions) lack error recovery guidance, confirmation patterns, or dry-run support. No explanation of consequences (e.g., is 'deactivate' reversible? Does 'clear queue' delete or archive?).
Descriptions for constraint and queue are generic (40 - 50 chars each). They do not explain WHEN to use the tool, what it returns, or how it differs from similar tools. E.g., constraint: 'Architectural Rules, Define and manage project constraints...', why not call 'decision' instead?
Pagination parameters (example, use_case: limit, offset) lack guidance on defaults, max values, or behavior when offset exceeds result count. No indication whether results are sorted or how new items are ordered.
Parameter 'category' (use_case tool) has no enum or valid values documented. LLM must guess or call help to discover options. Recommend: declare enum ['workflow', 'pattern', 'integration', ...] or at least list examples.
suggest tool's scoring system is mentioned (hybrid scoring, min_score default 30) but no documentation on score interpretation (range? semantics?). 'relevance_reason' or scoring methodology not explained, making it hard to prioritize suggestions.
Example value in project tool description ('e.g. "sqlew_proj_3"') creates risk of LLM literal reuse.