mcp-mermaidjs-to-image
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_supported_diagramsA | Returns the Mermaid.js engine version (v12.3.0) and the full catalog of all 37+ supported diagram types, keywords, aliases, and categories. Pointers guide the AI to query get_diagram_syntax_guide for deep syntax rules. |
| get_diagram_syntax_guideB | Returns authoritative syntax rules, keyword requirements, relationship connectors, common pitfalls, and verified working examples for a specific diagram type (e.g. "usecase-beta", "swimlane-beta", "sequenceDiagram", "architecture", "flowchart"). |
| render_mermaid_to_pngA | Renders Mermaid.js diagram syntax into a high-resolution PNG image. Requires an explicit diagram_type keyword (e.g. "usecase-beta", "swimlane-beta", "sequenceDiagram", "flowchart"). Rejects requests if diagram_type is missing or invalid, returning valid keyword feedback. |
| render_mermaid_fileB | Reads a local .mmd or .mermaid file, validates the mandatory diagram_type, renders it into a high-resolution PNG image, and writes the output file to disk. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The four tools split cleanly into two discovery tools (catalog vs. per-type syntax) and two rendering tools (inline source vs. file input), and each description states its input/output mode explicitly. render_mermaid_to_png vs. render_mermaid_file is the only near-pair, and the inline-vs-disk distinction is unambiguous.
All names follow a consistent verb_noun snake_case pattern (get_supported_diagrams, get_diagram_syntax_guide, render_mermaid_to_png, render_mermaid_file). The two get_ tools are discovery and the two render_ tools are execution, reinforcing the pattern semantically.
Four tools is well within a tight, focused scope for a single-purpose rendering server: two are needed because diagram syntax knowledge must be looked up before rendering, and two cover the two legitimate input modes. No tool looks redundant or missing at this size.
The lifecycle — discover supported types, fetch syntax rules, render from string or file — is covered end to end, with validation feedback on bad diagram_type. Minor gaps remain around output options (e.g. SVG/PDF or theme/size control) that agents could otherwise want, but the core workflow has no dead ends.