The Glyphic server is an MCP-compliant diagram generation tool that renders declarative JSON into visual diagrams, returned as inline images.
Tools Available
get_schema – Retrieve the full JSON schema so the AI knows all supported diagram types and fields.
render_diagram – Validate and render a JSON diagram definition, returning output as PNG, SVG, and/or React Flow JSON.
Supported Diagram Types
Flowchart / Architecture – Node-and-edge diagrams with shapes, icons, grouping, and flexible edge routing.
Sequence – Participant interaction diagrams with sync, async, and return message types.
ERD – Database schema diagrams with attributes, keys, and crow's-foot cardinality.
Class – UML class diagrams with attributes, methods, and relationship types.
State Machine – State transition diagrams with initial, final, and composite states.
Mindmap – Hierarchical idea maps with node shapes.
Gantt – Project timeline charts with sections, tasks, dependencies, and date formats.
Sankey – Flow/weight diagrams showing resource or data movement between nodes.
Git Graph – Branch and commit history visualizations.
C4 – Architecture context diagrams (person, system, container, boundary elements).
Pie Chart – Slice-based data charts with optional explode and legend.
Quadrant Chart – 2D scatter plots divided into four quadrants.
Timeline – Linear chronological event diagrams.
Journey Map – User journey diagrams with satisfaction scores per task.
Kanban – Board-style columns with cards, priorities, and assignees.
Treemap – Hierarchical area-proportional charts.
Canvas – Free-form SVG-based drawing with primitives (rect, circle, line, text, path, polygon, etc.).
Key Features
Export formats: PNG, SVG, and React Flow JSON.
Theming: named presets (light, dark, pastel, mono) or fully custom colors and fonts.
Visual style presets: compact, clean, minimal, sketch.
Layout directions (TB, BT, LR, RL) and edge routing (orthogonal, polyline, splines).
Files auto-saved to ~/Desktop/Glyphic Diagrams/ (configurable via GLYPHIC_OUTPUT_DIR or disabled with GLYPHIC_NO_SAVE).
Returns diagrams inline as base64 PNG even if local file saving fails or is disabled.
Schema validation before rendering ensures clean, actionable error messages.
Runs over stdio via npx — no global install required.
The official Model Context Protocol server for Glyphic. It lets MCP-capable clients — Claude Desktop, Cursor, and others — generate diagrams as a native tool: the model emits JSON, the tool renders it, and the image comes back inline.
The server runs over stdio via npx — no global install. Add this entry to
your client's MCP config:
{
"mcpServers": {
"glyphic": {
"command": "npx",
"args": ["-y", "@glyphicjs/mcp-server"]
}
}
}Most clients use exactly that; the difference is where the config lives and a couple of key names:
Client | Config location | Notes |
Claude Desktop |
| Fully quit (⌘Q) and reopen. |
Claude Code | — |
|
Cursor |
| Enable under Settings → MCP. |
VS Code |
| Top-level key is |
Windsurf |
| Reload servers from Cascade. |
Antigravity |
| Or Manage MCP Servers → View raw config. |
See the full MCP guide for the exact per-client JSON. Restart the client, then just ask:
"Draw an ERD for a blog: users, posts, and comments with the right relationships."
The model calls render_diagram, the diagram is saved locally, and the PNG is returned in the conversation.
Related MCP server: fcp-drawio
Tool | Description |
| Returns the full JSON Schema of a diagram input, so the model knows every supported type and field. |
| Validates the supplied |
By default, rendered files are written to ~/Desktop/Glyphic Diagrams/, named
<sanitized_title>_<timestamp>_<6-hex-chars>.png / .svg / .json, so the model
can tell the user exactly where to find them.
Two environment variables control this:
GLYPHIC_OUTPUT_DIR — overrides the output directory. Use an absolute
path — many MCP clients launch the server with cwd=/.
GLYPHIC_NO_SAVE — set to 1 or true to disable file saving entirely;
the tool still returns the diagram inline.
If writing to disk fails (e.g. a headless or read-only environment), the server logs a warning to stderr and still returns the diagram inline as base64 PNG — it never fails a render just because a file couldn't be saved. On startup, the server prints a short banner to stderr with its version, docs/issues links, and the resolved output directory.
Input is validated with @glyphicjs/schema before rendering — malformed model output comes back as a clean, fixable error rather than a crash, and error messages never leak stack traces.
Choose outputs with exportFormat in the diagram JSON, e.g. "exportFormat": ["png", "svg", "react-flow"] (defaults to ["png"]).
See the full MCP guide and the diagram types reference.
Sponsor: github.com/sponsors/MS-Teja
MIT
Returns the JSON schema of the DiagramInput payload to help the AI understand supported diagram types and properties.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states return of JSON schema, but doesn't disclose any behavioral traits (e.g., read-only, no side effects, auth requirements).
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?
Single sentence, 19 words, front-loaded with main action. Every word provides value; no unnecessary repetition.
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?
Given no output schema, description explains return value (JSON schema of DiagramInput) and purpose (supported types/properties). Sufficient for a simple tool, though more detail on structure could help.
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?
Zero parameters, baseline score of 4. Description adds context about the schema's purpose, but no parameter details needed.
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?
Clearly states verb 'returns', resource 'JSON schema of the DiagramInput payload', and purpose 'help the AI understand supported diagram types and properties'. Distinguishes from sibling 'render_diagram'.
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?
Implies use before calling render_diagram, but lacks explicit when-to-use or alternatives. No direct guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renders a declarative JSON diagram into a visual representation. The input MUST conform to the DiagramInput schema.
| Name | Required | Description | Default |
|---|---|---|---|
| diagram | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states it renders, without mentioning side effects, auth requirements, rate limits, or whether it is read-only. For a complex tool like this, more transparency on behavior is needed.
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 two sentences long with no unnecessary words. It front-loads the purpose and then states the constraint. Every sentence is essential.
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?
Given the complexity of the tool (multiple diagram types, many options), the description is too minimal. It does not mention supported diagram types, output formats, or any constraints beyond schema conformance. The schema itself is huge, but the description should provide a high-level overview to help the agent decide quickly.
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 single parameter 'diagram' is a complex object with extensive documentation in the input schema itself. The tool description adds value by referencing the 'DiagramInput schema', implying the agent must consult it. Since the schema already contains detailed descriptions for sub-properties, the description's semantic contribution is minimal but sufficient.
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 the tool renders a declarative JSON diagram into a visual representation, with a specific resource (diagram JSON) and action (render). It also mentions the input must conform to a schema, which distinguishes it from the sibling tool 'get_schema' that likely retrieves the schema.
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. The only sibling is 'get_schema', which serves a different purpose, but the description does not specify when to choose rendering over anything else. Lacks when-to-use or when-not-to information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_schemarender_diagramThe two tools have completely distinct purposes: one returns the JSON schema, the other renders a diagram. There is no overlap or ambiguity.
Both tool names follow the verb_noun pattern (get_schema, render_diagram), providing clear and consistent naming.
With only 2 tools, the server feels minimal but appropriate for a focused rendering service. It is slightly under what is typical, but not unreasonable.
The pair covers the core workflow: obtain the schema and then render a diagram. Missing validation or diagram management tools are minor gaps given the narrow scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Collaborative whiteboard MCP server — create objects, connectors, C4 diagrams, and manage boards
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
AI agent draws editable hand-drawn diagrams (flowchart, ER, architecture) via MCP, not static images
MCP Server for an Agent Task Marketplace
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MS-Teja/Glyphic'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
