Skip to main content
Glama

Get Diagram Source

diagrams_get
Read-onlyIdempotent

Get the raw source of a PlantUML or Mermaid diagram by file path, returning the full text or a specific character window for large diagrams.

Instructions

Retrieve the raw source text of a single PlantUML or Mermaid diagram, in full or as an explicit character window.

Args:

  • relative_path (string): Path to the diagram relative to the diagrams root, as returned by diagrams_list

  • offset (number, optional): Zero-based character offset where the returned window starts (default: 0)

  • max_chars (number, optional): Maximum characters to return from offset (1-100000). Omit to return the full source

Returns: JSON with schema: { "relative_path": string, "type": "plantuml" | "mermaid", "content": string, // full source, or the requested [offset, offset+max_chars) window "is_partial": boolean, // true when content is a window rather than the full source "offset": number, // effective character offset of this window "total_chars": number, // full source length in characters "returned_chars": number,// length of the returned content "has_more": boolean // true when source after this window remains }

The text block always equals structuredContent.content. Content is never silently truncated: omitting offset/max_chars returns everything, and requesting a window is always reported via is_partial/has_more.

Examples:

  • Use when: "Show me the order-flow diagram" -> relative_path="system/order-flow.puml"

  • Use when: "Read the first 2000 characters of the big diagram" -> relative_path="...", offset=0, max_chars=2000, then offset=2000 for the next window

  • Don't use when: You need to list what diagrams exist first (use diagrams_list)

Error Handling:

  • Returns "Error: No diagram found at ''" if the file doesn't exist

  • Returns "Error: Refused to access path outside the diagrams root" if relative_path attempts to escape the diagrams directory (e.g. via '../..')

  • Returns "Error: Invalid source window: ..." if offset/max_chars are negative, non-integer, or max_chars is outside 1-100000

  • Returns "Error: offset is out of range ..." if offset points past the end of the source

  • Unexpected internal failures return a generic "Error: Unexpected internal error ..." with isError:true and are logged to stderr without source, paths, or secrets

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoZero-based character offset into the diagram source where the returned window starts (default: 0).
max_charsNoMaximum characters to return starting at offset (1-100000). Omit to return the full source.
relative_pathYesPath to the diagram, relative to the diagrams root (e.g. 'system/order-flow.puml'). Get this from diagrams_list.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral detail beyond this: it explains the windowing behavior with is_partial/has_more flags, guarantees no silent truncation, and provides a comprehensive error-handling list (file not found, path escape, invalid window, out-of-range offset). This far exceeds annotation coverage and fully discloses behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While long, the description is modularly structured with clear sections (Args, Returns, Examples, Error Handling) and front-loads the core purpose. Every sentence serves a purpose—there is no fluff or repetition. The length is justified by the tool's windowing and error complexity, and the structure makes it easy to scan.

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?

Despite lacking an output schema, the description provides a full inline JSON return schema with all fields explained. It covers error cases, examples, and parameter usage. For a tool with this complexity (character windows, partial returns), the description leaves nothing an agent needs to call it correctly; it is complete.

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 reinforces each parameter and adds usage nuance: it explains that omitting offset/max_chars returns the full source, demonstrates a windowing example (offset=0, max_chars=2000, then offset=2000), and clarifies the zero-based offset. This goes beyond the schema's basic type/range descriptions, though it does not introduce entirely new semantics.

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 statement: 'Retrieve the raw source text of a single PlantUML or Mermaid diagram, in full or as an explicit character window.' It clearly distinguishes itself from siblings, explicitly noting the alternative diagrams_list for listing diagrams. No ambiguity about what this tool does.

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?

The Examples section explicitly states 'Use when' scenarios (e.g., 'Show me the order-flow diagram') and 'Don't use when' (e.g., when needing to list diagrams first, use diagrams_list). It also instructs that relative_path should come from diagrams_list, giving clear routing to the correct sibling.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mohammad-emad-dev/diagrams-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server