Loading ToolBench
Local MCP server that exposes the global brain to any MCP-aware AI tool (e.g. Claude Code) so the AI reads full historical context before executing any task. Transport is stdio; it never opens a network socket and never sends data externally.
ArchLab MCP server has 4 tools with basic descriptions and empty input schemas. All tools are READ_ONLY and accept minimal parameters. Naming follows verb_noun convention (brain_overview, list_projects, get_project, search_patterns), which is good. However, descriptions are generic (avg ~100 chars) and lack actionable context for LLM selection. Critical gap: input schemas are empty objects {} for all tools except search_patterns, which has a single 'keyword' parameter with type and description. No output schemas documented. No error handling guidance. No parameter validation rules. Tools lack composition hints (e.g., what fields get_project returns, whether brain_overview returns project IDs for chaining to get_project).
Global ArchLab brain overview: project count, cross-project patterns, and proactive insights learned across every analyzed project.
Get the full intelligence report and diagnostics for one analyzed project by id or name.
List every project ArchLab has analyzed, with a one-line summary each.
Search learned cross-project patterns by keyword (e.g. "auth", "sql", "scaling").
Empty input schemas for 3 of 4 tools (brain_overview, list_projects, get_project). Tools accept parameters but schemas are {}.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., does list_projects return project IDs for chaining to get_project?). Violates pattern:tool and mxe:include-chaining-ids.
Descriptions lack actionable context. 'Global ArchLab brain overview' (brain_overview) does not explain WHEN to call it vs list_projects, what it returns, or what 'cross-project patterns' means. Descriptions should be 50-200 chars with clear intent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
get_project accepts 'idOrName' parameter but no validation rules documented. Description does not specify format (e.g., 'Project ID (UUID) or name (string, case-sensitive?)'). Violates review:param-validation-rules.
No error handling guidance. Tools do not document what happens if project not found, keyword matches nothing, or backend service fails. Per pattern:recovery-guide, errors must tell LLM what to do next.