Loading ToolBench
Generate beautiful Excalidraw architecture diagrams with perfect auto-layout, stateful editing, and architecture-aware component styling. No API keys required.
Mixed quality across 26 tools. Strengths: most tools have descriptions (90%+), clear naming with action verbs, and coherent schema structures. Weaknesses: descriptions vary widely in detail (some are 40-50 chars, others 300+); output schemas are not formally documented in the visible code; many tools lack parameter type constraints (enums, ranges); error handling and recovery guidance are absent from descriptions. Knowledge graph tools (kg_*) are well-organized and properly scoped. Diagram tools (create_diagram, mermaid_to_excalidraw) have good descriptions but lack strict input validation hints.
Create a new Excalidraw diagram of any supported type. Two input modes: 1. **Graph types** (``architecture``, ``flowchart``) - pass ``nodes`` and ``connections``. The tool handles layout, styling, and rendering; no coordinates needed. 2. **Typed diagrams** (every other type) - pass ``diagram_type`` and a ``spec`` object shaped for that type. Call ``list_diagram_types`` to choose a type and ``get_diagram_schema`` to see its spec shape.
Export an .excalidraw file to SVG or PNG.
Read the current state of an Excalidraw diagram for LLM reasoning.
Get the spec schema for one diagram type.
Add or update a service in the knowledge graph.
Show how the architecture changed since a git ref.
Output schemas not formally documented. No tool description specifies the structure of returned data (fields, types, pagination). LLMs cannot reliably parse or chain results without explicit output documentation.
Parameter constraints missing. Enum values for 'theme' and 'format' are mentioned in descriptions (e.g., 'svg or png', 'default/dark/colorful') but not enforced as enums in the schema. LLMs may pass invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Generate Markdown documentation of the entire architecture.
Detect where the diagram diverges from the knowledge graph.
Export the knowledge graph to another format.
Import an existing .excalidraw diagram's services into the knowledge graph. Bootstraps the graph from diagrams you already created with this tool.
Summarize the whole knowledge graph: services, domains, and topology. Call this before mutating the graph to reason about current state.
Create a new architecture knowledge graph file (markdown). The knowledge graph is the persistent source of truth for your system's services and dependencies. Diagrams are rendered *from* it.
Add a directed dependency: ``from_id`` depends on / calls ``to_id``. Both services must already exist (add them with kg_add_service first). ``style`` is one of solid/dashed/dotted/thick.
Architecture health check: cycles, single points of failure, orphans, dangling references, and (optionally) unowned services.
Trace the shortest dependency path between two services.
Remove a service and all dependencies touching it.
Render the entire architecture to an .excalidraw file.
Render a service plus everything within ``depth`` hops of it. ``direction``: "downstream" (its dependencies), "upstream" (its dependents), or "both".
Render only the services belonging to one domain.
Render a focused diagram of just the given services (induced subgraph).
Assign a service to a domain (optionally set the domain's display label).
Remove the dependency ``from_id`` -> ``to_id``.
List every diagram type with when-to-use guidance.
Convert Mermaid flowchart syntax into an Excalidraw diagram. Supports the mermaid flowchart subset that AI agents commonly generate: - Directions: graph TD, LR, BT, RL - Node shapes: [text], {text}, ((text)), ([text]) - Edge types: -->, ---, -.-> ==> with |label| - Subgraphs: subgraph Title ... end Component types are auto-detected from node labels (e.g., a node labeled "PostgreSQL DB" automatically gets database styling).
Modify an existing Excalidraw diagram created by this tool. Supports iterative editing: add components, remove nodes, update labels, and rewire connections - without recreating the entire diagram. IMPORTANT: Call get_diagram_info first to understand the current diagram state before making modifications.
Impact analysis: what breaks if ``service_id`` fails? Reports direct dependents, the full transitive upstream blast radius, and what the service itself depends on.
Error handling and recovery guidance absent. Tools like kg_remove_service and kg_unlink (destructive operations) lack descriptions of failure modes or recovery steps. No guidance on what to do if a service is not found or if removal fails.
Terse descriptions on critical discovery tools. list_diagram_types returns '26 words', get_diagram_info returns '9 words', get_diagram_schema returns '11 words'. These fall below the 34-char minimum observed in production baselines and provide insufficient context for LLM selection.
No per-tool error handling or validation documentation. Parameters like 'service_id' in kg_remove_service and 'from_id'/'to_id' in kg_link lack guidance on what happens if the referenced service does not exist. LLMs will not know whether to retry, look up the ID, or ask the user.
modify_diagram 'operations' parameter is documented as array with inline type hints but lacks formal schema. Descriptions state it accepts 'add_node, remove_node, update_node, add_connection, remove_connection' but no enum or structured schema prevents malformed operations.
No idempotency guarantees documented. Tools like kg_add_service may be called multiple times by an agent (on retry). Descriptions should clarify: does calling kg_add_service twice with the same id overwrite or error? No guidance given.