Convert Mermaid JS graph definitions into native .drawio XML, making diagrams editable in Draw.io. Transform Mermaid code into a Draw.io file for direct editing.
Convert a Mermaid JS graph definition string into native .drawio XML.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes | ||
| mermaid_code | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v2.0.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the conversion action without revealing any side effects, error conditions, file handling (e.g., overwriting), or requirements for input validity. This is a minimal disclosure that leaves important behaviors unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, which is concise. However, it lacks structure or front-loading of key details; it is merely a statement of functionality. While concise, it doesn't organize information for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and a conversion task, the description is incomplete. It does not explain the expected format of mermaid_code, the behavior of output_path (e.g., overwriting), or any error handling. Given the many sibling tools, it also fails to provide context for selection. The presence of an output schema is not referenced, so the agent gets no help on return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the tool description must explain the parameters. The description mentions 'Mermaid JS graph definition string' and 'native .drawio XML' but does not explicitly map these to the two required parameters (mermaid_code and output_path). It implies that mermaid_code is the input string and output_path is the destination, but this is not explicit or detailed enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: converting a Mermaid JS graph definition string into native .drawio XML. This identifies the resource and result, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like generate_er_diagram or parse_diagram, though the conversion aspect is distinctive enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing valid Mermaid syntax, nor does it suggest scenarios where this tool is preferred over other diagram-related tools. The agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.