What can you do with this server?

The AI Diagram Maker MCP Server generates professional software engineering diagrams from various inputs directly within AI agents like Cursor or Claude. * Natural language to diagrams — Describe your system, flow, or architecture in plain English to create flowcharts, sequence diagrams, ERDs, system/network architecture, UML, mindmaps, or workflows * JSON to diagrams — Visualize API responses, database schemas, config files, or any structured JSON data * ASCII art to diagrams — Convert text-based ASCII art (box-drawing characters, arrows, etc.) into polished visuals * Images to diagrams — Turn whiteboard photos, screenshots, or hand-drawn sketches (via public URL or base64 data URI) into clean diagrams * Mermaid to D2 diagrams — Convert Mermaid definitions (flowchart, sequenceDiagram, erDiagram, etc.) into D2 format rendered as PNG images * Inline rendering — Diagrams appear directly in the chat interface via MCP Apps UI, no downloads needed * Browser editing — Every generated diagram includes a URL to view and edit it in your browser * Customizable output — Add styling/layout instructions via a prompt parameter; optionally include icons * Flexible deployment — Works via stdio (local) or HTTP/Streamable HTTP (remote), compatible with Cursor, Claude Desktop, and Claude Code * Requires an API key — An AI Diagram Maker account and API key are needed for operation

Which integrations are available for this server?

Provides the capability to convert Mermaid diagram definitions into polished PNG images and D2-based visualizations. Supports the generation of Unified Modeling Language (UML) diagrams to represent software architecture and design from text, JSON, or images.

AI Diagram Maker MCP Server

by erajasekar

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

AI Diagram Maker MCP Server

MCP server for AI Diagram Maker — generate beautiful software engineering diagrams directly inside Cursor, Claude Desktop, Claude Code, or any MCP-compatible AI agent.

ai-diagram-maker-mcp 🌐 ☁️ - Generate professional software diagrams from plain English descriptions.

Features

5 tools covering every input type: natural language text, code, ASCII diagram, images, and Mermaid
Inline rendering — diagrams appear directly in the chat using MCP Apps UI, no downloads
Diagram URL in responses — open it in your browser to view and edit the diagram
5 diagram types: flowchart, sequence, ERD, system architecture, UML
Supports both stdio (local) and HTTP/Streamable HTTP (remote) transports

Related MCP server: obscuraai-mcp

Prerequisites

Node.js 18+
An AI Diagram Maker account and API key

Hosted MCP server

The public MCP endpoint is https://mcp.aidiagrammaker.com/mcp (Streamable HTTP). Nothing to install for this option.

Authentication (HTTP)

For remote HTTP clients, send your API key on every request — not via environment variables:

X-ADM-API-Key: <your_api_key> (recommended), or
Authorization: Bearer <your_api_key>

Use the API key from your AI Diagram Maker account (see Prerequisites).

Remote server JSON example

Merge this into your client’s MCP config (replace the API key placeholder):

{
  "mcpServers": {
    "ai-diagram-maker": {
      "url": "https://mcp.aidiagrammaker.com/mcp",
      "headers": {
        "X-ADM-API-Key": "YOUR_API_KEY"
      }
    }
  }
}

Installation

Option A — hosted server (recommended)

Use the remote server JSON example above and wire it into your client using MCP client configuration. No global install.

Option B — run locally with npx

Nothing to install permanently — npx runs the package on demand. The package name is ai-diagram-maker-mcp; append @latest if you want every invocation to resolve the newest release (recommended for one-off runs and claude mcp add).

ADM_API_KEY=your_api_key npx ai-diagram-maker-mcp@latest

MCP client configuration

Cursor

Remote (recommended)

Add to ~/.cursor/mcp.json or Settings → MCP using the remote server JSON example. No environment variables are required for this setup.

Local (stdio)

{
  "mcpServers": {
    "ai-diagram-maker": {
      "command": "npx",
      "args": ["-y", "ai-diagram-maker-mcp@latest"],
      "env": {
        "ADM_API_KEY": "your_api_key_here"
      }
    }
  }
}

