Which integrations are available for this server?

Provides tools to create, update, and analyze Mermaid diagrams stored on diagramzu.ai.

DiagramZu

Overview Schema Source Related Servers Score Discussions Admin

@diagramzu/mcp

MCP server for diagramzu.ai. Lets Claude Code, Claude Desktop, Cursor, Windsurf, ChatGPT custom GPTs, and any MCP client read and write Mermaid diagrams in your Space.

You author diagrams by talking to your AI — it stores them at diagramzu.ai/d/<id>, where your team can read and share them.

Available in the official MCP Registry as ai.diagramzu/mcp.

1. Get a token

Sign up at diagramzu.ai, then create an API token at diagramzu.ai/app/settings/tokens. Tokens look like dz_live_… and are scoped to one Space — no separate space-id needed.

Related MCP server: AI Diagram Maker MCP Server

2. Connect your client

The hosted server is the easy path: no install, no build. Just paste a config.

Claude Code

claude mcp add --scope user --transport http diagramzu https://mcp.diagramzu.ai/mcp \
  --header "Authorization: Bearer dz_live_xxx"

Claude Desktop, Cursor, Windsurf, Cline

Add to your client's MCP config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS for Claude Desktop, ~/.cursor/mcp.json for Cursor, etc.):

{
  "mcpServers": {
    "diagramzu": {
      "type": "http",
      "url": "https://mcp.diagramzu.ai/mcp",
      "headers": { "Authorization": "Bearer dz_live_xxx" }
    }
  }
}

ChatGPT custom GPT (Actions)

In the GPT builder, add an MCP server action pointing to https://mcp.diagramzu.ai/mcp with a Bearer-token authentication header set to your dz_live_… token.

