Skip to main content
Glama
yenchieh

DiagramZu

by yenchieh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_diagram

Create a Mermaid diagram in a DiagramZu workspace from code or defaults. Returns its id and Space-only URL for team viewing, commenting, and sharing.

Instructions

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 class role names (edge/core/data/accent/muted) for color-grouping.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoMermaid source (≤50,000 bytes). Defaults to a tiny flowchart.
spaceNoWhich workspace to act in: its id, its slug, or its exact name (case-insensitive). Omit to use this token's default workspace. Call list_spaces to see what this token can reach. A name that matches more than one workspace is refused — pass the id or slug instead.
styleNoVisual preset: midnight (default dark), paper, forest, ocean, mono. Omit to use the default.
titleNoDisplay name (≤200 chars)
folderIdNoOptional 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.
descriptionNoOverall 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.
styleOptionsNoOptional 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.0.7
    • addedInput schema / properties / space
      Added value: +{
+  "description": "Which workspace to act in: its id, its slug, or its exact name (case-insensitive). Omit to use this token's default workspace. Call list_spaces to see what this token can reach. A name that matches more than one workspace is refused — pass the id or slug instead.",
+  "type": "string"
+}
  2. Changed2 schema fields changedv0.0.6
    • changedInput schema / properties / code / description
      Previous value: -"Mermaid source. Defaults to a tiny flowchart."New value: +"Mermaid source (≤50,000 bytes). Defaults to a tiny flowchart."
    • changedInput schema / properties / title / description
      Previous value: -"Display name"New value: +"Display name (≤200 chars)"
  3. First observedv0.0.3

TDQS

A4.3/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 and does real work: it discloses that the returned URL is Space-member-only, is NOT shareable, and that a public link requires an in-app Share action. It does not cover creation-time permissions, failure modes, or rate limits, but the visibility semantics are unusually well documented.

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?

Front-loaded with the core action and return value, and the sharing caveat is worth its length because misuse produces a link that silently fails for outsiders. The Share-button walkthrough is somewhat verbose, but every sentence conveys a distinct constraint.

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 7-parameter, annotation-free tool with a nested object and no output schema, the description fills the two biggest gaps itself: return shape and link visibility. Remaining omissions are error behavior and creation permissions, which are secondary for a first-call 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 the baseline is 3, but the description adds genuine meaning beyond the schema by pointing at the class role names (edge/core/data/accent/muted) for color-grouping in the Mermaid code and by explaining what the description field is for. The nested styleOptions object is left to 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?

Opens with a specific verb and resource scoped to a Space ('Create a new diagram in the Space'), which is clearly distinguishable from siblings like create_deck or update_diagram. It also states what is returned (id and URL), so an agent knows the outcome without opening any schema.

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?

It routes the agent to the server instructions for diagram-type selection and explains the sharing workflow, but never states when to prefer this over alternatives such as update_diagram or when creation would be refused (e.g. duplicate names). Context is clear, but explicit exclusions are absent.

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

Deploy Server

Other Tools