Optional: add "ADM_DEBUG": "1" to env for debug logging — see Environment variables.

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "ai-diagram-maker": {
      "command": "npx",
      "args": ["-y", "ai-diagram-maker-mcp@latest"],
      "env": {
        "ADM_API_KEY": "your_api_key_here"
      }
    }
  }
}

Claude Code

macOS

claude mcp add ai-diagram-maker -t stdio -e ADM_API_KEY=<api_key> -- npx -y ai-diagram-maker-mcp@latest

Windows

claude mcp add ai-diagram-maker \
  --command "npx" \
  --args "-y,ai-diagram-maker-mcp@latest" \
  --env ADM_API_KEY=your_api_key_here

HTTP transport (local or self-hosted)

To run an HTTP server yourself (same header-based auth as Authentication (HTTP)):

npx ai-diagram-maker-mcp@latest --transport http

The server listens on $PORT or 3001. Point clients at /mcp and send the API key with each request using the headers above.

Environment variables

Variable	Required	Default	Description
`ADM_API_KEY`	Yes (stdio only)	—	Your AI Diagram Maker API key (stdio transport only; remote HTTP clients use headers — see Authentication (HTTP))
`ADM_BASE_URL`	No	`https://app.aidiagrammaker.com`	Override for local/staging API; also used as the base for diagram URLs in tool responses
`ADM_DEBUG`	No	—	Set to `1`, `true`, or `yes` to log request parameters from the AI agent and the payload sent to the AI Diagram Maker API. Logs go to stderr. In Cursor, open Output, choose the MCP or ai-diagram-maker channel to read the server logs.

Tools

`generate_diagram_from_text`

Generate a diagram from a natural language description.

Parameter	Type	Required	Description
`content`	string	Yes	Natural language description of the diagram
`diagramType`	enum	No	flowchart, sequence, erd, system_architecture, uml
`prompt`	string	No	Additional styling/layout instruction

Example prompts:

"Create a microservices architecture with API gateway, auth service, user service, and PostgreSQL database"
"Draw a sequence diagram for user login flow with JWT token generation"
"adm show the CI/CD pipeline for a Next.js app deployed to Vercel"

`generate_diagram_from_json`

Convert a JSON structure into a diagram (great for API responses, database schemas, config files).

Parameter	Type	Required	Description
`content`	string	Yes	JSON string to visualise
`prompt`	string	No	How to interpret the JSON
`diagramType`	enum	No	Preferred diagram type

`generate_diagram_from_ascii`

Convert ASCII art into a polished diagram.

Parameter	Type	Required	Description
`content`	string	Yes	Raw ASCII art diagram
`prompt`	string	No	Rendering instructions
`diagramType`	enum	No	Preferred diagram type

`generate_diagram_from_image`

Convert a whiteboard photo, screenshot, or any image into a clean diagram.

Parameter	Type	Required	Description
`content`	string	Yes	Public image URL or base64 data URI
`prompt`	string	No	What to extract or how to render
`diagramType`	enum	No	Preferred output diagram type

`generate_diagram_from_mermaid`

Convert a Mermaid diagram definition to D2 and return a PNG image.

Parameter	Type	Required	Description
`content`	string	Yes	Mermaid diagram source (e.g. flowchart, sequenceDiagram, erDiagram)
`prompt`	string	No	Optional layout or styling instruction
`diagramType`	enum	No	Preferred diagram type for the converted output

Trigger keywords

The AI agent will automatically select the right tool when you use phrases like:

adm ...
ai diagram maker ...
create a diagram of ...
show me a flowchart / sequence diagram / ERD / architecture ...
visualise / draw / diagram ...

Local developer setup

Use these steps to clone the repo, build locally, and run the MCP server with Node.

1. Clone the repository

git clone https://github.com/erajasekar/ai-diagram-maker-mcp.git
cd ai-diagram-maker-mcp

