DiagramZu
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DIAGRAMZU_BASE_URL | No | Base URL for diagramzu.ai API | https://diagramzu.ai |
| DIAGRAMZU_SPACE_ID | Yes | Space ID | |
| DIAGRAMZU_API_TOKEN | Yes | API token (looks like dz_live_...) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_diagramsA | 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 |
| list_foldersA | 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. |
| get_diagramA | Fetch one diagram by id. Returns its title, description (the agent's brief), mermaid source code, and its URL in the app — which only members of this Space can open. If the diagram already has a public link, that link is reported separately on a |
| create_diagramA | Create a new diagram in the Space. Returns its id and its URL in the app, which only members of this Space can open — it is NOT a shareable link. To show the diagram to anyone outside the Space, someone in the Space opens it in DiagramZu and uses its Share button, which mints a public read-only link. See this server's instructions for diagram-type selection and |
| update_diagramA | Update an existing diagram's title, description, mermaid source, visual style preset, and/or layout style options. When rewriting the source, keep or restore |
| analyze_diagramA | 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. |
| list_versionsA | List manual snapshots of a diagram, newest first. Returns id, label, title, createdAt, and createdBy for each. |
| get_versionA | Fetch one snapshot by id. Returns its title, mermaid source code, and metadata. Read-only — restore is human-only in the UI. |
| list_commentsA | 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. |
| add_commentA | 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. |
| list_decksA | 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. |
| get_deckA | 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). |
| create_deckA | Create a presentation deck from existing diagrams. Pass |
| update_deckA | Update a deck's title, description, and/or slide order. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool targets a distinct resource and action: diagrams, decks, comments, versions, and folders are cleanly separated, and get/list/create/update variants are unambiguous. The only close pair, get_diagram and get_version, is clearly distinguished by current source vs snapshot source.
All 14 tools follow a consistent snake_case verb_noun pattern (list_*, get_*, create_*, update_*, add_comment, analyze_diagram). The use of add_comment instead of create_comment is a minor verb choice but does not break the pattern.
14 tools is well within the ideal 3-15 range and matches the server's scope: diagram CRUD, deck management, comments, versions, and analysis. Each tool has a clear purpose and none feel redundant.
Core workflows are covered: create/read/update diagrams and decks, list/get versions, and comment on diagrams. Obvious gaps are the lack of delete operations, comment resolution, and version creation, though several of these are explicitly human-only by design.