Provides tools to commit and push model changes to a Git repository, enabling version control of ArchiMate models.
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., "@MCP ArchiMate Server Show me the API component"
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 for ArchiMate/CoArchi model interaction. Works with VS Code Copilot, Cursor, and other MCP-compatible clients.
MCP ArchiMate Server enables AI assistants to read and write ArchiMate models stored in CoArchi XML format. Query elements, create relationships, design diagrams, and sync changes to Git—all through natural language.
Repository: https://github.com/dqxorg/mcp-archimate
Related MCP server: ArchiScribe MCP Server
Read and search ArchiMate models (CoArchi XML format)
Create elements, relationships, and diagrams
Generate models from architecture documentation
Auto-add visual connections to diagrams
Commit and push changes to Git branches
Full ArchiMate 3.2 schema support
1. Install via npm:
npm install -g archimate-chloe-mcp2. Add to VS Code settings (Ctrl+, → click {} icon):
{
"mcp": {
"servers": {
"archimate": {
"command": "archimate-chloe-mcp",
"env": {
"ARCHIMATE_MODEL_PATH": "/path/to/your/archimate/model"
}
}
}
}
}3. Restart VS Code
mcp add archimate -- archimate-chloe-mcpgit clone https://github.com/dqxorg/mcp-archimate.git
cd mcp-archimate
npm installThen add to VS Code settings:
{
"mcp": {
"servers": {
"archimate": {
"command": "node",
"args": ["/path/to/mcp-archimate/server.js"],
"env": {
"ARCHIMATE_MODEL_PATH": "/path/to/your/archimate/model"
}
}
}
}
}Set the ARCHIMATE_MODEL_PATH environment variable to your CoArchi model directory:
# Linux/Mac
export ARCHIMATE_MODEL_PATH=~/Documents/Archi/models/my-architecture
# Windows
set ARCHIMATE_MODEL_PATH=C:\Users\chloe\Documents\Archi\models\my-architecturepython -m archimate_mcp.servernode server.jsAfter installation, use the archimate-chloe-mcp command:
{
"mcp": {
"servers": {
"archimate": {
"command": "archimate-chloe-mcp",
"env": {
"ARCHIMATE_MODEL_PATH": "/path/to/your/archimate/model"
}
}
}
}
}Set ARCHIMATE_MODEL_PATH to your CoArchi model folder (the one with model/business/, model/application/, etc.).
Restart VS Code after adding the configuration.
Ask Copilot:
"What's in my application layer?"
"Show me all elements"
If you get a response, the MCP server is connected.
Tool | Description |
| Get model statistics by layer and type |
| List elements in business/application/technology layer |
| Search elements by name |
| Get element details by ID |
| Check model for errors |
Tool | Description |
| Create a new element |
| Create a relationship between elements |
| Create a new diagram/view |
| Add element to existing diagram |
| Add visual connection line |
| Auto-add all connections |
| Generate model from markdown |
| Git commit and push |
Tool | Description |
| List all ArchiMate element types |
| List all relationship types |
User: What's in my application layer?
→ Returns all application components and functions
User: Show me the API component
→ Returns element details with relationships
User: Create a BusinessActor for Product Owner
→ Creates new element in business layer
User: Connect the API to the Database with AccessRelationship
→ Creates relationship between elements
User: Add all connections to the C1 diagram
→ Adds visual connection lines for all relationships
User: Design from C:/docs/architecture.md
→ Generates full model from markdown documentBusinessActor, BusinessRole, BusinessCollaboration, BusinessProcess, BusinessFunction, BusinessService, BusinessObject
ApplicationComponent, ApplicationFunction, ApplicationService, DataObject
Node, Device, SystemSoftware, TechnologyService, Artifact
Type | Use Case |
| Service provided to actor |
| Data/control flow |
| Read/write data |
| Actor assigned to element |
| Implementation of specification |
| Strong whole-part |
| Whole-part |
| Event trigger |
The server expects a CoArchi model structure:
model-repository/
└── your-model/
└── model/
├── business/ # Business layer elements
├── application/ # Application layer elements
├── technology/ # Technology layer elements
├── relations/ # All relationships
└── diagrams/ # Views and diagramsThe commit_and_push tool automatically:
Stages all changes
Commits with your message
Creates a new branch (archi/{user}-{date})
Pushes to origin
Model not loading?
Verify ARCHIMATE_MODEL_PATH is set correctly
Check model has proper folder structure (model/business/, model/application/, etc.)
Connections not visible in diagram?
Use add_connections_from_relationships tool
Press F5 in CoArchi to reload
Element not found?
Use search_elements to find the correct ID
Check if element exists in the model
MIT
Add to your VS Code settings (settings.json):
{
"mcpServers": {
"archimate": {
"command": "python",
"args": ["-m", "archimate_mcp.server"],
"env": {
"ARCHIMATE_MODEL_PATH": "C:\\path\\to\\your\\archimate\\model"
}
}
}
}Add to claude_desktop_config.json:
{
"mcpServers": {
"archimate": {
"command": "python",
"args": ["-m", "archimate_mcp.server"],
"env": {
"ARCHIMATE_MODEL_PATH": "/path/to/your/archimate/model"
}
}
}
}# Create virtual environment
python -m venv .venv
# Activate
source .venv/Scripts/activate # Linux/Mac
.venv\Scripts\activate # Windows
# Install dependencies
pip install fastmcp
# Run tests
python -c "import sys; sys.path.insert(0, '.'); from archimate_mcp.server import get_model; m = get_model(); print(m.get_summary())"MIT License
Commit changes and push to git branch
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | Commit message | |
| branch_name | No | Branch name (auto-generated if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the action but omits details like whether it stages files, handling of dirty working tree, conflict behavior, or authentication requirements, leaving 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?
A single, front-loaded sentence that efficiently conveys the tool's purpose. Every word is necessary with no filler.
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 simple git operation with two well-documented parameters and no output schema, the description is largely sufficient. Minor gaps exist (e.g., behavior with uncommitted changes) but do not severely impair understanding.
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 both parameters having clear descriptions ('Commit message' and 'Branch name'). The description adds no additional meaning beyond the schema, so baseline score 3 is appropriate.
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-resource combination ('Commit changes and push to git branch'). It distinguishes effectively from sibling tools, which are all about model/diagram creation, making the purpose unambiguous.
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 explicit guidance on when to use this tool versus alternatives. However, the sibling context strongly implies its use for git version control operations distinct from model editing, providing implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new diagram/view
| Name | Required | Description | Default |
|---|---|---|---|
| diagram_name | Yes | Name of the diagram | |
| element_ids | No | Element IDs to include |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Create', implying a mutation. No details about side effects, permissions, idempotency, or return behavior are disclosed.
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 short sentence, which is concise and front-loaded. However, it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and the need to understand the tool's behavior, the description is incomplete. It does not mention what the tool returns, any side effects, or how it integrates with other tools.
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 covers 100% of parameters with descriptions, so the description adds no extra meaning. Baseline score of 3 is appropriate.
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 'Create a new diagram/view' clearly states the action (create) and resource (diagram/view). However, it does not differentiate from sibling creation tools like create_element or create_relationship, nor clarify if 'diagram/view' is a single entity.
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 on when to use this tool versus alternatives. No context about prerequisites, constraints, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new ArchiMate element
| Name | Required | Description | Default |
|---|---|---|---|
| element_type | Yes | ArchiMate element type | |
| name | Yes | Element name | |
| documentation | No | Element documentation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the creation action without disclosing behavioral traits such as permission requirements, idempotency, or error handling (e.g., duplicate names).
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, front-loaded sentence with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description is insufficient for a creation tool. It does not mention return values, side effects, or relationships to sibling tools like get_element.
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 three parameters. The description adds no extra meaning beyond the schema, meeting the baseline for high 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 verb 'Create' and the resource 'ArchiMate element', distinguishing it from sibling tools like create_relationship and create_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 implies the tool is for creating elements but provides no explicit guidance on when to use it over alternatives like create_relationship or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new ArchiMate relationship between two elements
| Name | Required | Description | Default |
|---|---|---|---|
| relationship_type | Yes | Relationship type | |
| source_element_id | Yes | Source element ID | |
| target_element_id | Yes | Target element ID | |
| documentation | No | Relationship documentation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Create', implying a write operation, but provides no details on side effects, validation, or required permissions. The agent lacks critical behavioral context.
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, concise sentence that immediately conveys the action. However, it could be slightly more informative without becoming verbose.
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?
The tool is moderately complex with 4 parameters, no output schema, and no annotations. The description fails to mention whether source/target elements must exist, relationship type constraints, or success behavior, leaving significant gaps for an agent.
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 baseline is 3. The description adds no parameter-specific information beyond what the schema already provides (e.g., no explanation of relationship_type values or element ID format).
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 an ArchiMate relationship between two elements, using a specific verb and resource. This distinguishes it from sibling tools like create_element (creates elements) and list_relationship_types (lists types).
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 when-to-use or when-not-to-use guidance is provided. The description does not mention prerequisites such as element existence or relationship type validity, nor does it reference alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ArchiMate model from an architecture markdown document
| Name | Required | Description | Default |
|---|---|---|---|
| document_path | Yes | Path to architecture markdown file | |
| scope | No | Design scope |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description implies a generative action but does not disclose side effects (e.g., whether it overwrites an existing model, permissions needed, or output format). For a model generation tool, more transparency is expected.
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 sentence with no unnecessary words. It is concise and front-loaded, efficiently stating the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of generating a model from a document, the description lacks completeness. There is no output schema, and no mention of what happens to the existing model, file format requirements, or the difference between 'full' and 'outline' scope. More details would improve completeness.
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 parameter descriptions. The description does not add extra meaning beyond the schema, but since coverage is high, a baseline of 3 is appropriate.
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 'Generate ArchiMate model from an architecture markdown document', which is a specific verb (Generate) and resource (ArchiMate model). It distinguishes itself from sibling tools that focus on creating individual elements or diagrams.
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, nor any prerequisites or context. Given the variety of sibling tools, some indication of when to generate a model from a document vs. other actions would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific element by ID
| Name | Required | Description | Default |
|---|---|---|---|
| element_id | Yes | Element ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation but lacks details on return format or behavior beyond 'details'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with core purpose, no wasted words.
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?
Simple tool with one parameter, no output schema. Description adequately conveys purpose, though missing return details.
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 one parameter described as 'Element ID'. Description adds no further meaning 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?
The description clearly states the verb 'Get', resource 'element', and identifies by ID, distinguishing it from siblings like 'list_elements_by_layer' and 'search_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?
The description implies use when you have an element ID, but no explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of the ArchiMate model (element counts by layer and type)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it returns counts; doesn't mention side effects, idempotency, or that it is a read-only operation (implied but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the tool's purpose. No wasted words; every part of the description 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?
Despite no output schema, description provides essential info (counts by layer and type). However, lacks details on output structure or format, which would improve completeness.
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 in input schema (0 params), so baseline score of 4 applies. Description adds no param info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Verb is specific ('Get a summary'), resource is clearly identified ('ArchiMate model'), and description mentions what data is returned ('element counts by layer and type'). Differentiates from sibling tools like 'list_elements_by_layer' by being a summary rather than a listing, though not explicitly stated.
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 on when to use this tool versus alternatives like 'search_elements' or 'list_elements_by_layer'. Lacks prerequisites or context for optimal use.
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 element types
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only list operation, but does not explicitly confirm it's non-destructive or disclose any side effects, 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?
Single sentence, no wasted words. Front-loaded with verb and resource. Efficiently communicates purpose.
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 simple parameterless list operation, the description is somewhat complete but lacks detail about the output format (e.g., list of strings, objects) and how 'available' is defined. The presence of sibling tools provides context, but the description itself is minimal.
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?
Input schema has 0 parameters, so baseline is 4. The description adds meaning by specifying the scope ('all available ArchiMate element types'), which is not clear from the name alone.
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 ('List') and the resource ('all available ArchiMate element types'). It uses a specific verb and resource, distinguishing it from sibling tools like 'list_elements_by_layer' which lists actual elements, not types.
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 on when to use this tool versus alternatives. The description simply states what it does, without mentioning prerequisites, exclusions, or comparisons to sibling tools like 'list_relationship_types' or 'search_elements'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all elements in a specific layer
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | ArchiMate layer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only says 'list all elements' and does not describe the output format, pagination, ordering, or whether it returns full element details or just identifiers. This lacks transparency for a read operation.
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 short sentence without unnecessary words. While it could be enriched with more behavioral details, it is efficient and to the point, earning a high score for conciseness.
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 (one parameter, list operation) and lack of output schema, the description is minimally adequate but does not fully inform the agent about what the response will contain. A more complete description would mention the element attributes returned.
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 already provides a complete description of the only parameter 'layer' with enum values and a descriptive label. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 it lists all elements in a specific layer, which is a distinct action from siblings like get_element (single element) and create_element (write operation). The verb 'list' and resource 'elements' with scope 'by layer' is specific and unambiguous.
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 explicit guidance on when to use this tool vs alternatives like search_elements. While the purpose is clear, the description does not state that this tool specifically only filters by layer and may not support other filters, leaving the agent to infer usage context.
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?
No annotations are provided, so the description carries the full burden. It only states it lists types without disclosing side effects, permissions, or whether it is read-only. For a simple listing, this is insufficient but not misleading.
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, concise sentence with no wasted words. It is front-loaded and directly states the tool's function.
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 simple list tool with no parameters and no output schema, the description is adequate but minimal. It does not explain what constitutes a 'relationship type' or the format of the output, which could be incomplete for an agent without prior knowledge.
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?
There are zero parameters, and schema coverage is 100%. The description adds no parameter information beyond the schema, which is acceptable per the baseline guideline of 4 for zero-parameter 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 'List all available ArchiMate relationship types' has a clear verb ('List') and resource ('ArchiMate relationship types'), distinguishing it from sibling tools like list_available_element_types (which lists element types).
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 on when to use this tool versus alternatives (e.g., list_available_element_types or search_elements). The description does not mention contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search elements by name (case-insensitive)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions case-insensitivity but omits other behaviors (e.g., pagination, partial matching, or error handling). Adequate for a simple search but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with action and key detail. Excellent conciseness.
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 simple search tool with one parameter and clear purpose, the description is nearly complete. Could mention it returns matching elements, but not strictly required given low 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?
The schema provides base description for the 'query' parameter (100% coverage), and the tool description adds valuable context: case-insensitive name search. This justifies a score above 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 searches elements by name with case-insensitive matching, which distinguishes it from siblings like get_element (exact ID) and list_elements_by_layer.
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?
While the description implies use for name-based search, it lacks explicit guidance on when to use this tool over alternatives like get_element or list_elements_by_layer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the ArchiMate model for errors
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose what counts as errors, whether the tool modifies state, or what the output looks like. The full burden falls on the description, which is insufficient.
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?
One concise sentence with no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter details, the description lacks essential context such as what the validation entails and what the result format is.
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, so the description does not need to elaborate on them. The purpose statement adds meaning beyond the empty 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?
The description states a specific verb (Validate) and resource (ArchiMate model), clearly differentiating from sibling tools which focus on creation, retrieval, or diagramming.
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 on when to use this tool versus alternatives; no mention of prerequisites or when not to use it.
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.3commit_and_pushcreate_diagramcreate_elementcreate_relationshipdesign_from_documentget_elementget_model_summarylist_available_element_typeslist_elements_by_layerlist_relationship_typessearch_elementsvalidate_modelEach tool has a clearly distinct purpose: creating elements/relationships/diagrams, committing changes, generating models from documents, retrieving elements, listing types, searching, and validating. No ambiguity between tools.
All tool names follow a consistent verb_noun snake_case pattern (e.g., create_element, list_elements_by_layer, validate_model), making it easy to predict functionality.
With 12 tools, the set is well-scoped for an ArchiMate modeling server, covering creation, retrieval, listing, validation, and documentation generation without being excessive or insufficient.
The tool set covers core operations (create, read, search, validate) but lacks update and delete for elements and relationships, which is a minor gap for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Generate, edit, and export data-architecture diagrams from your AI. Column lineage, PNG in chat.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dqxorg/mcp-archimate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