2. Install dependencies

npm install

3. (Optional) Regenerate API client

If you change the AI Diagram Maker OpenAPI spec or config, regenerate the client:

npm run generate

4. Build

npm run build

This compiles TypeScript and builds the MCP app UI into dist/. The server entrypoint is dist/index.js.

5. Run the local MCP server

stdio (default) — for use with Cursor, Claude Desktop, etc.:

ADM_API_KEY=your_api_key node dist/index.js

Or use the npm script:

ADM_API_KEY=your_api_key npm start

HTTP transport — for remote clients or testing (same headers as Authentication (HTTP)):

ADM_API_KEY=your_api_key node dist/index.js --transport http

Or:

ADM_API_KEY=your_api_key npm run start:http

The HTTP server listens on $PORT (default 3001).

6. Use the local server in Cursor

Point Cursor at your built server via Settings → MCP (or ~/.cursor/mcp.json):

{
  "mcpServers": {
    "ai-diagram-maker": {
      "command": "node",
      "args": ["/absolute/path/to/ai-diagram-maker-mcp/dist/index.js"],
      "env": {
        "ADM_API_KEY": "your_api_key_here"
      }
    }
  }
}

Replace /absolute/path/to/ai-diagram-maker-mcp with the actual path to your cloned repo. After changing the config, restart Cursor or reload the MCP servers.

For debug logging, add "ADM_DEBUG": "1" to env — see Environment variables.

License

MIT

Available Tools

5 tools

generate_diagram_from_asciiA

Convert an ASCII art diagram into a polished visual diagram. Use this tool when the user has an existing ASCII art representation of a system, flow, or architecture and wants it rendered as a proper diagram. Accepts box-drawing characters, arrow representations (-->, ==>), and plain text layouts. Returns a link to view and edit the generated diagram in the browser.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Raw ASCII art diagram to convert into a polished visual diagram. Include the full ASCII art as-is, with box-drawing characters, arrows, or plain text layout. Example: +--------+ +--------+ \| Client \| --> \| Server \| +--------+ +--------+
`prompt`	No	Additional instruction for rendering. Example: "Use a dark theme and add icons"
`diagramType`	No	Preferred diagram type. Leave blank to let the AI infer from the ASCII layout.
`isIconEnabled`	No	Set to true when the user asks to include icons in the diagram.

TDQS

A4.4/5.0

Behavior4/5

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 effectively describes what the tool does (converts ASCII art to visual diagrams), specifies acceptable input formats (box-drawing characters, arrow representations, plain text layouts), and explains the output behavior (returns a link to view and edit). It doesn't mention potential limitations like size constraints or error conditions, but covers the core behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured with three sentences that each serve distinct purposes: stating the core function, specifying usage context, and explaining input/output behavior. There's no wasted language, and it's front-loaded with the most important information about what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 provides good coverage of the tool's behavior, usage context, and input expectations. It explains what the tool returns (a link) which compensates for the missing output schema. The main gap is lack of information about potential constraints or error conditions, but overall it's quite complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'box-drawing characters, arrow representations (-->, ==>), and plain text layouts' which aligns with the content parameter example, but doesn't provide additional context for other parameters. This meets the baseline expectation when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('convert', 'rendered') and resource ('ASCII art diagram'), and distinguishes it from siblings by specifying it's for ASCII art input rather than image, JSON, Mermaid, or text inputs. The phrase 'polished visual diagram' adds specificity beyond just conversion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('when the user has an existing ASCII art representation') and implicitly distinguishes it from sibling tools by specifying ASCII art input. It provides clear context for usage without needing to name alternatives directly, as the sibling tool names make the differentiation obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_diagram_from_imageA

Convert an image (whiteboard photo, screenshot, hand-drawn sketch) into a clean diagram. Use this tool when the user provides an image URL or base64-encoded image and wants it converted to a proper software engineering diagram. Accepts public image URLs or base64 data URIs (data:image/...;base64,...). Returns a link to view and edit the generated diagram in the browser.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Either a public image URL or a base64 data URI of the image to convert. Supported formats: JPEG, PNG, GIF, WebP. For a URL: 'https://example.com/whiteboard.png'. For a data URI: 'data:image/png;base64,iVBORw0KGgo...'
`prompt`	No	Instruction describing what to extract or how to render the diagram. Example: "Convert this whiteboard photo into a clean sequence diagram"
`diagramType`	No	Preferred output diagram type. Leave blank to let the AI decide based on the image content.
`isIconEnabled`	No	Set to true when the user asks to include icons in the diagram.

TDQS

A4/5.0

Behavior3/5

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 describes the input formats (public URLs or base64 data URIs), supported image formats (JPEG, PNG, GIF, WebP), and the return value (link to view and edit the diagram). However, it doesn't mention potential limitations like file size constraints, processing time, authentication requirements, or error conditions, which would be valuable for a tool performing complex image conversion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured in three sentences: the core functionality, when to use it, and what it returns. Every sentence adds value without redundancy. It's appropriately sized and front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the tool's purpose, usage context, input formats, and return value. The main gap is the lack of behavioral details about limitations or error handling, which would be helpful given the complexity of image-to-diagram conversion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 thoroughly. The description adds some context by mentioning 'public image URLs or base64 data URIs' and 'software engineering diagram,' but doesn't provide additional parameter semantics beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Convert an image... into a clean diagram.' It specifies the input types (whiteboard photo, screenshot, hand-drawn sketch) and output (software engineering diagram), and distinguishes it from sibling tools by focusing on image input rather than ASCII, JSON, Mermaid, or text inputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'when the user provides an image URL or base64-encoded image and wants it converted to a proper software engineering diagram.' However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools by name, which would be needed for a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_diagram_from_jsonA

Generate a diagram from a JSON structure. Use this tool when the user wants to visualise JSON data such as API responses, database schemas, dependency trees, configuration files, or any structured data. Pass the raw JSON string as content. Returns a link to view and edit the generated diagram in the browser.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	A JSON string representing the structure to visualise. This can be API response data, a database schema, a config file, dependency tree, or any other structured JSON. Example: '{"users": [{"id": 1, "orders": [{"id": 101}]}]}'
`prompt`	No	Instruction for how to interpret or render the JSON. Example: "Show as an entity relationship diagram with cardinality labels"
`diagramType`	No	Preferred diagram type. Defaults to 'erd' for schemas and 'flowchart' for other JSON.
`isIconEnabled`	No	Set to true when the user asks to include icons in the diagram.

TDQS

A4.2/5.0

Behavior3/5

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 mentions that the tool returns 'a link to view and edit the generated diagram in the browser,' which is useful output information. However, it lacks details on potential limitations (e.g., JSON size constraints), error handling, or performance characteristics that would be helpful for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured in two sentences: the first states the purpose and usage context, and the second covers the key parameter and return value. Every sentence adds essential information without redundancy, making it easy to parse and front-loaded with critical details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, 100% schema coverage, and no output schema, the description is reasonably complete. It covers the tool's purpose, usage context, main parameter, and return value. However, it could be more comprehensive by addressing potential behavioral aspects like error cases or limitations, given the lack of annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 thoroughly. The description adds minimal value beyond the schema by mentioning the 'content' parameter in context, but it doesn't provide additional semantic insights or usage examples for parameters like 'prompt' or 'diagramType' that aren't already in the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Generate a diagram from a JSON structure') and distinguishes it from sibling tools by specifying the input type (JSON) rather than ASCII, image, Mermaid, or text. It provides concrete examples of use cases like API responses and database schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'when the user wants to visualise JSON data such as API responses, database schemas, dependency trees, configuration files, or any structured data.' This clearly differentiates it from sibling tools that handle other input formats, providing direct guidance on appropriate contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_diagram_from_mermaidA

