Enables generation of Kubernetes architecture diagrams including ingress, services, pods, and other Kubernetes infrastructure components as part of the diagrams library's 15+ supported providers.
Uses the Python diagrams library to generate infrastructure and architecture diagrams as code, supporting 500+ node types across multiple cloud and infrastructure providers.
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., "@Diagrams MCP Server Create an AWS 3-tier web app diagram with load balancer, EC2 instances, and RDS database"
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.
MCP server for generating infrastructure and architecture diagrams as code using the Python diagrams library.
5 Diagram Tools for infrastructure, architecture, and flowcharts:
Infrastructure Diagrams - 15+ providers (AWS, Azure, GCP, K8s, On-Prem, SaaS)
500+ Node Types - Compute, database, network, storage, security
Custom Icons - Web URLs (HTTPS) and local files
Flowcharts - 24 shapes for process diagrams
Validation - Dry-run before generation
Advanced Capabilities:
Multiple output formats (PNG, PDF, JPG, DOT)
Cluster grouping with unlimited nesting
Edge styling (colours, labels, line styles)
Graphviz attribute customisation
Related MCP server: diagrams-mcp
System Requirements:
Graphviz must be installed:
macOS: brew install graphviz
Ubuntu/Debian: sudo apt-get install graphviz
Windows: Download from https://graphviz.org/download/
Add to your claude_desktop_config.json:
For published package:
{
"mcpServers": {
"diagrams": {
"command": "uvx",
"args": ["diagrams-mcp"]
}
}
}For local development:
{
"mcpServers": {
"diagrams:local": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/diagrams-mcp",
"run",
"diagrams-mcp"
]
}
}
}Quick setup (CLI):
Published package:
claude mcp add --transport stdio math -- uvx diagrams-mcpLocal development:
claude mcp add --transport stdio math -- uvx --from /absolute/path/to/diagrams-mcp diagrams-mcpTeam setup (project-level):
Add .mcp.json to your project root:
{
"mcpServers": {
"diagrams": {
"command": "uvx",
"args": ["diagrams-mcp"]
}
}
}Verify installation:
claude mcp listOr check in IDE: View → MCP Servers, or use /mcp command.
Once installed, try these prompts:
"Create an AWS 3-tier web application diagram with Route53, ELB, EC2 instances, and RDS"
"Generate a Kubernetes microservices architecture with ingress, services, and pods"
"Build a flowchart for a CI/CD pipeline with decision points"
"Create a diagram using a custom icon from my company logo URL"
"Show me all available AWS compute nodes"
Map to tools: create_diagram, create_diagram_with_custom_icons, create_flowchart, list_available_nodes, validate_diagram_spec
All tool parameters and descriptions are available in your IDE's autocomplete.
Tool | Description |
| Full infrastructure/architecture diagrams with all providers |
| Diagrams with custom node icons from URLs or local files |
| Simplified flowchart creation with 24 process shapes |
Tool | Description |
| Search 500+ available nodes by provider, category, or keyword |
| Dry-run validation before generation |
HTTPS-only (HTTP rejected)
5MB file size limit
5-second download timeout
Image format validation (PNG, JPG)
Automatic caching (~/.diagrams_mcp/icon_cache)
Path validation (file must exist)
Format validation
Sandboxed execution
# Run all tests
uv run poe testSTDIO mode (for Claude Desktop integration):
uv run diagrams-mcpHTTP mode (for containerised deployments):
uv run diagrams-mcp-http --port 8000MIT License. See LICENSE file for details.
Contributions welcome via PRs! Please ensure:
Tests pass, and new ones are added if applicable
Code is linted & formatted
Type hints are included
Clear, actionable error messages are provided
For issues and questions, please open an issue on GitHub.
Generate infrastructure diagrams with 15+ providers (AWS, Azure, GCP, K8s, etc.).
Examples: AWS: nodes=[{"id":"r53","provider":"aws","category":"network","type":"Route53",...}] K8s: nodes=[{"id":"ing","provider":"k8s","category":"network","type":"Ingress",...}] Clusters: clusters=[{"name":"VPC","node_ids":["elb","ec2"],"graph_attr":{"bgcolor":"#E5F5FD"}}]
⚠️ CRITICAL: Node types must exist in diagrams library or diagram fails silently (no arrows). ALWAYS verify first: list_available_nodes(provider="aws", category="compute") For brands (Stripe, Vercel), use create_diagram_with_custom_icons instead.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Diagram title | |
| nodes | Yes | List of nodes to include | |
| connections | Yes | List of connections between nodes | |
| clusters | No | Optional clusters for grouping nodes | |
| direction | No | Diagram direction (LR=left-right, TB=top-bottom) | LR |
| curvestyle | No | Edge curve style | ortho |
| output_format | No | Output format(s): png, pdf, jpg, dot | png |
| output_dir | No | Output directory (default: current directory). Auto-created if missing. | |
| graph_attr | No | Graphviz graph attributes | |
| node_attr | No | Default node attributes | |
| edge_attr | No | Default edge attributes | |
| autolabel | No | Auto-prefix nodes with class names | |
| return_base64 | No | Include base64-encoded images |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations. Annotations indicate it's not read-only, is idempotent, and not destructive. The description warns of a critical behavior: 'diagram fails silently (no arrows)' if node types don't exist in the library, and advises verification with list_available_nodes. This disclosure of failure modes and prerequisites enhances transparency for safe usage.
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 efficiently structured: it starts with the core purpose, provides concrete examples, highlights critical warnings, and gives clear alternatives. Every sentence adds value—no redundancy or fluff. It's front-loaded with essential information and uses formatting (⚠️, ALWAYS) for emphasis without verbosity.
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 (13 parameters, creation operation), the description is complete. It covers purpose, usage guidelines, critical behaviors, and examples. With annotations covering safety (idempotent, non-destructive), 100% schema coverage, and an output schema (implied by context signals), no major gaps remain. It effectively complements structured data.
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 description coverage is 100%, so the schema fully documents all 13 parameters. The description adds minimal parameter semantics: it provides examples for nodes and clusters parameters (e.g., AWS and K8s node structures, cluster attributes), which helps illustrate usage but doesn't add new information beyond the schema. This meets the baseline for high schema coverage.
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's purpose: 'Generate infrastructure diagrams with 15+ providers (AWS, Azure, GCP, K8s, etc.)'. It specifies the verb ('Generate'), resource ('infrastructure diagrams'), and scope ('15+ providers'), distinguishing it from sibling tools like create_flowchart (likely for different diagram types) and create_diagram_with_custom_icons (for brands).
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 guidance: it tells when to use this tool (for infrastructure diagrams with standard providers) and when not to (for brands like Stripe, Vercel, use create_diagram_with_custom_icons instead). It also includes a prerequisite: 'ALWAYS verify first: list_available_nodes(provider="aws", category="compute")' to avoid silent failures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create diagrams with custom icons from web URLs or local files.
USE WHEN: Brand logos (Stripe, Vercel, Supabase, Fly.io) not in diagrams library. GitHub avatars work well: https://avatars.githubusercontent.com/u/{org_id}
Examples: URL: custom_nodes=[{"id":"stripe","icon_source":"url","icon_path":"https://avatars.githubusercontent.com/u/856813"}] Mixed: nodes=[{...AWS nodes...}], custom_nodes=[{...}], connections=[...]
HTTPS-only for URLs, 5MB limit, PNG/JPG supported. Automatic caching.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Diagram title | |
| custom_nodes | Yes | Custom nodes with icon URLs/paths | |
| connections | Yes | Connections between nodes | |
| nodes | No | Optional standard provider nodes to mix with custom | |
| clusters | No | Optional clusters | |
| direction | No | Layout direction | LR |
| curvestyle | No | Edge style | ortho |
| output_format | No | Output format(s): png, pdf, jpg, dot | png |
| output_dir | No | Output directory (default: current directory). Auto-created if missing. | |
| graph_attr | No | Graph attributes | |
| return_base64 | No | Return base64 images |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: HTTPS-only requirement, 5MB file limit, PNG/JPG support, and automatic caching. Annotations cover idempotency and non-destructive nature, but the description supplements with operational constraints, though it doesn't mention rate limits or authentication needs, keeping it from a perfect score.
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 well-structured with clear sections: purpose, usage guidelines, examples, and constraints. Each sentence adds value, such as the HTTPS-only note and caching info, with no redundant or verbose content. It's front-loaded with key information and efficiently organized.
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 (11 parameters, nested objects in schema) and the presence of an output schema, the description is complete. It covers purpose, usage, examples, and constraints, while annotations handle safety aspects. The output schema likely explains return values, so the description doesn't need to, making it sufficiently comprehensive for agent use.
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?
With 100% schema description coverage, the baseline is 3. The description provides examples for 'custom_nodes' and mentions mixing with standard nodes, adding some practical meaning. However, it doesn't detail other parameters like 'output_format' or 'graph_attr' beyond what the schema already explains, so it meets but doesn't exceed the baseline.
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 creates diagrams with custom icons from web URLs or local files, which is a specific verb+resource combination. It distinguishes from sibling tools like 'create_diagram' by emphasizing the custom icon capability, making the purpose unambiguous and differentiated.
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 includes an explicit 'USE WHEN' section that provides clear guidance: use for brand logos not in the diagrams library, with GitHub avatars as a good example. It distinguishes this tool from alternatives by specifying when custom icons are needed versus standard diagrams, offering practical context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create process flowcharts with 24 shapes (StartEnd, Process, Decision, etc.).
Example: steps=[{"id":"start","shape":"StartEnd","label":"Start"},...] flows=[{"from_step":"start","to_step":"check"},...]
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Flowchart title | |
| steps | Yes | Flowchart steps | |
| flows | Yes | Connections between steps | |
| direction | No | Layout direction | TB |
| output_format | No | Output format(s): png, pdf, jpg, dot | png |
| output_dir | No | Output directory (default: current directory). Auto-created if missing. | |
| graph_attr | No | Graphviz graph attributes (overrides defaults) | |
| return_base64 | No | Return base64 images |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive, idempotent write operation (readOnlyHint: false, destructiveHint: false, idempotentHint: true). The description adds minimal behavioral context beyond this - it mentions the 24 shape types and provides a brief example structure, but doesn't cover important aspects like error conditions, performance characteristics, or authentication 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?
The description is appropriately concise with two sentences and a brief example. The first sentence states the purpose, the second provides structural guidance. However, the example could be more complete to better illustrate parameter usage.
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 (8 parameters, nested object definitions), the description is somewhat minimal. While annotations cover safety aspects and there's an output schema, the description doesn't adequately address the tool's relationship to siblings or provide sufficient guidance for proper usage of the complex parameters beyond the basic example.
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?
With 100% schema description coverage, the schema already documents all 8 parameters thoroughly. The description provides a minimal example showing the structure of steps and flows arrays, which adds some semantic context about how these complex parameters should be structured, but doesn't significantly enhance understanding beyond what the schema provides.
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 creates process flowcharts and mentions the 24 available shapes, providing a specific verb (create) and resource (flowcharts). However, it doesn't explicitly differentiate from sibling tools like create_diagram or create_diagram_with_custom_icons, which likely have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. There are multiple sibling tools (create_diagram, create_diagram_with_custom_icons) that likely serve similar purposes, but the description offers no comparison or context for choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover 500+ node types across providers.
⚠️ USE THIS FIRST before create_diagram to avoid invalid node errors.
Filters: provider, category, search_term
Examples: AWS compute: provider="aws", category="compute" → EC2, Lambda, ECS, EKS... Search DBs: search_term="db" → RDS, DynamoDB, SQL across providers
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Filter by provider (aws, azure, gcp, etc.) | |
| category | No | Filter by category (compute, database, etc.) | |
| search_term | No | Search term for node type names | |
| limit | No | Maximum results to return |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations. While annotations already indicate read-only, idempotent, and non-destructive behavior, the description provides practical guidance about using this tool first to avoid errors with create_diagram. It also mentions the scale ('500+ node types') and gives filtering examples. No contradiction with annotations exists.
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 efficiently structured with zero wasted sentences. It opens with the core purpose, provides critical usage guidance, lists filter parameters, and gives concrete examples. Each sentence adds clear value. The bullet-point style for examples enhances readability without verbosity.
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 (discovering 500+ node types), the description provides complete context. With 100% schema coverage, comprehensive annotations, and an output schema (which means return values don't need description), the description focuses on what's missing: purpose, usage sequencing, and practical examples. It perfectly complements the structured data.
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 description coverage is 100%, so the schema already fully documents all four parameters. The description mentions the three filter parameters (provider, category, search_term) and provides examples, but doesn't add significant semantic meaning beyond what's in the schema. The limit parameter isn't mentioned in the description. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Discover 500+ node types across providers.' It specifies the verb 'discover' and resource 'node types,' and distinguishes from siblings by explicitly mentioning its relationship to create_diagram. The first sentence provides a complete, specific purpose statement.
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 guidance: 'USE THIS FIRST before create_diagram to avoid invalid node errors.' It names a specific sibling tool (create_diagram) and explains when to use this tool versus alternatives. The warning emoji reinforces the importance of this sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate diagram before generation (dry-run).
Checks: node validity, connection references, cluster memberships. Returns: {"valid": true/false, "errors": [...], "warnings": [...]}
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | Nodes to validate | |
| connections | Yes | Connections to validate | |
| clusters | No | Clusters to validate |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds valuable context about what specific checks are performed ('node validity, connection references, cluster memberships') and the exact return format. This goes beyond the safety profile provided by annotations and gives the agent concrete expectations about validation behavior.
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 extremely concise and well-structured: a clear purpose statement, specific validation checks listed, and exact return format specified - all in just three lines. Every sentence earns its place with zero wasted words, and the information is front-loaded effectively.
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 validation purpose, comprehensive annotations, 100% schema coverage, and explicit output format description, the description is complete enough. It provides the necessary context about what's validated, when to use it, and what to expect in return, making it fully functional for an AI agent to understand and invoke correctly.
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?
With 100% schema description coverage, the input schema already thoroughly documents all parameters (nodes, connections, clusters). The description doesn't add any additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate since the schema does the heavy lifting for parameter documentation.
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 specific action ('validate diagram before generation') and resource ('diagram'), distinguishing it from sibling tools like 'create_diagram' or 'list_available_nodes'. It explicitly mentions this is a 'dry-run' operation, which clarifies it's a validation check rather than actual generation.
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 guidance on when to use this tool: 'before generation' as a 'dry-run' validation step. This clearly positions it as a pre-check alternative to the sibling 'create_diagram' tools, helping the agent understand this should be used to validate specifications before attempting actual diagram creation.
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.
create_diagramcreate_diagram_with_custom_iconscreate_flowchartlist_available_nodesvalidate_diagram_specEach tool has a clearly distinct purpose: create_diagram for standard infrastructure diagrams, create_diagram_with_custom_icons for diagrams with custom icons, create_flowchart for process flowcharts, list_available_nodes for discovery, and validate_diagram_spec for validation. The descriptions explicitly differentiate when to use each tool, with clear boundaries between them.
All tool names follow a consistent verb_noun pattern with snake_case: create_diagram, create_diagram_with_custom_icons, create_flowchart, list_available_nodes, validate_diagram_spec. The naming is predictable and readable throughout the set.
With 5 tools, this server is well-scoped for diagram creation and management. Each tool earns its place by covering distinct aspects: diagram generation (2 tools), flowchart creation, node discovery, and validation. This count is appropriate for the domain without being too sparse or bloated.
The tool set covers the core diagram creation workflow comprehensively: discovery (list_available_nodes), validation (validate_diagram_spec), and generation for both infrastructure diagrams and flowcharts. A minor gap exists in lacking update or delete operations for existing diagrams, but agents can work around this by regenerating diagrams as needed.
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.
Render, validate, encode/decode PlantUML diagram-as-code; 22 diagram types. Free, no auth.
Create diagrams in chat, rendered as live interactive draw.io diagrams. 10,000+ searchable shapes.
Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/apetta/diagrams-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
