Loading ToolBench
MCP server for Agent Zone — infrastructure knowledge for AI agents
Agent Zone MCP presents a well-structured knowledge base and template access interface with mostly complete schemas and clear descriptions. All 7 tools have input schemas defined with Zod and descriptions present. However, the server has several notable gaps: output schemas are not formally documented (only described in prose), parameter descriptions lack detailed format guidance, error handling is minimal (generic try-catch without recovery hints), and there are no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear READ vs WRITE semantics. The naming is verb-forward and clear ('search', 'get_article', 'list_categories', 'submit_feedback', 'suggest_topic', 'list_templates', 'get_template'), and descriptions are contextual and moderately detailed (avg ~150 chars). Tool composition is good, each tool has a single responsibility and tools chain well (search → get_article, list_templates → get_template). The two write tools (submit_feedback, suggest_topic) lack confirmation patterns or dry-run options, and error messages are generic ('failed to submit feedback: {e}'). Output is returned as structured text content, not as rich typed objects. Overall, this is a solid C+ / B- server with room for protocol alignment and error guidance improvements.
Retrieve the full content of an Agent Zone article by its ID. Returns the complete article with markdown content, metadata, categories, tags, and skills.
Get detailed metadata for a specific Agent Zone template by ID. Returns requirements, what it produces, estimated duration, cost, and tags.
List all knowledge categories available in Agent Zone with article counts. Useful for discovering what topics are covered.
Search and list Agent Zone infrastructure templates. Templates are ready-to-use configurations for validation (Path 1), local testing (Paths 2-3), cloud testing (Path 4), and dev environments (Path 5).
Search Agent Zone knowledge base for infrastructure articles. Returns matching article titles, descriptions, and IDs. Use get_article to retrieve full content.
Output schemas not formally documented. All tools return text content via MCP's content array, but the structure of the underlying data (field names, types, presence) is inferred from code prose rather than declared as formal schemas. Clients and LLMs cannot reliably parse or plan downstream operations.
Example values embedded in parameter descriptions ('kubernetes rbac', 'prometheus alerting', 'validation~helm-lint'). Should use enums, regex patterns, or format declarations instead.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools have clear semantics (search, get_article, list_categories, list_templates, get_template are read-only; submit_feedback and suggest_topic are write operations), but MCP annotation hints are absent. Agents cannot determine safety/retry semantics from metadata.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Submit feedback on an Agent Zone article. Use this to report helpful content, inaccuracies, outdated information, or suggest improvements.
Suggest a new topic or article for Agent Zone. Use this when you notice a gap in the knowledge base that would be useful for infrastructure work.
Minimal error handling and no recovery guidance. Error responses are generic ('Feedback failed: {data.error}', 'Failed to submit feedback: {e}') and do not suggest recovery steps. Try search() with a partial name.').
Write tools lack confirmation or dry-run patterns. submit_feedback and suggest_topic have irreversible side effects (feedback is recorded, suggestions are submitted) but offer no confirmation step or preview. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.
Pagination not fully implemented. list_templates accepts a limit parameter and defaults to 25, but does not return a total_count or next_cursor.
Parameter descriptions lack prescriptive format guidance. For example, 'feedback_type' description says 'Type of feedback' but enum values are listed in schema only, not prose. Descriptions should state 'One of: helpful, inaccurate, outdated, needs-examples, other' for clarity when schema is not visible.