Convert a Mermaid diagram definition into a D2 diagram and return a PNG image. Use this tool when the user has existing Mermaid code (flowchart, sequenceDiagram, erDiagram, etc.) and wants it converted to D2 or rendered as an image. Pass the Mermaid source as content. Returns a link to view and edit the generated diagram in the browser.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	A Mermaid diagram definition to convert to D2. Pass the raw Mermaid source (e.g. flowchart, sequenceDiagram, erDiagram). Example: "flowchart LR A --> B --> C"
`prompt`	No	Optional instruction for layout or styling of the converted diagram.
`diagramType`	No	Preferred diagram type for the converted D2 output.
`isIconEnabled`	No	Set to true when the user asks to include icons in the diagram.

TDQS

A4.2/5.0

Behavior3/5

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 describes the core transformation behavior (Mermaid to D2 conversion with PNG output) and mentions the return format ('Returns a link to view and edit the generated diagram in the browser'), but doesn't cover important aspects like error handling, performance characteristics, authentication needs, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with three focused sentences: purpose statement, usage guidance, and return value explanation. Every sentence earns its place with no wasted words, and the most critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a transformation tool with no annotations and no output schema, the description does well by explaining the core behavior, usage context, and return format. However, it could be more complete by addressing potential limitations, error scenarios, or transformation constraints given the complexity of diagram conversion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 mentions the 'content' parameter ('Pass the Mermaid source as content') but doesn't add significant semantic value beyond what's already documented in the comprehensive schema descriptions for all four parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Convert a Mermaid diagram definition into a D2 diagram and return a PNG image'), identifies the resource ('Mermaid diagram definition'), and distinguishes it from sibling tools by specifying it's for Mermaid code conversion rather than ASCII, image, JSON, or text inputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('when the user has existing Mermaid code... and wants it converted to D2 or rendered as an image'), provides clear context about the input type, and implicitly distinguishes from sibling tools by specifying Mermaid-specific usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_diagram_from_textA

Generate a software engineering diagram from a natural language description. Use this tool when: the user asks to 'create a diagram', 'show me a flowchart', 'visualise the architecture', uses the keyword 'adm' or 'ai diagram maker', or asks for any visual representation of code, systems, processes or data flows. Supported diagram types: flowchart, sequence, ERD, system architecture, network architecture, UML, mindmap, workflow. Returns a link to view and edit the generated diagram in the browser.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Natural language description of the diagram to generate. Be descriptive — include components, relationships, data flows, etc. Example: "Create a microservices architecture with API gateway, auth service, user service, and PostgreSQL database"
`diagramType`	No	Preferred diagram type. Leave blank to let the AI infer the best type from your description.
`prompt`	No	Additional styling or layout instruction. Example: "Use left-to-right layout with pastel colors"
`isIconEnabled`	No	Set to true when the user asks to include icons in the diagram.

TDQS

A4.3/5.0

Behavior4/5

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 effectively describes the tool's behavior: it generates diagrams from text, supports specific diagram types, and returns a link to view/edit the diagram. It could improve by mentioning potential limitations like generation time or accuracy, but it covers core functionality well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by usage guidelines and return information. It avoids unnecessary repetition, though it could be slightly more concise by integrating the diagram type list more smoothly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 provides good context: it explains what the tool does, when to use it, supported diagram types, and the return format (a link). It could be more complete by detailing error cases or output specifics, but it covers essential aspects adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 thoroughly. The description adds minimal parameter semantics beyond the schema, only implying that 'content' should be descriptive natural language. 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('generate') and resource ('software engineering diagram from a natural language description'). It distinguishes itself from siblings by specifying the input source (natural language) rather than ASCII, image, JSON, or Mermaid formats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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, listing specific user requests ('create a diagram', 'show me a flowchart'), keywords ('adm' or 'ai diagram maker'), and contexts (visual representation of code, systems, processes, or data flows). It implicitly distinguishes from siblings by focusing on natural language input.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv3.0.4Mar 19, 2026
- First observedgenerate_diagram_from_ascii
- First observedgenerate_diagram_from_image
- First observedgenerate_diagram_from_json
- First observedgenerate_diagram_from_mermaid
- First observedgenerate_diagram_from_text

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose based on the input format: ASCII art, images, JSON, Mermaid code, or natural language text. The descriptions explicitly differentiate when to use each tool, with no overlap in functionality. An agent can easily select the appropriate tool based on the input type provided.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'generate_diagram_from_' as the prefix, followed by the specific input source (ascii, image, json, mermaid, text). This creates a predictable and readable naming convention throughout the tool set, making it easy for agents to understand the pattern.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of generating diagrams from various input formats. Each tool covers a distinct input type, and the count is neither too sparse nor overwhelming. This number allows comprehensive coverage without unnecessary complexity for the domain of diagram generation.

