Skip to main content
Glama
yenchieh

DiagramZu

by yenchieh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_deck

Assemble an ordered slideshow from existing diagram IDs in a workspace, returning the deck ID and Space-only present URL for playback.

Instructions

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, which only members of this Space can open — it is NOT a shareable link. To share the deck outside the Space, someone in the Space opens it in DiagramZu and uses its Share button, which mints a public read-only presentation link. Diagram ids must already exist in this Space (use list_diagrams to find them).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
titleNoDeck title shown in the deck list and above the presentation (≤200 chars).
slidesNoOrdered 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.
descriptionNoOptional one-line summary of what the deck covers (≤1000 chars).

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. Changed1 schema field changedv0.0.6
    • changedInput schema / properties / title / description
      Previous value: -"Deck title shown in the deck list and above the presentation."New value: +"Deck title shown in the deck list and above the presentation (≤200 chars)."
  3. Addedv0.0.4

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: it discloses the return values (deck id and present URL), a critical access constraint (only Space members can open the URL, it is NOT shareable), and the out-of-band sharing path via DiagramZu's Share button. This is exactly the non-obvious behavioral context an agent needs.

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-loads the action and the slides contract, then the flow, then the return/sharing caveat. Dense and mostly waste-free, though the sharing explanation runs slightly long for a single tool description.

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?

No output schema exists, and the description compensates by explaining what is returned (deck id, present URL) and its access limitation. Combined with the prerequisite chain, an agent has everything needed to call this correctly.

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 space, title, slides, and description including the ≤200/≤1000 char limits and the 'at most once' rule. The description reinforces the ordered-list semantics but adds little beyond the schema, so the baseline 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?

States a specific verb+resource ('Create a presentation deck from existing diagrams') and immediately names the source objects, distinguishing it from siblings like create_diagram and update_deck. An agent can tell exactly what this produces.

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?

Gives an explicit typical flow (create_diagram per slide → collect ids → create_deck in presentation order), names the prerequisite (ids must already exist in this Space, use list_diagrams), and routes the sharing use case to a separate mechanism. When-to-use and alternatives are fully covered.

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