Loading ToolBench
MCP server for AI Software Architect framework
This server has complete tool definitions with schemas and descriptions present for all 6 tools. However, the quality varies significantly. Tool names follow verb_noun convention consistently (setup_architecture, create_adr, list_architecture_members, get_architecture_status, configure_pragmatic_mode, get_implementation_guidance). Descriptions are present and mostly adequate (averaging ~120 chars), but several fall short of the 50-200 char sweet spot and lack explicit guidance on WHEN to use each tool or prerequisite information. All parameters have descriptions and types, and enums are used where appropriate (intensity in configure_pragmatic_mode). However, output schemas are completely undocumented, we cannot see what fields are returned by any tool, which blocks LLM planning for downstream calls and breaks tool composition patterns. Error handling is not visible in the code excerpt provided. The server shows no security concerns (no credentials as parameters, proper path-based access), and tool relationships are clear (setup_architecture must be called before others), but the lack of output documentation and guidance on error recovery significantly limits production readiness.
Enable and configure Pragmatic Mode (YAGNI Enforcement) to prevent over-engineering
Create an Architectural Decision Record (ADR)
Get the current status of architecture documentation and decisions
Get implementation methodology, influences, and practices configuration for 'Implement as the architects' command. Returns configured methodology (TDD, BDD, etc.), influences (Kent Beck, Sandi Metz, etc.), language-specific practices, testing approach, refactoring guidelines, and quality standards.
List all available architecture team members and their specialties
Set up the AI Software Architect framework in the current project
Output schemas completely undocumented for all 6 tools. Tool descriptions mention what will be returned (e.g., 'returns configured methodology, influences, practices') but no formal JSON schema is visible. This blocks LLM planning for downstream tool calls and breaks composition patterns. Agents cannot know what fields to extract without trial-and-error.
No pagination support visible. list_architecture_members and potentially get_architecture_status may return unbounded results. If the members list grows large, all results are returned, wasting tokens and degrading LLM reasoning. No limit, offset, or cursor parameters are visible.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 21 | - | v1 |
Descriptions lack explicit guidance on WHEN to call each tool and what prerequisites must be met. For example, create_adr does not state whether setup_architecture must be called first, where ADRs are stored, or what happens if the project is not initialized. Agents must infer relationships through trial-and-error.
No visible error handling or recovery guidance in tool descriptions. If setup_architecture fails (e.g., directory already set up, permission denied, invalid path), agents have no hint on what to do next or how to self-correct. Descriptions do not mention error cases or conditional success.
Parameter descriptions are generic in some cases. For example, 'projectPath' is described only as 'Path to the project root directory', no validation on format (absolute vs relative), no hint if it must exist, no example. featureDescription in get_implementation_guidance has no constraint (length, format, required keywords).
Tool descriptions use vague language that does not match LLM expectations. 'Get the current status' (get_architecture_status) does not explain what 'status' means, is it a boolean, a summary, a list of pending tasks? 'List all available' (list_architecture_members) does not state how many members are typically expected or if roles/specialties are included in the response.