Loading ToolBench
Professional AI-powered architecture diagram generator with MCP server support for creating diagrams with provider-specific icons for AWS, Azure, GCP, Kubernetes, and more
This server has moderate definition quality with significant gaps. All 5 tools have descriptions and basic parameter schemas, but descriptions are verbose and include unnecessary language-switching instructions that clutter the signal. Parameter descriptions are minimal (typically 1-2 sentences). Output schemas are undocumented, LLMs cannot predict response structure. Error handling guidance is present but inconsistent. The tool set is well-composed (discovery → creation workflow) but naming could be more consistent (e.g., 'create_diagram_from_json' vs 'create_multicloud_diagram' have different naming patterns for similar operations). The repeated language-instruction injection in every docstring indicates the descriptions were not optimized for LLM parsing, LLMs do not parse prose instructions; they need structured constraints.
Create an architecture diagram from a JSON specification. IMPORTANT: Respond in the same language as the user's request. If the user speaks Spanish, respond in Spanish. If the user speaks English, respond in English. 📋 Recommended workflow for professional diagrams with correct icons: 1. list_providers() → See all available cloud providers 2. get_provider_categories(provider) → See categories for chosen provider 3. get_category_nodes(provider, category) → Get exact node names 4. create_diagram_from_json() → Create diagram with exact names from step 3 ⚠️ Using exact names from the discovery steps ensures correct icons! Args: diagram_spec: JSON specification of the diagram. Required format: SINGLE-CLOUD EXAMPLE, MULTI-CLOUD EXAMPLE (use component_provider for each component), IMPORTANT: Use "clusters" (NOT "children"), Use exact node names from get_category_nodes(), Connections support: color, style, label, Layouts: "horizontal" or "vertical" title: Optional diagram title (overrides spec title) Returns: Diagram generation result with file path and details
Create a multi-cloud architecture diagram with components from different providers. IMPORTANT: Respond in the same language as the user's request. If the user speaks Spanish, respond in Spanish. If the user speaks English, respond in English. This is a convenience tool for multi-cloud scenarios. Each component can specify its own provider using "component_provider". Args: title: Diagram title components: JSON array of components with component_provider field connections: JSON array of connections (optional) layout: "horizontal" or "vertical" (default: horizontal) Example components with AWS Lambda, Azure Functions, Cloud Functions Returns: Diagram generation result
Get ALL nodes/icons available for a specific provider category. IMPORTANT: Respond in the same language as the user's request. If the user speaks Spanish, respond in Spanish. If the user speaks English, respond in English. This is STEP 3 of the recommended workflow. Use get_provider_categories() first. Args: provider: Provider name (aws, azure, gcp, k8s, etc.) category: Exact category name (compute, network, database, etc.) Returns: Complete list of nodes to use in create_diagram_from_json with exact names
Output schemas not documented. No tool specifies what fields the response contains, data types, or structure. LLMs cannot reason about downstream tool chaining or extract specific fields from results.
Descriptions contain repeated language-switching instructions ('IMPORTANT: Respond in the same language as the user's request...') that are not actionable tool parameters. This violates the pattern of putting operational constraints in parameter descriptions, not prose instructions. LLMs parse structured schemas, not prose directives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Get all categories available for a specific cloud provider. IMPORTANT: Respond in the same language as the user's request. If the user speaks Spanish, respond in Spanish. If the user speaks English, respond in English. This is STEP 2 of the recommended workflow. Use list_providers() first. Args: provider: Exact provider name (aws, azure, gcp, k8s, onprem, etc.) Returns: List of categories for the selected provider
List all available cloud providers and infrastructure platforms. IMPORTANT: Respond in the same language as the user's request. If the user speaks Spanish, respond in Spanish. If the user speaks English, respond in English. This is STEP 1 of the recommended workflow for creating diagrams with correct icons. Returns: Numbered list of all available providers
'create_diagram_from_json' accepts a free-form string 'diagram_spec' (JSON payload as string) instead of structured parameters (title, components, connections, clusters as separate inputs). This forces the LLM to construct and stringify JSON manually, increasing hallucination risk. Parameter should be typed object with subfields, not a string.
'create_multicloud_diagram' has the same issue: 'components' and 'connections' are free-form JSON strings, not structured arrays. The tool description shows example JSON but does not enforce schema for those fields, LLMs will hallucinate fields.
Parameter descriptions are minimal and lack actionable constraints. E.g., 'provider' is described as 'Exact provider name (aws, azure, gcp, k8s, onprem, etc.)', no enum constraint, no statement of what happens if invalid, no guidance on case sensitivity (although code shows .lower() is called).
Error messages in implementations reference tools the LLM should call (e.g., 'USE: list_providers()') but this guidance is not part of the tool schema, it's embedded in string responses. This is inconsistent with structured error classification and recovery patterns.
No pagination or result-limiting parameters. 'list_providers' and 'get_category_nodes' return full lists with no limit/offset. If a provider has thousands of nodes, the response could be huge, bloating the context window.