Local stdio (for clients that don't speak remote MCP)

npx -y @diagramzu/mcp

with environment:

DIAGRAMZU_BASE_URL=https://diagramzu.ai
DIAGRAMZU_API_TOKEN=dz_live_xxx
DIAGRAMZU_SPACE_ID=<your space id>

Most users should prefer the remote HTTP transport above — the stdio path exists for clients without HTTP MCP support.

Tools

Tool	Description
`list_diagrams`	List diagrams in the Space (filter with `q`, sort by `updated` / `created`)
`list_folders`	List folders in the Space
`get_diagram`	Fetch one diagram by id (returns title + Mermaid source)
`create_diagram`	Create a new diagram (returns the share URL)
`update_diagram`	Update title and/or Mermaid source of an existing diagram
`analyze_diagram`	Get a structural summary of a diagram (nodes, edges, density)
`list_versions`	List version history for a diagram
`get_version`	Fetch a specific historical version of a diagram

Show off your setup

If you publish your MCP / Claude Code config in a dotfiles or example repo, drop this in the README so the next person knows where the diagrams come from:

[![MCP: diagramzu](https://diagramzu.ai/badge/mcp.svg)](https://diagramzu.ai)

Renders as a small shields-style badge — gray MCP + indigo diagramzu.

Local development (this repo)

For hacking on diagramzu itself, build from source:

cd packages/mcp-diagramzu
pnpm install
pnpm run build
# point your client at: node dist/index.js
# with DIAGRAMZU_BASE_URL / DIAGRAMZU_API_TOKEN / DIAGRAMZU_SPACE_ID

License

MIT

Available Tools

14 tools

add_commentAInspect

Post a comment on a diagram. Pass nodeId to pin it to a specific node, or parentId to reply to an existing top-level comment (threads are one level deep). The author is the API token's owner. Use this to leave structured review findings a human will see on the diagram.

ParametersJSON Schema

Name	Required	Description
`diagramId`	Yes	Diagram UUID
`body`	Yes	Comment text (1–5000 chars)
`nodeId`	No	Pin to this node id (top-level comments only)
`parentId`	No	Reply to this top-level comment id

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that the author is the API token's owner (auth implication) and that threads are one level deep (behavioral constraint). No output schema or annotations, so description carries behavioral burden; could mention return value, but adequate.

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?

Two efficient sentences covering action, parameters, auth, and usage. No unnecessary words, all sentences add value. Front-loaded with key information.

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?

Given no output schema or annotations, description covers purpose, parameters, auth, and use case. Lacks mention of return value or error conditions, but sufficient for a simple comment creation tool.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions already cover parameters well (100% coverage). Description adds nuance by explaining nodeId vs parentId distinction and thread depth, providing extra meaning beyond schema.

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 'Post a comment on a diagram' with specific verb and resource. It distinguishes from siblings like list_comments and create_diagram by detailing node vs. parent parameters and threading behavior.

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?

Provides context for when to use ('leave structured review findings') and notes threading depth. Does not explicitly list when not to use or alternatives, but effectively implies using list_comments for reading.

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

analyze_diagramAInspect

Analyze a stored flowchart diagram's structure (nodes, edges, subgraphs) and return actionable findings — orphan nodes, over-connected hubs, cycles, disconnected clusters, and grouping suggestions. Flowchart diagrams only. Set postAsComments: true to also persist each finding as a comment on the diagram (node-pinned where the finding names a single node) so a human reviewer sees them on the diagram surface.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Diagram UUID
`postAsComments`	No	If true, persist each finding as a comment on the diagram instead of only returning ephemeral prose.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Clearly discloses that findings are returned and that setting postAsComments: true persists them as comments on the diagram, including node-pinning behavior.

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?

Two concise sentences. First states purpose and output, second explains optional flag. No superfluous text.

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?

No output schema, but description lists types of findings. Could elaborate on exact return format, but overall sufficient for a tool with two parameters.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds meaningful context for postAsComments, explaining its side effect beyond the schema description.

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?

Clearly describes the tool's purpose: analyzing a stored flowchart diagram's structure and returning specific actionable findings (orphan nodes, hubs, cycles, etc.). Distinguishes from sibling tools like get_diagram or update_diagram.

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?

States that it is for flowchart diagrams only, providing clear context. Does not explicitly mention when not to use or alternatives, but the specificity is sufficient.

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

create_deckAInspect

Create a presentation deck from existing diagrams. Pass slides as the complete ordered list of diagram ids — the deck plays them as a slideshow in that order. Typical flow: create_diagram for each slide, collect the returned ids, then create_deck with those ids in presentation order. Returns the deck id and the present URL to share. Diagram ids must already exist in this Space (use list_diagrams to find them).

ParametersJSON Schema

Name	Required	Description
`title`	No	Deck title shown in the deck list and above the presentation.
`description`	No	Optional one-line summary of what the deck covers (≤1000 chars).
`slides`	No	Ordered list of existing diagram UUIDs. The deck plays them in this exact order. A diagram may appear at most once. Omit or pass [] to create an empty deck.

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 full burden. It discloses that diagrams must already exist, that slides is an ordered list, and that the return includes deck id and present URL. It could mention error handling for invalid ids, but is otherwise transparent.

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 four sentences, front-loaded with purpose. Each sentence adds value: purpose, parameter clarification, typical flow, and prerequisite. No wasted words.

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 simple creation tool without output schema, the description covers purpose, usage flow, constraints (diagrams must exist), and return value. Minor missing details like error cases, but overall complete enough.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are described in the schema (100% coverage). The description adds extra meaning: 'slides' is clarified as 'complete ordered list' and the sequence of playing as slideshow. This adds value beyond the schema.

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 'Create a presentation deck from existing diagrams' with a specific verb and resource. It distinguishes from sibling tools like create_diagram and update_deck by focusing on assembling existing diagrams into a deck.

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 outlines a typical flow (create_diagram then create_deck) and advises using list_diagrams to find existing diagram ids. It does not explicitly state when not to use, but the context is clear.

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

create_diagramCInspect

Create a new diagram in the Space. Returns its id and shareable URL. See this server's instructions for diagram-type selection and class role names (edge/core/data/accent/muted) for color-grouping.

ParametersJSON Schema

Name	Required	Description
`title`	No	Display name
`code`	No	Mermaid source. Defaults to a tiny flowchart.
`style`	No	Visual preset: midnight (default dark), paper, forest, ocean, mono. Omit to use the default.
`styleOptions`	No	Optional layout knobs, independent of the color preset. Each key is optional; omit any to keep its default. Pass layout: 'auto' to let the server pick a concrete layout based on the diagram's shape.
`description`	No	Overall purpose of the diagram (≤1000 chars). Shown to share-link viewers and surfaced back to the agent as the diagram's brief — write this before generating the code.
`folderId`	No	Optional UUID of an existing folder to place the diagram in. Use list_folders first to find the right folder by name (e.g. 'Infra', 'Schemas'). Omit to place at the space root.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full responsibility. It mentions return values but omits important behavioral traits such as permissions, rate limits, or side effects of creation.

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?

Short and front-loaded with the main purpose. However, the second sentence about server instructions is somewhat vague and could be more direct.

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

Completeness3/5

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

The description partially covers return values but lacks details on error scenarios, success conditions, or constraints. Given the complexity (6 params, nested objects, no output schema), more context would improve completeness.

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. The description adds minimal extra meaning beyond hinting at server instructions for diagram-type selection, resulting in a baseline score.

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

Purpose4/5

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

The description clearly states 'Create a new diagram in the Space' and mentions the return values (id and shareable URL). It is specific about the action and resource but does not explicitly differentiate from sibling tools like update_diagram.

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

Usage Guidelines2/5

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

No direct guidance on when to use this tool versus alternatives like update_diagram. The description references 'server instructions' for advanced features but does not provide concrete usage context or exclusions.

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

get_deckAInspect

Fetch one deck by id. Returns its title, description, and the ordered list of slides (each slide is a diagram id + title in presentation order).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Deck UUID

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It clearly indicates a read-only operation and discloses return fields. However, it omits details on error handling (e.g., behavior on non-existent id) and permissions.

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?

Two sentences, no wasted words, front-loaded with verb and resource, achieving maximum conciseness for the information conveyed.

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?

Despite lacking an output schema, the description lists return fields adequately. However, missing details on optional behavior (e.g., if deck not found) make it not fully complete.

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 coverage is 100% and the description's mention of 'by id' adds no new meaning beyond the schema's 'Deck UUID'. Baseline 3 is appropriate as no extra semantics are needed.

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 action ('fetch one deck by id') and the specific resource, and distinguishes from siblings by specifying the return fields (title, description, ordered slides).

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

Usage Guidelines3/5

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

The description implies when to use (to get a single deck with slides) but provides no explicit guidance on when not to use or alternatives, relying on sibling names for differentiation.

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

get_diagramAInspect

Fetch one diagram by id. Returns its title, description (the agent's brief), mermaid source code, and a shareable URL. Read the description before editing — it tells you what the diagram is for and when to update it.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Diagram UUID

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description handles transparency. It discloses the fetch nature and return fields, plus hints that the description field guides editing decisions. Does not cover error behavior or auth, but adequate for a simple read.

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?

Two sentences with no wasted words. First sentence states purpose and output; second provides actionable guidance. Efficient and well-structured.

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?

Given the tool's simplicity (1 param, no output schema), the description covers purpose, return values, and a usage tip. It could mention missing ID behavior, but remains largely complete.

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 coverage is 100% with a single parameter 'id' described as 'Diagram UUID'. The description adds no extra meaning beyond that, so baseline score of 3 applies.

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 it fetches one diagram by ID and lists the returned fields (title, description, mermaid source code, shareable URL), distinguishing it from sibling tools like list_diagrams (multiple) 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.

Usage Guidelines4/5

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

Advises to read the description before editing, providing clear context for use. However, it lacks explicit when-not-to-use guidance or alternatives beyond the implied context.

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

get_versionAInspect

Fetch one snapshot by id. Returns its title, mermaid source code, and metadata. Read-only — restore is human-only in the UI.

ParametersJSON Schema

Name	Required	Description	Default
`diagramId`	Yes	Diagram UUID
`versionId`	Yes	Version UUID

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explicitly states the tool is read-only and that restore is not available via API (human-only UI). This discloses key behavioral constraints beyond the schema.

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?

Two sentences: first tells action and return data, second adds behavioral note. Every word earns its place; no filler.

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?

Despite no output schema, description specifies return fields (title, source code, metadata). With 2 simple params and clear behavior (read-only), the description provides sufficient context for correct invocation.

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 coverage is 100% with descriptions for diagramId and versionId. The description adds 'Fetch one snapshot by id' but does not elaborate on parameter meaning or format beyond what the schema already provides.

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?

Description clearly states 'Fetch one snapshot by id' and lists returned fields (title, mermaid source code, metadata). This specific verb+resource combination distinguishes it from siblings like list_versions (list all) and get_diagram (get diagram, not version).

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?

Description includes 'Read-only — restore is human-only in the UI,' which tells the agent this tool is for retrieval only and not for restoring a version. However, it lacks explicit guidance on when to use this vs list_versions (e.g., when you need details of a single version).

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

list_commentsAInspect

List comments on a diagram, oldest first. Returns id, parentId (null for a top-level comment), nodeId (the pinned node, if any), author, resolved state, and a body snippet. Use nodeId to fetch only the thread pinned to one node.

ParametersJSON Schema

Name	Required	Description
`diagramId`	Yes	Diagram UUID
`nodeId`	No	Only comments pinned to this node id
`includeResolved`	No	Include resolved threads (default true)
`limit`	No	Max items (default 500, max 500)
`offset`	No	Items to skip (default 0)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full load. It discloses the return fields (id, parentId, nodeId, etc.) and ordering, implying a read-only, non-destructive operation. It lacks details on pagination behavior beyond the schema, but the included information is sufficient.

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 three sentences, all substantive. The first sentence introduces the action and ordering. The second lists key return fields. The third gives actionable parameter advice. No fluff or redundancy.

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?

Given the tool has 5 parameters and no output schema or annotations, the description covers purpose, return structure, ordering, and parameter usage. It omits error behavior and pagination details, but the schema covers limit/offset. Overall, it is sufficient for a listing tool.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that nodeId 'fetches only the thread pinned to one node,' reinforcing the schema description and providing practical usage context. Other parameters are not elaborated, but the addition warrants a slight bump.

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 verb ('List') and resource ('comments on a diagram') and specifies ordering ('oldest first'). It distinguishes from sibling tools like add_comment (which creates) and others that deal with diagrams or decks. The purpose is unambiguous.

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 explicitly advises 'Use nodeId to fetch only the thread pinned to one node,' guiding when to apply that filter. It does not provide explicit contraindications or alternatives, but the advice is clear enough for effective use.

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

list_decksAInspect

List presentation decks in the configured Space, newest-edited first. A deck is an ordered set of existing diagrams shown as a slideshow. Returns each deck's id, title, and slide count.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It correctly identifies the operation as read-only (listing) and specifies the return fields. However, it doesn't mention potential behaviors like pagination, rate limits, or authentication, which are minor omissions for a simple list tool.

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 extremely concise: two sentences that cover purpose, ordering, definition, and return fields. Every word adds value with no redundancy.

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

Completeness5/5

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

Given no parameters or output schema, the description fully covers what the tool does and returns. It explains the concept of a deck and the sorting, making it self-contained.

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 coverage is 100% (0 parameters), so baseline is 3. The description adds no parameter info (none exist) but provides context on the return values, which is adequate.

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 lists decks in the configured Space with specific ordering (newest-edited first). It defines what a deck is and specifies the return fields, distinguishing it from siblings like create_deck or get_deck.

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

Usage Guidelines3/5

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

The description implies usage for listing decks but does not provide explicit guidance on when not to use it or mention alternatives. For example, it doesn't say 'use get_deck for a single deck' or 'use list_diagrams for diagrams.' The context is clear but not directive.

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

list_diagramsAInspect

List diagrams in the configured Space (every folder, newest first by default). Use this BEFORE create_diagram to check whether a diagram with the target purpose already exists — if it does, prefer update_diagram over creating a duplicate. Filter with q (case-insensitive substring on title or code) when looking for a named diagram (e.g. q: 'schema' or q: 'infra'). Sort with sort: 'updated' to find the most recently changed diagrams.

ParametersJSON Schema

Name	Required	Description
`q`	No	Case-insensitive substring search on title and code. Use when looking for a named diagram (e.g. 'schema', 'infra').
`owner`	No	Filter to diagrams created by this user (Clerk user id, e.g. 'user_abc'). Rarely needed; omit unless the caller already has the user id.
`sort`	No	Sort order. 'created' (default) = newest-first by creation; 'updated' = newest-first by last edit (use this to find the most recently changed diagram); 'title' = alphabetical.
`folderId`	No	Optional UUID — narrow to diagrams in this folder. Use list_folders to look up folder ids. Omit to see every folder (the default).

TDQS

A4.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes default sort behavior and filtering but does not disclose potential side effects, permissions, pagination, or rate limits. Adequate for a list tool but lacks deeper 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.

Conciseness5/5

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

Three sentences, front-loaded with main purpose, each sentence earning its place. No redundancy or fluff.

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?

Given no output schema and simple parameters, the description covers core usage, filtering, sorting, and a key workflow (avoid duplicates). Could mention pagination or limits, but not essential.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining when to use each parameter (e.g., 'use when looking for a named diagram' for `q`, 'omit unless the caller already has the user id' for `owner`, and 'use this to find the most recently changed diagram' for sort updated, plus references list_folders for folderId). This surpasses 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 'List diagrams in the configured Space' with default behavior (every folder, newest first). It distinguishes from siblings by mentioning use before create_diagram and preferring update_diagram.

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?

Explicitly advises to use before create_diagram to avoid duplicates, and suggests preferring update_diagram if a diagram exists. Also provides guidance on filtering with `q` and sorting with `sort`.

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

list_foldersAInspect

List every folder in the configured Space, ordered by name. Returns id and full path (e.g. 'Infra/AWS' for a nested folder). Use this BEFORE create_diagram or update_diagram when you want to place a diagram in a meaningful folder — agents should match by name (e.g. find a folder named 'Schemas' and pass its id as folderId). Folders are at most two levels deep. Creating folders is currently human-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description discloses behavior: returns id and path, ordered by name, max two levels deep, human-only creation. Assures read-only nature.

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?

Three concise sentences, front-loaded with main action, no wasted words, well-structured.

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

Completeness5/5

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

Complete for tool with no parameters and no output schema; explains return structure (id, full path) and nesting depth, covering all user needs.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema; baseline for 0 params is 4. Description adds value by explaining return fields, compensating for lack of 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 tool lists every folder in the configured Space, ordered by name, and returns id and full path. It distinguishes from siblings by mentioning its use before create_diagram or update_diagram.

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?

Explicitly states when to use (before create_diagram or update_diagram), how to match by name, and that folder creation is human-only, providing clear guidance.

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

list_versionsAInspect

List manual snapshots of a diagram, newest first. Returns id, label, title, createdAt, and createdBy for each.

ParametersJSON Schema

Name	Required	Description
`diagramId`	Yes	Diagram UUID
`limit`	No	Max items to return (default 100, max 200)
`offset`	No	Items to skip (default 0)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that only manual snapshots are listed, ordering is newest first, and specifies return fields. However, it doesn't mention pagination behavior or prerequisites like diagram existence, which are somewhat covered by schema parameters.

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?

Two sentences: first states purpose and ordering, second lists return fields. No unnecessary words; information is front-loaded and efficient.

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 simple list tool with no output schema, the description covers core behavior and return fields. It could mention pagination handling or error conditions, but overall it is fairly complete given 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 coverage is 100% with descriptions for limit and offset. The description adds no additional parameter semantics beyond what the schema provides, so baseline score applies.

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 lists manual snapshots of a diagram, ordered newest first, and specifies the exact fields returned. It distinguishes itself from siblings like get_version (single snapshot) and list_diagrams (different resource).

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

Usage Guidelines3/5

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

The description implies usage when needing to list snapshots for a given diagram, but does not explicitly state when not to use it or provide alternative tools. While siblings offer context, no direct guidance is given.

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

update_deckAInspect

Update a deck's title, description, and/or slide order. slides is DECLARATIVE: pass the complete desired ordered list of diagram ids — reorder, add, and remove are all expressed by sending the new full list (any id omitted is removed from the deck; new ids are appended in the order given). Returns the deck id and present URL.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Deck UUID
`title`	No	Deck title shown in the deck list and above the presentation.
`description`	No	One-line summary of what the deck covers (≤1000 chars).
`slides`	No	Complete ordered list of diagram UUIDs that should be in the deck after this update. Omit to leave the slides unchanged; pass [] to clear all slides.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the declarative nature of the slides parameter, including that omitted ids are removed and new ids are appended. It also specifies the return value (deck id and present URL). This goes beyond a simple 'update' to reveal non-obvious behavior, though it could mention permissions or side effects.

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

Conciseness5/5

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

The description is two sentences: first sentence states purpose, second explains the critical slides behavior and return value. It is concise, front-loaded, and every sentence adds value.

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

Completeness3/5

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

The description covers the core update functionality and slides behavior, but lacks details on error conditions (e.g., missing deck, invalid diagram IDs), prerequisites, or what happens to omitted fields for title/description. Given no output schema and 4 parameters, more context would improve completeness.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value for the slides parameter by explaining the declarative semantics (reorder, add, remove via full list). For other parameters, the schema descriptions are sufficient. The extra context raises the score above baseline.

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 verb 'update' and resource 'deck', specifying the aspects that can be modified (title, description, slide order). It distinguishes from sibling tools like create_deck and get_deck by focusing on mutation of an existing deck, and the declarative slides behavior is explicitly highlighted.

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

Usage Guidelines3/5

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

The description provides some usage guidance for the slides parameter (declarative approach) but does not explicitly state when to use this tool versus alternatives (e.g., create_deck or update_diagram). It lacks context on prerequisites or when not to use this tool.

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

update_diagramAInspect

Update an existing diagram's title, description, mermaid source, visual style preset, and/or layout style options. When rewriting the source, keep or restore class assignments using the role names from this server's instructions so the diagram stays color-grouped.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Diagram UUID
`title`	No	Display name
`code`	No	Mermaid source. Replaces the diagram's current code.
`style`	No	Visual preset: midnight (default dark), paper, forest, ocean, mono.
`styleOptions`	No	Optional layout knobs, independent of the color preset. Each key is optional; omit any to keep its default. Pass layout: 'auto' to let the server pick a concrete layout based on the diagram's shape.
`description`	No	Overall purpose of the diagram (≤1000 chars). Shown to share-link viewers and surfaced back to the agent as the diagram's brief — write this before generating the code.
`createVersion`	No	If true, snapshot the pre-update diagram state as a version row before applying the update. Use this to create a checkpoint right before an agent overwrites the diagram.
`versionLabel`	No	Optional short label for the snapshot taken when createVersion is true (max 80 chars).
`folderId`	No	Optional UUID of an existing folder to move this diagram into. Use list_folders to look up folder ids. (Moving back to root is currently human-only.)

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses the need to keep class assignments when rewriting source, which adds transparency. However, it does not mention other behavioral traits like permissions, atomicity, or error scenarios.

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?

Two concise sentences, front-loaded with the action and key fields. The second sentence adds critical guidance without fluff. Every word earns its place.

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

Completeness3/5

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

No output schema, and the description does not explain return values or behavior during simultaneous updates. Given 9 parameters and nested objects, more context on versioning or error handling would improve completeness.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 9 parameters are described in the schema (100% coverage). The description adds value beyond schema for the code parameter by specifying to preserve class assignments, and provides an overall summary. Baseline is 3, extra guidance raises it to 4.

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 it updates an existing diagram's title, description, mermaid source, visual style preset, and/or layout style options. It distinguishes from sibling tools like create_diagram and get_diagram by focusing on modification.

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

Usage Guidelines3/5

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

The description implies usage for updating existing diagrams but does not explicitly state when to use versus alternatives like create_diagram or when not to use. Guidance is inferred but not direct.

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.

8 tool updatesv0.0.4Jun 18, 2026
- Addedadd_comment
- Changedanalyze_diagram1 field changed
  - addedInput schema / properties / postAsComments
```
Added value: +{
+  "description": "If true, persist each finding as a comment on the diagram instead of only returning ephemeral prose.",
+  "type": "boolean"
+}
```
- Addedcreate_deck
- Addedget_deck
- Addedlist_comments
- Addedlist_decks
- Addedupdate_deck
- Changedupdate_diagram3 fields changed
  - addedInput schema / properties / code / description
```
Added value: +"Mermaid source. Replaces the diagram's current code."
```
  - addedInput schema / properties / id / description
```
Added value: +"Diagram UUID"
```
  - addedInput schema / properties / title / description
```
Added value: +"Display name"
```
8 tool updatesv0.0.3Jun 18, 2026
- First observedanalyze_diagram
- First observedcreate_diagram
- First observedget_diagram
- First observedget_version
- First observedlist_diagrams
- First observedlist_folders
- First observedlist_versions
- First observedupdate_diagram

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: CRUD for diagrams, listing, analysis, versioning, and folder management. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_diagram, list_folders, get_version). The only minor variation is get_version vs. list_versions, which is appropriate for singular vs. plural.

Tool Count5/5

8 tools is well-scoped for the domain of diagram management with versioning and folder support. Each tool earns its place without unnecessary bloat.

Completeness3/5

The set covers creation, retrieval, updating, listing, analysis, and version history. However, it lacks a delete diagram tool, which is a notable gap for full lifecycle management.

Maintenance

ActivityStale

ResponsivenessNo issues

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

Agentic Mermaid A
io.github.adewale
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Data Visualization Software Architecture
9210
DrillSpark MCP ServerOAuth
io.github.jackasser
Create and manage Mermaid.js flowcharts and diagrams with AI agents via MCP.
Software Architecture Developer Tools App Automation
2
Agentage MemoryOAuth
io.agentage
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Knowledge & Memory File Systems
2
cnvs.app A
app.cnvs
Real-time collaborative whiteboard — AI agents and humans edit the same board live over MCP.
Design Tools App Automation
2521

Related MCP Servers

MCP Server Mermaid
Code Execution Data Platforms Developer Tools
hustcc
A
license
B
quality
C
maintenance
❤️ Generate mermaid diagram and chart with AI MCP dynamically.
Updated 4 months ago (2026-05-15 12:16 UTC)
1
3,023
627
TypeScript
MIT
AI Diagram Maker MCP Server
Software Architecture Developer Tools Data Visualization
erajasekar
A
license
A
quality
F
maintenance
MCP server for AI Diagram Maker — generate software engineering diagrams from natural language, code, ASCII diagram, images, or Mermaid. Inline diagram rendering using MCP apps UI and diagram URL in responses. Works with Cursor, Claude Desktop, Claude Code, and any MCP-compatible AI.
Updated 4 months ago (2026-05-04 04:45 UTC)
5
22
8
MIT
Mermaid Studio
Design Tools Software Architecture
wangyaominde
F
license
Not graded
quality
D
maintenance
Enables AI to create, edit, and manage Mermaid diagrams via MCP, with real-time preview in a browser-based editor.
Updated 5 months ago (2026-04-08 16:02 UTC)
3
-
mermAId MCP Server
Software Architecture Developer Tools Design Tools
mozi-app
A
license
Not graded
quality
B
maintenance
Enables AI agents to interact with a local Mermaid diagram editor via MCP, allowing them to get and set diagrams programmatically.
Updated a month ago (2026-08-11 16:51 UTC)
15,208,241
12
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on 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/yenchieh/diagramzu-mcp'

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