Skip to main content
Glama
yenchieh

DiagramZu

by yenchieh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

analyze_diagram

Inspect a stored flowchart's structure to surface orphan nodes, cycles, hubs, and disconnected clusters, optionally posting findings as diagram comments.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
idYesDiagram UUID
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.
postAsCommentsNoIf true, persist each finding as a comment on the diagram instead of only returning ephemeral prose.

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.4
    • 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"
+}
  3. First observedv0.0.3

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 burden. It usefully discloses the mutation side effect: default behavior is ephemeral prose, while postAsComments:true persists comments on the diagram surface (node-pinned when a finding names a single node). It omits permissions/auth requirements and any rate or cost considerations, keeping it short of a 5.

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 the list of findings, then the flowchart-only restriction, then the optional flag. Every sentence earns its place, though the final sentence is long and could be tightened.

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?

For a 3-parameter tool with no output schema, the description names the return contents (orphan nodes, over-connected hubs, cycles, disconnected clusters, grouping suggestions) and covers the optional write path. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the effect of postAsComments (persisting findings as comments) and the node-pinning behavior, which the schema does not mention.

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 (analyze) and resource (stored flowchart diagram's structure: nodes, edges, subgraphs) and enumerates the concrete findings returned. The 'Flowchart diagrams only' restriction further distinguishes its scope 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?

Gives a clear condition for the optional behavior ('Set postAsComments: true to also persist...'), but does not name an alternative tool or state when analysis should be preferred over, e.g., get_diagram. No sibling tool offers structural analysis, so the absence of explicit alternatives is a minor gap.

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