Skip to main content
Glama

View the diagram (fast)

canvas_view
Read-onlyIdempotent

When: use to see a diagram before you edit it and after each round of changes; this is how you check your work. It answers in milliseconds from the saved diagram, where export_diagram starts a browser for 6-10 s.

Returns a text map: the zones as a tree, each with its place on a coarse grid (r1 = top row, c1 = left column) and its nodes (label, type, icon, #id), then the edges, then the checks a render would reveal: overlapping nodes, overlapping sibling zones, nodes sticking out of their zone, nodes not laid out yet, empty zones, and the validator's error and warning counts. Every #id works as a node reference in the canvas_* tools. It also says when an edit_diagram run or a generation is still in progress on the diagram, and gives a preview image link that renders only if opened.

For a large diagram, pass zone to look at one zone. include_image also renders a PNG (slow: only when you need to see styling).

Next: fix what the checks report with the targeted canvas_* tool, then canvas_view again.

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": {
      "diagram_id": "<diagram_id>"
    },
    "name": "canvas_view"
  }
}

Input Schema

NameRequiredDescriptionDefault
zoneNoZone id or exact label: show only that zone and what it contains.
diagram_idYesDiagram id, from list_diagrams, create_diagram or create_blank_diagram.
include_edgesNoList the edges. Default true.
include_imageNoAlso render a PNG, 6-10 s. Default false.
include_columnsNoList column names under each table. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent safety, but the description goes well beyond: millisecond latency sourced from the saved diagram, detection of an in-progress edit_diagram run or generation, and the caveat that the preview image link only renders if opened. The enumerated checks (overlap, orphaned nodes, empty zones, validator counts) tell the agent exactly what signal it will get back.

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 a 'When:' clause and organized as when/returns/parameters/next. Dense rather than padded, though the millisecond-vs-export timing comparison is stated twice, which is slightly redundant.

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?

There is no output schema, so the description carries the return contract itself and does so thoroughly: tree of zones with grid coordinates, node attributes (#id usable in canvas_* tools), edge list, and the render checks. Nothing an agent needs to interpret or act on the response 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 coverage is 100%, so the baseline is 3, and the description adds real guidance on top: use zone for large diagrams and treat include_image as a slow path only needed for styling. It doesn't explain include_edges/include_columns, but those are self-documenting in 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?

States a specific verb+resource ('see a diagram') and immediately frames the return as a text map with defined structure. It is clearly distinguished from export_diagram and from the many canvas_* mutation siblings by being the read/verify step.

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?

Explicit when-to-use: 'before you edit it and after each round of changes; this is how you check your work.' It also names the alternative (export_diagram) plus the selecting condition (6-10 s browser start) and closes with a prescribed next step routing to the targeted canvas_* tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources