Generates draw.io XML diagrams that can be opened and edited in diagrams.net.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@drawx/mcp-server design a microservices checkout flow"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Generate draw.io diagrams and architecture designs from inside Claude, Cursor, or VS Code.
DrawX MCP is a Model Context Protocol server that gives your AI assistant three tools:
generate_diagram — one-shot: natural-language prompt → complete draw.io XML.
architect_design — from a brief, produce a High-Level Design diagram (optionally an LLD + design doc).
whoami — verify your API key + see remaining quota.
Behind the scenes it calls the DrawX public API, so output matches the DrawX web app exactly.
Node.js 18+
A DrawX API key — create one in DrawX → Settings → API keys. Keys start with drawx_live_. API access is a paid feature (bundled with the DrawX Pro plan).
Related MCP server: draw-io-mcp
npm install -g @drawx/mcp-serverOr, if your MCP client supports npx, no install is needed — reference npx @drawx/mcp-server directly.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"drawx": {
"command": "npx",
"args": ["-y", "@drawx/mcp-server"],
"env": {
"DRAWX_API_KEY": "drawx_live_..."
}
}
}
}Restart Claude Desktop. In a new chat, ask "Draw me a microservices checkout flow" — Claude will call generate_diagram and show the resulting XML.
Edit ~/.cursor/mcp.json:
{
"mcpServers": {
"drawx": {
"command": "npx",
"args": ["-y", "@drawx/mcp-server"],
"env": { "DRAWX_API_KEY": "drawx_live_..." }
}
}
}Add to your workspace or user settings.json:
{
"mcp": {
"servers": {
"drawx": {
"command": "npx",
"args": ["-y", "@drawx/mcp-server"],
"env": { "DRAWX_API_KEY": "drawx_live_..." }
}
}
}
}Variable | Required | Purpose |
| yes | Your DrawX API key ( |
| no | Override the API base URL (default |
generate_diagramTurn a description into draw.io XML.
Inputs
prompt (string, required) — what to draw.
mode — "flash" (default), "pro", or "ultra". Trades speed for quality.
previousXml — an existing mxfile to modify.
Output — assistant text: a summary line (model, tokens, cost) followed by the full <mxfile>...</mxfile> XML in a fenced code block. Paste the XML into diagrams.net or save as .drawio.
architect_designRun the DrawX Architect Co-Pilot on a brief. Streams intermediate progress; returns a JSON payload with hld (and optional lld, doc).
Inputs
brief (string, required, ≥ 20 chars) — what to design.
depth — "hld", "hld_lld" (default), or "hld_lld_doc".
style — "cloud_agnostic" (default), "aws", "azure", or "gcp".
mode — "flash" (default), "pro", or "ultra".
whoamiNo inputs. Returns your email, plan, API tier, and remaining monthly API quota.
API usage is metered on a separate tier from your in-app usage. Pro subscribers get 200 API calls / month. The rate limit is 60 requests / minute. On the free plan, API access is not enabled — upgrade at getdrawx.com.
git clone https://github.com/SaharshPamecha/drawx-mcp-server
cd drawx-mcp-server
npm install
npm run build
DRAWX_API_KEY=drawx_live_... node dist/index.js # runs over stdio; use an MCP inspector
npm testMIT © 2026 DrawX
Run the DrawX Architect Co-Pilot: from a brief, produce a High-Level Design diagram (optionally a Low-Level Design and a written design document). Returns the diagram XML and rationale. Best for 'design me an architecture for X' requests.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Quality/speed tier. Default flash. | |
| brief | Yes | The architecture brief / requirements. | |
| depth | No | How deep to go. Default hld_lld. | |
| style | No | Cloud/icon style. Default cloud_agnostic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions outputs (diagram XML and rationale) but does not disclose safety aspects, side effects, authentication needs, or whether the tool is read-only. This is insufficient for a tool with no annotations.
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, front-loading the core action and followed by a use case. No superfluous words; every sentence adds value.
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 tool's complexity (4 parameters, no output schema), the description explains the primary output and scope. It lacks details on return format or error handling, but for a design tool with schema-enriched parameters, it is largely complete.
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?
Schema coverage is 100%, so the baseline is 3. The description adds context that the brief is central and that depth controls output types, but it does not provide additional meaning beyond what the schema already offers for each parameter.
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 produces a High-Level Design diagram from a brief, optionally including Low-Level Design and a written document. It explicitly targets 'design me an architecture for X' requests, distinguishing it from siblings like generate_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?
The description provides explicit context for when to use the tool ('Best for design me an architecture for X requests'). However, it does not mention when not to use it or suggest alternatives, though siblings are listed in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a draw.io (diagrams.net) diagram from a natural-language description. Returns complete mxfile XML you can save as a .drawio file or paste into diagrams.net. Pass previousXml to modify an existing diagram.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Quality/speed tier. Default flash. | |
| prompt | Yes | What to draw, in plain language. | |
| previousXml | No | Existing mxfile XML to modify (full updated document is returned). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions return type and modify capability, but lacks detail on destructiveness, rate limits, auth needs, or any side effects.
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?
Two sentences, front-loaded with key info, no fluff. Efficient and clear.
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?
Explains output format (mxfile XML) and modify scenario, which compensates for missing output schema. Lacks some behavioral context, but overall covers essential usage.
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?
Schema coverage is 100%, with each parameter described. Description adds minimal extra value (e.g., 'pass previousXml to modify'), but does not significantly extend understanding beyond schema.
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?
Description clearly states verb (generate), resource (draw.io diagram), and output format (mxfile XML). Distinguishes from sibling tools like 'architect_design' and 'whoami' which are unrelated.
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?
Provides guidance for modifying existing diagrams via previousXml. Lacks explicit when-not-to-use or alternatives, but context is clear for its intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the DrawX account tied to the configured API key, its plan, API tier, and remaining monthly API quota. Useful to confirm the key works before generating.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the output: account, plan, tier, quota. No side effects are mentioned, but for a read-only query tool, this is sufficient.
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?
Two sentences, front-loaded with action, no redundancy. Every sentence adds value.
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 tool's simplicity (no params, no output schema), the description fully covers purpose and usage context. It is complete for its scope.
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?
No parameters exist (0 params), so schema coverage is 100%. The description adds no parameter info, but baseline is 4 for 0-param tools.
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 identifies the tool's purpose: showing the DrawX account, plan, API tier, and quota. It distinguishes itself from siblings (generate_diagram, architect_design) by being a diagnostic tool.
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?
The description provides explicit usage context: useful to confirm the key works before generating. It does not explicitly mention when not to use or alternatives, but the context is clear.
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.
v0.1.1architect_designgenerate_diagramwhoamiThe tools 'generate_diagram' and 'architect_design' both generate diagrams but serve distinct purposes: general diagram creation vs. architectural design with documentation. 'whoami' is unrelated. Descriptions clearly differentiate the two diagram tools, though some overlap remains for architecture diagram requests.
Tool names are all lowercase with underscores, but patterns differ: 'generate_diagram' (verb_noun), 'architect_design' (noun_noun or unusual verb_noun), and 'whoami' (standalone command). The mix of conventions makes the set less predictable.
With 3 tools, the surface is minimal but well-scoped for the server's purpose of generating diagrams from natural language. Each tool serves a core function: general generation, architectural design with documentation, and account verification. No tool feels redundant or missing.
The server covers diagram generation and modification (via previousXml) and includes architectural design with written output. It lacks tools for listing, deleting, or converting diagrams, which is acceptable given the focus on generation. Minor gap in retrieving non-XML outputs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Let Claude, Cursor, or ChatGPT author Mermaid diagrams your team can read and share.
Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.
Create and edit collaborative architecture diagrams with any AI assistant using the Trident 2D DSL.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SaharshPamecha/drawx-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
