Generates Mermaid diagram syntax from ArchiMate models for creating visual enterprise architecture diagrams that can be rendered and shared.
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., "@ArchiMate MCP Server create a business process diagram for customer onboarding"
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.
A Model Context Protocol (MCP) server that generates ArchiMate 3.2 enterprise architecture diagrams. This server enables AI assistants like Claude to create, validate, and visualize ArchiMate models through natural language interactions.
ArchiMate is an open standard for enterprise architecture modeling that provides a visual language for describing, analyzing, and communicating enterprise architectures. It covers business, application, technology, and implementation domains across multiple architectural layers.
Related MCP server: ArchiScribe MCP Server
Complete ArchiMate 3.2 Support: All 55+ element types across 7 architectural layers
Intelligent Validation: Ensures diagram compliance with ArchiMate 3.2 specification
Mermaid Diagram Generation: Creates beautiful, shareable diagrams
ArchiMate XML Export: Generates ArchiMate 3.0 Open Exchange Format XML
Case-Insensitive Operations: Flexible element and relationship naming
MCP Integration: Seamless integration with Claude Desktop and other MCP clients
Install the package globally to use as an MCP server:
npm install -g @null-pointer/mcp-archimateOr install locally in your project:
npm install @null-pointer/mcp-archimateStart the server directly:
npx -y @null-pointer/mcp-archimateOr if installed globally:
mcp-archimateNode.js (v16 or higher)
Locate your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the MCP server configuration:
{
"mcpServers": {
"archimate": {
"command": "npx",
"args": ["-y", "@null-pointer/mcp-archimate"]
}
}
}Or if installed globally:
{
"mcpServers": {
"archimate": {
"command": "mcp-archimate"
}
}
}Restart Claude Desktop to load the new MCP server
The MCP server provides four main tools:
generate_archimate_diagramCreates Mermaid diagrams from ArchiMate elements and relationships.
validate_archimate_modelValidates models against ArchiMate 3.2 specification rules.
list_archimate_elementsLists available element types, optionally filtered by layer.
list_archimate_relationshipsLists all available relationship types.
Prompt: "Create an ArchiMate diagram showing a customer ordering process with a customer actor, ordering process, and order management application"
Expected Output: A Mermaid diagram showing:
Business Actor (Customer)
Business Process (Ordering Process)
Application Component (Order Management System)
Appropriate relationships between them
Prompt: "Design an e-commerce application architecture with a web interface, API service, database, and payment gateway"
Expected Elements:
Application Interface (Web UI)
Application Service (API Service)
Data Object (Customer Data, Order Data)
Technology Service (Payment Gateway)
Node (Database Server)
Prompt: "Show me the technology infrastructure for a cloud-based system with load balancer, web servers, application servers, and database cluster"
Expected Elements:
Device (Load Balancer)
Node (Web Servers, App Servers)
Technology Service (Database Service)
Technology Collaboration (Cluster Communication)
Here are effective prompts to use with Claude when the MCP server is configured:
"What ArchiMate elements are available in the business layer?"
"Show me all the relationship types I can use"
"What's the difference between a business process and business function?""Create a basic ArchiMate diagram showing how users interact with a mobile app"
"Design a simple business process diagram for customer onboarding"
"Show me the technology stack for a typical web application""Create an ArchiMate model for a digital banking transformation showing business processes, applications, and technology infrastructure"
"Design an enterprise architecture diagram for a retail company showing customer journey, supporting applications, and underlying technology"
"Model a cloud migration scenario showing current on-premise architecture and target cloud architecture""Validate this ArchiMate model and tell me if there are any specification violations"
"Check if a business actor can have a realization relationship with an application service"
"What relationships are valid between a business process and application component?"Elements for describing stakeholder concerns, goals, and requirements
Stakeholder, Driver, Assessment, Goal, Outcome, Principle, Requirement, Constraint
Elements for strategic planning and capability modeling
Resource, Capability, Value Stream, Course of Action
Elements for business processes, actors, and services
Business Actor, Business Role, Business Collaboration, Business Interface, Business Process, Business Function, Business Interaction, Business Event, Business Service, Business Object, Contract, Representation, Product
Elements for application components and services
Application Component, Application Collaboration, Application Interface, Application Function, Application Interaction, Application Process, Application Event, Application Service, Data Object
Elements for technology infrastructure and platforms
Node, Device, System Software, Technology Collaboration, Technology Interface, Technology Function, Technology Process, Technology Interaction, Technology Event, Technology Service, Path, Communication Network, Artifact
Elements for physical facilities and equipment
Equipment, Facility, Distribution Network, Material
Elements for transformation planning
Work Package, Deliverable, Implementation Event, Plateau, Gap
ArchiMate defines several relationship categories:
Composition: Part-of relationships
Aggregation: Groups of elements
Assignment: Allocation of behavior/structure
Realization: Implementation relationships
Serving: Service provision
Access: Data/object access
Influence: Impact relationships
Triggering: Temporal/causal sequences
Flow: Information/material transfer
Specialization: Generalization/specialization
Association: Generic connections
Start Simple: Begin with core elements and add detail progressively
Use Proper Layers: Respect ArchiMate's layered architecture
Validate Early: Check relationships against the specification
Name Clearly: Use descriptive names for elements
Focus Purpose: Create diagrams with specific stakeholder viewpoints
Be Specific: Mention the domain (business, application, technology)
Provide Context: Describe the scenario or use case
Request Validation: Ask Claude to validate complex models
Iterate: Build diagrams incrementally with feedback
Layered View: Show relationships between business, application, and technology
Process Flow: Model business processes with supporting applications
Service Orientation: Focus on services and their relationships
Capability Mapping: Link business capabilities to supporting elements
npm run devnode test-mcp.jssrc/
├── core/ # Core ArchiMate element classes
├── generator/ # Diagram generation logic
├── models/ # Type definitions and enums
├── validator/ # ArchiMate specification validation
└── server.ts # MCP server implementationFork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
[Add your license information here]
For issues, questions, or contributions, please visit the project repository or contact the maintainers.
Export ArchiMate model as standard XML Open Exchange Format (.archimate)
| Name | Required | Description | Default |
|---|---|---|---|
| elements | Yes | Array of ArchiMate elements to export | |
| relationships | Yes | Array of relationships between elements | |
| options | No | Export options and metadata |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, what happens to the exported data, rate limits, or error conditions. The description is minimal and lacks essential context for a tool with complex parameters.
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 a single, efficient sentence that states the core function without unnecessary words. It's appropriately sized and front-loaded with the essential information, making it easy to parse quickly.
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 tool with 3 complex parameters (including nested arrays and objects), no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., file content, download link, status), error handling, or practical usage context. The minimal description leaves significant gaps given the tool's complexity.
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 documents all 3 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced 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 action ('Export') and resource ('ArchiMate model') with specific output format ('standard XML Open Exchange Format (.archimate)'). It distinguishes from siblings like 'generate_archimate_diagram' by focusing on export rather than diagram generation, but doesn't explicitly contrast with all siblings like 'list_archimate_elements'.
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 like 'generate_archimate_diagram' or 'validate_archimate_model'. The description implies usage for exporting models but doesn't specify prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ArchiMate diagrams in Mermaid or Draw.io format from elements and relationships
| Name | Required | Description | Default |
|---|---|---|---|
| elements | Yes | Array of ArchiMate elements | |
| relationships | Yes | Array of relationships between elements | |
| format | No | Output format for the diagram | mermaid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates diagrams but doesn't mention whether this is a read-only operation, if it modifies data, requires specific permissions, or has rate limits. For a tool with no annotations, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core action and key details (formats), with zero wasted words. It's appropriately sized for the tool's complexity, making it easy to parse quickly.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, or output specifics, leaving gaps that could hinder an agent's understanding despite the good schema coverage.
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 documents all parameters ('elements', 'relationships', 'format') with detailed descriptions. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or usage examples, but the high schema coverage justifies a baseline score of 3.
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 action ('Generate'), the resource ('ArchiMate diagrams'), and the output formats ('Mermaid or Draw.io format'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'export_archimate_xml' (which exports XML rather than diagrams) or 'list_archimate_elements' (which lists elements rather than generating diagrams), missing full sibling distinction.
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 like 'export_archimate_xml' or 'validate_archimate_model'. It lacks context on prerequisites (e.g., needing elements and relationships as input) or exclusions, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available ArchiMate 3.2 element types with their layers
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | Filter elements by specific layer (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects like whether this is a read-only operation, what format the output takes, whether it returns all elements at once or uses pagination, or any rate limits 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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the output looks like (e.g., list format, structure, whether it includes element properties beyond layers), which is critical for an agent to understand how to use the results. The description should compensate for the lack of structured output information.
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 input schema has 100% description coverage, with the single parameter 'layer' clearly documented as an optional filter with enumerated values. The description doesn't add any parameter information beyond what's in the schema, so the baseline score of 3 is appropriate when the 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 specific action ('List'), resource ('ArchiMate 3.2 element types'), and scope ('with their layers'). It distinguishes itself from sibling tools like 'list_archimate_relationships' by focusing on element types rather than relationships.
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 implies usage for retrieving element types with layer information, but provides no explicit guidance on when to use this tool versus alternatives like 'list_archimate_relationships' or 'validate_archimate_model'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available ArchiMate relationship types
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states it 'lists all available' types but doesn't disclose format, pagination, sorting, or any constraints. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized for a simple listing tool and front-loads the essential information.
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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'available' means (e.g., from a database, file, or API), the return format, or any behavioral traits. Given the lack of structured data, more context is needed for effective 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?
The tool has zero parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for zero parameters is 4, as the description appropriately doesn't waste space on non-existent parameters.
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 verb ('List') and resource ('ArchiMate relationship types'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_archimate_elements', which follows a similar pattern for a different resource type.
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. While the name implies it's for listing relationship types, there's no mention of prerequisites, typical use cases, or how it differs from other listing/exporting tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate ArchiMate elements and relationships against the ArchiMate 3.2 specification
| Name | Required | Description | Default |
|---|---|---|---|
| elements | Yes | Array of ArchiMate elements to validate | |
| relationships | Yes | Array of relationships to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states validation occurs 'against the ArchiMate 3.2 specification' but doesn't disclose what validation entails (e.g., syntax checks, semantic rules, error reporting), whether it's read-only (implied but not stated), or performance considerations (e.g., handling large arrays). This leaves significant gaps for a tool with two required parameters.
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 a single, efficient sentence that front-loads the core purpose without fluff. Every word contributes directly to understanding the tool's function (validate, ArchiMate elements/relationships, specification version). It avoids redundancy and is appropriately sized for the complexity.
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 validation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes valid/invalid input, how results are returned (e.g., error messages, status codes), or edge cases (e.g., empty arrays). Given the tool's potential complexity (validating architectural models), more context on behavior and outputs is needed for effective 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 description coverage is 100%, with clear descriptions for 'elements' and 'relationships' arrays. The description adds no additional parameter semantics beyond implying validation scope, but doesn't detail format expectations (e.g., valid 'type' values) or validation rules. Given high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
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 action ('validate') and target ('ArchiMate elements and relationships') with specific reference to the ArchiMate 3.2 specification. It distinguishes this from siblings like export, generate, and list tools by focusing on validation. However, it doesn't explicitly contrast with potential validation alternatives (e.g., schema-based vs. rule-based validation), keeping it from a perfect score.
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. It doesn't mention prerequisites (e.g., needing valid element/relationship data), exclusions (e.g., not for partial models), or compare with sibling tools like list_archimate_elements for checking existence. Usage is implied only through the tool name and description, lacking explicit context.
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.0export_archimate_xmlgenerate_archimate_diagramlist_archimate_elementslist_archimate_relationshipsvalidate_archimate_modelEach tool has a clearly distinct purpose with no overlap: exporting XML, generating diagrams, listing elements, listing relationships, and validating models. An agent can easily distinguish between these operations as they target different aspects of ArchiMate model management.
All tool names follow a consistent verb_noun pattern with 'archimate' as a common prefix (e.g., export_archimate_xml, list_archimate_elements). This predictable naming scheme makes the tool set easy to navigate and understand.
With 5 tools, this server is well-scoped for its purpose of ArchiMate model handling. Each tool earns its place by covering essential operations like export, diagram generation, listing, and validation, without being overly sparse or bloated.
The tool set covers key aspects of ArchiMate model interaction, including export, visualization, information retrieval, and validation. A minor gap exists in CRUD operations for creating or modifying models, but agents can likely work around this by using external tools or focusing on analysis and export tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and edit collaborative architecture diagrams with any AI assistant using the Trident 2D DSL.
Generate, edit, and export data-architecture diagrams from your AI. Column lineage, PNG in chat.
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
AI knowledge graph for architecture, portfolio, and digital strategy management.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RMRanjit/mcp-Archimate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