Completeness5/5

The tool set provides complete coverage for the server's purpose of generating diagrams from diverse input sources. It supports ASCII art, images, JSON, Mermaid code, and natural language text, covering all common ways users might want to create diagrams. There are no obvious gaps in the input formats supported, ensuring agents can handle a wide range of user requests.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
simceptorOAuth
io.github.ayda212
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
API Testing Testing & QA Tools
2
Apuchat A
io.github.opcastil11
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Communication Agent Orchestration
181
MiroOAuth
io.github.miroapp
Official Miro MCP server - Supports context to code and creating diagrams, docs, and data tables.
Software Architecture App Automation Workplace & Productivity
2151

Related MCP Servers

AI Charts
Software Architecture Developer Tools App Automation
tjameswilliams
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI assistants to programmatically create and manage flowcharts, ERDs, and swimlane diagrams. It provides tools for manipulating diagram structures, performing auto-layouts, and exporting to Mermaid or Markdown formats.
Updated 6 months ago (2026-03-15 21:46 UTC)
12
MIT
obscuraai-mcp
Autonomous Agents App Automation Workplace & Productivity
madeinphantom
A
license
B
quality
D
maintenance
MCP server for Claude, ChatGPT, coding agents (cursor, claude code etc), windsurf, etc— generate visual AI automation workflows. Describe a business process, get an interactive flow map you can edit and share.
Updated 5 months ago (2026-04-10 11:39 UTC)
1
64
MIT
mcp-media-engine
Multimedia Processing AI & Machine Learning
Tr1ckyMag1ca1
A
license
A
quality
B
maintenance
MCP server for AI-powered image, audio, and video generation, enabling media creation directly from Claude, Cursor, and other MCP clients.
Updated 2 months ago (2026-07-14 15:20 UTC)
11
64
MIT
gemini-diagram-mcp
Data Visualization AI & Machine Learning
arunsanna
A
license
A
quality
D
maintenance
MCP server for generating diagrams, charts, and visualizations using Gemini image generation on Vertex AI. Supports auto-detection of diagram types, multiple style modes, and iterative refinement.
Updated 3 months ago (2026-05-27 22:37 UTC)
3
14
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/erajasekar/ai-diagram-maker-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

AI Diagram Maker MCP Server

Features

Contents

Prerequisites

Hosted MCP server

Authentication (HTTP)

Remote server JSON example

Installation

Option A — hosted server (recommended)

Option B — run locally with npx

MCP client configuration

Cursor

Remote (recommended)

Local (stdio)

Claude Desktop

Claude Code

macOS

Windows

HTTP transport (local or self-hosted)

Environment variables

Tools

generate_diagram_from_text

generate_diagram_from_json

generate_diagram_from_ascii

generate_diagram_from_image

generate_diagram_from_mermaid

Trigger keywords

Local developer setup

1. Clone the repository

2. Install dependencies

3. (Optional) Regenerate API client

4. Build

5. Run the local MCP server

6. Use the local server in Cursor

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`generate_diagram_from_text`

`generate_diagram_from_json`

`generate_diagram_from_ascii`

`generate_diagram_from_image`

`generate_diagram_from_mermaid`