Loading ToolBench
Model Context Protocol server exposing Averos application design, planning, validation, and execution workflows to AI assistants.
Averos MCP server demonstrates solid tool naming (verb_noun pattern) and comprehensive parameter schemas with enums and descriptions. All 12 tools have descriptions and input schemas. However, output schemas are not documented in the source code provided, descriptions lack LLM-optimization guidance (many exceed 200 chars), and error handling lacks recovery guidance. Tool composition is strong (single responsibility, clear chaining via sessionId), but descriptions read as API docs rather than agent-optimized prompts. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels.
Records user approval or rejection of the execution plan. ONLY call with decision=approve after presenting the plan and receiving explicit user confirmation to proceed. Call with decision=reject if the user wants changes.
Builds the execution plan by diffing the validated manifest against current state. Returns an ordered list of operations for user review. Present this to the user and ask for approval before calling execute_plan.
Creates a new design session. Call this first before any other tool. Returns a sessionId required by all other tools. One session = one application being designed.
Shows what changed between manifest versions. Modes: current_vs_executed (changes since last run), revision_vs_revision (two specific history revisions), current_vs_revision (current vs a historical revision). Use list_revisions to see available revision numbers.
Executes the approved plan. Runs all operations in dependency order. Returns execution status and logs. Only callable after approve_plan with decision=approve.
Output schemas not documented. Tools like get_ir, build_execution_plan, get_status return complex objects (manifest, execution plan, status) but no schema is visible in source. LLMs cannot plan downstream calls or extract fields without knowing return structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. execute_plan is IRREVERSIBLE, approve_plan is WRITE, get_ir is READ_ONLY, these should be annotated to guide agent behavior and prevent misuse.
Descriptions lack recovery guidance for errors. update_ir says 'Apply JSON Patch operations' but does not explain what happens on validation failure, how to fix it, or when to call validate_ir. Error responses should guide LLM recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Returns the current session manifest (JSON IR) and its revision number.
Returns the current execution status of a session. Shows which operations have completed, failed, or are pending.
Lists all revision history entries for a session. Shows timestamps, authors, and comments for each revision.
Replaces the entire manifest with a new one. Use update_ir for surgical edits. Use this for full rewrites.
Reverts the manifest to a previous revision. Creates a new revision entry in history.
Applies JSON Patch operations (RFC 6902) to the session manifest (JSON IR). Use op=add to insert, op=replace to update, op=remove to delete. Paths follow JSON Pointer notation (RFC 6901): /entities/0/name. After updating, always call validate_ir to check for errors before build_execution_plan. Use this tool whenever the user asks to add, modify, or remove entities, fields, services, use cases, or any other application component.
Validates the manifest against all schema, referential, and constraint rules. Must pass before build_execution_plan. Returns errors that must be fixed and warnings that are informational.
Descriptions exceed LLM-optimized length (50-200 chars). update_ir is 280+ chars, diff_ir is 250+ chars. Verbose descriptions waste tokens and bury key intent. Condense to core action + when to use.
approve_plan decision parameter lacks guidance on when to call with 'reject'. Description says 'ONLY call with decision=approve after presenting the plan' but does not explain the reject flow or when rejection is appropriate.