GCP Diagram MCP Server
Provides enhanced GCP service icons for Google Maps Platform, enabling its inclusion in generated GCP architecture diagrams.
Provides enhanced GCP service icons for Looker, enabling its inclusion in generated GCP architecture diagrams.
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., "@GCP Diagram MCP ServerCreate a GCP architecture diagram for a web app with Cloud Run, Cloud SQL, and Load Balancer."
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.
GCP Diagram MCP Server
Model Context Protocol (MCP) server for GCP Diagrams
This MCP server that seamlessly creates diagrams using the Python diagrams package DSL. This server allows you to generate GCP diagrams, sequence diagrams, flow diagrams, and class diagrams using Python code.
Prerequisites
Install
uvfrom Astral or the GitHub READMEInstall Python using
uv python install 3.10Install GraphViz https://www.graphviz.org/
Related MCP server: arch7
Installation
Cursor | VS Code |
Configure the MCP server in your MCP client configuration (e.g., for Google AI Studio CLI, edit your MCP client config):
{
"mcpServers": {
"mclabs.gcp-diagram-mcp-server": {
"command": "uvx",
"args": ["mclabs.gcp-diagram-mcp-server"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"autoApprove": [],
"disabled": false
}
}
}or docker after a successful docker build -t mclabs/gcp-diagram-mcp-server .:
{
"mcpServers": {
"mclabs.gcp-diagram-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"--interactive",
"--env",
"FASTMCP_LOG_LEVEL=ERROR",
"mclabs/gcp-diagram-mcp-server:latest"
],
"env": {},
"disabled": false,
"autoApprove": []
}
}
}从本地源代码安装
如果你想从本地源代码安装和开发此 MCP 服务器,请按照以下步骤操作:
1. 克隆仓库
git clone <repository-url>
cd gcp-diagram-mcp-server2. 安装依赖
# 安装 uv(如果尚未安装)
curl -LsSf https://astral.sh/uv/install.sh | sh
# 安装 Python 和依赖
uv python install 3.10
uv sync3. 本地开发安装
# 以可编辑模式安装
uv pip install -e .
# 或者安装开发依赖
uv pip install -e ".[dev]"4. 配置 MCP 客户端
在你的 MCP 客户端配置中,使用本地安装的路径而不是 uvx:
{
"mcpServers": {
"gcp-diagram-mcp-server-local": {
"command": "uv",
"args": ["run", "--project", "/path/to/gcp-diagram-mcp-server", "mclabs.gcp_diagram_mcp_server"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"autoApprove": [],
"disabled": false
}
}
}或者,如果你已经将项目路径添加到 Python 路径中:
{
"mcpServers": {
"gcp-diagram-mcp-server-local": {
"command": "python",
"args": ["-m", "mclabs.gcp_diagram_mcp_server"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"PYTHONPATH": "/path/to/gcp-diagram-mcp-server"
},
"autoApprove": [],
"disabled": false
}
}
}5. 验证安装
运行测试以确保一切正常工作:
# 运行所有测试
./run_tests.sh
# 或者直接使用 pytest
uv run pytest -xvs tests/6. 热重载开发
在开发过程中,你可以使用以下命令直接运行服务器:
# 直接运行服务器
uv run python -m mclabs.gcp_diagram_mcp_server
# 或者使用调试模式
uv run python -m mclabs.gcp_diagram_mcp_server --debugFeatures
The Diagrams MCP Server provides the following capabilities:
Generate Diagrams: Create professional diagrams using Python code
Multiple Diagram Types: Support for GCP architecture, sequence diagrams, flow charts, class diagrams, and more
Enhanced GCP Icons: Access to 22+ additional GCP service icons not available in the standard diagrams package
Customization: Customize diagram appearance, layout, and styling
Security: Code scanning to ensure secure diagram generation
Enhanced GCP Icons
This server now includes a curated collection of enhanced GCP service icons that are automatically available when generating diagrams. These icons are implemented as Custom classes and provide access to the latest GCP services:
AI/ML Services:
Vertex AI, Vertex AI Agent Builder, Vertex AI Search
Dataplex, Analytics Hub, Data QnA
Looker, Looker Studio
Database & Integration:
Datastream, Database Migration Service
Cloud SQL (2nd Gen)
DevOps & CI/CD:
Cloud Deploy, Artifact Registry, Batch
Migrate to Containers, Infrastructure Manager
Network & CDN:
Cloud CDN (new shield), Network Topology
Security & Identity:
BeyondCorp Enterprise
Management & Operations:
Cost Management, Cloud Monitoring (new)
Maps & Geospatial:
Google Maps Platform
These enhanced icons are automatically loaded and can be used just like standard diagram icons:
with Diagram("AI/ML Pipeline", show=False):
# Enhanced icons - no import needed
vertex_ai = VertexAI("Vertex AI")
analytics_hub = AnalyticsHub("Analytics Hub")
dataplex = Dataplex("Data Lake")
# Standard icons
from diagrams.gcp.storage import Storage
storage = Storage("Data Source")
storage >> dataplex >> analytics_hub >> vertex_aiQuick Example
from diagrams import Diagram
from diagrams.gcp.compute import Functions
from diagrams.gcp.database import Firestore
from diagrams.gcp.network import LoadBalancing
with Diagram("Serverless Application", show=False):
lb = LoadBalancing("Load Balancer")
function = Functions("Cloud Function")
database = Firestore("Firestore")
lb >> function >> databaseDevelopment
Testing
The project includes a comprehensive test suite to ensure the functionality of the MCP server. The tests are organized by module and cover all aspects of the server's functionality.
To run the tests, use the provided script:
./run_tests.shThis script will automatically install pytest and its dependencies if they're not already installed.
Or run pytest directly (if you have pytest installed):
pytest -xvs tests/To run with coverage:
pytest --cov=mclabs.gcp_diagram_mcp_server --cov-report=term-missing tests/For more information about the tests, see the tests README.
Development Dependencies
To set up the development environment, install the development dependencies:
uv pip install -e ".[dev]"This will install the required dependencies for development, including pytest, pytest-asyncio, and pytest-cov.
Acknowledgments
This project is based on the excellent work from the AWS Labs MCP project. We are grateful to the AWS Labs team for creating the original AWS Diagram MCP Server, which served as the foundation for this GCP version.
Original Project
Original Repository: awslabs/mcp
Original Package:
awslabs.aws-diagram-mcp-serverLicense: Apache License 2.0
Special thanks to the AWS Labs team and all contributors to the original project for their innovative work in creating MCP servers for cloud architecture diagrams.
Available Tools
3 toolsgenerate_diagramA
Generate a diagram from Python code using the diagrams package.
This tool accepts Python code as a string that uses the diagrams package DSL and generates a PNG diagram without displaying it. The code is executed with show=False to prevent automatic display.
USAGE INSTRUCTIONS:
Never import. Start writing code immediately with with Diagram( and use the icons you found with list_icons.
First use get_diagram_examples to understand the syntax and capabilities
Then use list_icons to discover all available icons. These are the only icons you can work with.
You MUST use icon names exactly as they are in the list_icons response, case-sensitive.
Write your diagram code following python diagrams examples. Do not import any additional icons or packages, the runtime already imports everything needed.
Submit your code to this tool to generate the diagram
The tool returns the path to the generated PNG file
For complex diagrams, consider using Clusters to organize components
Diagrams should start with a user or end device on the left, with data flowing to the right.
CODE REQUIREMENTS:
Must include a Diagram() definition with appropriate parameters
Can use any of the supported diagram components (GCP, K8s, etc.)
Can include custom styling with Edge attributes (color, style)
Can use Cluster to group related components
Can use custom icons with the Custom class
COMMON PATTERNS:
Basic: provider.service("label")
Connections: service1 >> service2 >> service3
Grouping: with Cluster("name"): [components]
Styling: service1 >> Edge(color="red", style="dashed") >> service2
IMPORTANT FOR CLINE: Always send the current workspace directory when calling this tool! The workspace_dir parameter should be set to the directory where the user is currently working so that diagrams are saved to a location accessible to the user.
Supported diagram types:
GCP architecture diagrams
Sequence diagrams
Flow diagrams
Class diagrams
Kubernetes diagrams
On-premises diagrams
Custom diagrams with custom nodes
Returns: Dictionary with the path to the generated diagram and status information
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python code using the diagrams package DSL. The runtime already imports everything needed so you can start immediately using `with Diagram(` | |
| timeout | No | The timeout for diagram generation in seconds. Default is 90 seconds. | |
| filename | No | The filename to save the diagram to. If not provided, a random name will be generated. | |
| workspace_dir | No | The user's current workspace directory. CRITICAL: Client must always send the current workspace directory when calling this tool! If provided, diagrams will be saved to a 'generated-diagrams' subdirectory. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains execution details (show=False, runtime imports), return value (path to PNG), and code requirements. Minor gap: no mention of error handling or potential 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?
Well-structured with sections and bullet points; all content is relevant and front-loaded. Slightly long but justified by the complexity of the tool.
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?
Comprehensive coverage: explains prerequisites, code patterns, supported diagram types, return value, and all parameters. No output schema needed given the clear description of returned path and status.
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%, and the description adds significant context: code format, timeout default, filename generation, workspace_dir behavior (saves to 'generated-diagrams' subdirectory).
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 it generates a PNG diagram from Python code using the diagrams package. It distinguishes from sibling tools by referencing get_diagram_examples and list_icons as prerequisites.
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 explicit step-by-step usage instructions, including when to use this tool (after getting examples and listing icons), what not to do (never import), and important notes about the workspace_dir parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_diagram_examplesA
Get example code for different types of diagrams.
This tool provides ready-to-use example code for various diagram types. Use these examples to understand the syntax and capabilities of the diagrams package before creating your own custom diagrams.
USAGE INSTRUCTIONS:
Select the diagram type you're interested in (or 'all' to see all examples)
Study the returned examples to understand the structure and syntax
Use these examples as templates for your own diagrams
When ready, modify an example or write your own code and use generate_diagram
EXAMPLE CATEGORIES:
gcp: GCP cloud architecture diagrams (basic services, grouped workers, clustered web services, AI Platform)
sequence: Process and interaction flow diagrams
flow: Decision trees and workflow diagrams
class: Object relationship and inheritance diagrams
k8s: Kubernetes architecture diagrams
onprem: On-premises infrastructure diagrams
custom: Custom diagrams with custom icons
all: All available examples across categories
Each example demonstrates different features of the diagrams package:
Basic connections between components
Grouping with Clusters
Advanced styling with Edge attributes
Different layout directions
Multiple component instances
Custom icons and nodes
Parameters:diagram_type (str): Type of diagram example to return. Options: gcp, sequence, flow, class, k8s, onprem, custom, all
Returns: Dictionary with example code for the requested diagram type(s), organized by example name
| Name | Required | Description | Default |
|---|---|---|---|
| diagram_type | No | Type of diagram example to return. Options: gcp, sequence, flow, class, k8s, onprem, custom, all | all |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description bears full burden. It explains read-only nature by stating 'get example code' and details return type, though no explicit safety note.
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?
Structured with sections, front-loaded purpose, but slightly verbose with redundant explanatory sentences.
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 single-parameter tool with no output schema, the description thoroughly covers purpose, categories, usage, and examples, leaving minimal ambiguity.
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% but description adds extensive context: lists categories with examples and explains what each demonstrates, far beyond the enum list.
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 gets example code for diagram types, lists categories, and distinguishes from sibling tools 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?
Explicit step-by-step instructions are provided, along with when to use (learn syntax before creating) and an alternative tool link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_iconsA
List available icons from the diagrams package, with optional filtering.
This tool dynamically inspects the diagrams package to find available providers, services, and icons that can be used in diagrams.
USAGE INSTRUCTIONS:
Call without filters to get a list of available providers
Call with provider_filter to get all services and icons for that provider
Call with both provider_filter and service_filter to get icons for a specific service
Example workflow:
First call: list_icons() → Returns all available providers
Second call: list_icons(provider_filter="gcp") → Returns all GCP services and icons
Third call: list_icons(provider_filter="gcp", service_filter="compute") → Returns GCP compute icons
This approach is more efficient than loading all icons at once, especially when you only need icons from specific providers or services.
Returns: Dictionary with available providers, services, and icons organized hierarchically
| Name | Required | Description | Default |
|---|---|---|---|
| service_filter | No | Filter icons by service name (e.g., "compute", "database", "network", "analytics", "ml", "storage") | |
| provider_filter | No | Filter icons by provider name (e.g., "gcp", "k8s", "onprem", "saas") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains it dynamically inspects the package and returns a hierarchical dictionary. Could mention performance considerations but otherwise transparent for a read-only inspection tool.
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?
Well-structured with clear sections (description, usage instructions, example workflow, returns). Every sentence is informative. No fluff.
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?
Even without an output schema, the description explains the return structure (dictionary with providers, services, icons hierarchically). Covers all essential information for correct 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?
Schema coverage is 100% with concise descriptions. The description adds significant value by explaining the progressive filtering pattern and giving concrete examples of parameter values ("gcp", "compute").
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 it lists available icons from the diagrams package with optional filtering. It distinguishes from sibling tools (generate_diagram, get_diagram_examples) by focusing on icon discovery.
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 detailed step-by-step usage instructions with examples, including the progressive filtering workflow. Tells the agent when to call with no filters, with provider_filter, and with both filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose: listing icons, providing examples, and generating diagrams. No overlap in functionality, making it easy for an agent to select the right tool.
All tool names follow the verb_noun pattern in snake_case (generate_diagram, get_diagram_examples, list_icons), which is consistent and predictable.
With only 3 tools, the server is tightly scoped to its core mission: icon discovery, example learning, and diagram generation. This minimal set avoids unnecessary complexity.
The tool set covers the full workflow: discover icons, learn syntax via examples, and generate diagrams. There are no missing operations for the stated purpose of creating diagrams.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Generate org charts, MCD/ERD data models, and C4 architecture diagrams — pilot OrgGen AI via MCP.
Create and manage Mermaid.js flowcharts and diagrams with AI agents via MCP.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables users to generate professional AWS architecture diagrams, sequence diagrams, flow charts, and class diagrams using Python code through the diagrams package. Supports customizable styling and secure diagram generation for cloud infrastructure visualization.3Apache 2.0
- AlicenseAqualityDmaintenanceGenerates Excalidraw architecture diagrams with support for 60+ components including GCP, Kafka, and AI/Agentic shapes. Provides MCP tools for creating, modifying, and converting diagrams from structured input or Mermaid syntax.41MIT
- AlicenseNot gradedqualityDmaintenanceEnables generating cloud architecture diagrams, flowcharts, sequence diagrams, and more using three rendering engines: mingrammer/diagrams, Mermaid, and PlantUML.3MIT
- AlicenseNot gradedqualityDmaintenanceEnables generating GCP architecture, sequence, flow, and class diagrams using natural language or Python code via the diagrams library.1Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lesonky/gcp-diagrams-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server