Skip to main content
Glama
yenchieh

DiagramZu

by yenchieh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_diagram

Update a diagram's title, description, Mermaid source, style preset, or layout options. In review-enabled workspaces, changes are proposed for approval.

Instructions

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. In a workspace with proposal review enabled, your change is recorded as a proposal pending human approval rather than applied to the live diagram — in that case tell the user you've proposed the change and share the review URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesDiagram UUID
codeNoMermaid source (≤50,000 bytes). Replaces the diagram's current code.
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.
titleNoDisplay name (≤200 chars)
folderIdNoOptional 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.)
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.
versionLabelNoOptional short label for the snapshot taken when createVersion is true (max 80 chars).
createVersionNoIf 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.

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. Replaces the diagram's current code."New value: +"Mermaid source (≤50,000 bytes). Replaces the diagram's current code."
    • changedInput schema / properties / title / description
      Previous value: -"Display name"New value: +"Display name (≤200 chars)"
  3. Changed3 schema fields changedv0.0.4
    • 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"
  4. First observedv0.0.3

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 the full burden and largely succeeds: it discloses the proposal-review approval flow (a non-obvious side effect that changes whether the edit is live), the color-grouping requirement for source rewrites, and the 'and/or' semantics implying partial updates. It does not cover permission/workspace requirements or failure modes, which keeps it out of 5 territory.

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?

Three sentences, front-loaded with the purpose, then the two most consequential behavioral caveats. Nothing is filler, though the sentences are dense and could be trimmed slightly.

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 10-parameter mutation tool with a nested styleOptions object, no output schema and no annotations, the description covers the critical unknowns: that fields are optional/partial, that a proposal may be created instead of an immediate write, and the source-rewrite constraint. Missing only auth/workspace prerequisites, which the schema's `space` description partially handles.

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 10 parameters in depth (code byte limit, space resolution rules, enum meanings, versionLabel/createVersion interactions). The description mostly restates the field list and adds only the cross-reference to role names for `class` assignments; baseline 3 is appropriate.

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 opens with a precise verb+resource ('Update an existing diagram') and enumerates the mutable surface (title, description, mermaid source, style preset, layout options). The resource is unambiguous against the sibling update_deck, and an agent can route correctly without opening the 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 gives real conditional guidance: keep/restore `class` assignments from the server instructions when rewriting source, and in proposal-review workspaces the change becomes a pending proposal — with an instruction to inform the user and share the review URL. It stops short of naming explicit alternatives (e.g. create_diagram vs update, or reading with get_diagram first).

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