Skip to main content
Glama

Diagram View

diagram_view
Read-only

View a saved diagram as an iframe-embeddable HTML page with inline SVG rendering; no API key required.

Instructions

Diagram View. View a previously saved diagram as an HTML page. Public, no API key required. Iframe-embeddable with inline SVG rendering.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "diagram_view"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe diagram ID returned in the X-Diagram-View-URL header when saving a diagram. Format: cq-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
shareNoSet share=true to persist the config and receive JSON instead of an image: { id, render_url, view_url, embed_url, expires_in }. Free plan: 3-day expiry with watermark. Paid plan: 6-month expiry, no branding. Default: false.
fieldsNoComma-separated list of fields to keep in the response, with dot notation for nested fields (e.g. name,location.city). Does not change the credit cost.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true; the description adds genuinely new behavioral facts — no API key required, public accessibility, and embeddability via inline SVG. It does not, however, reconcile the "HTML page" framing with the schema's share=true path that returns JSON instead of an image.

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?

Four short sentences, front-loaded with the core purpose, with no filler. Slightly fragmented (the title is repeated as the first sentence), but nothing that wastes the reader's time.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Three parameters with full schema coverage and no output schema means the description needn't explain return values, so it is close to adequate. What it leaves out is the distinction from its many siblings and any hint about the share=true JSON response shape, which matters for an agent invoking it with that flag.

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%, and the id, share, and fields parameters are each documented thoroughly in the schema, including the cq- id format and plan-based expiry. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"View a previously saved diagram as an HTML page" states a specific verb (view) and resource (saved diagram) plus the output form. It is reasonably distinguishable from diagram_render/diagram_view siblings, though it never names them, so the reader must infer the render-vs-view split.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context (public, no API key, iframe-embeddable) that implies when this tool is appropriate — embedding a saved diagram in a page. But it gives no explicit when-to-use/when-not guidance and never contrasts itself with diagram, diagram_render, or diagram_ai, which an agent must pick between.

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