Skip to main content
Glama

Archboard

by app.getarchboard
OverviewDiscussionsAdmin

Export a PNG or SVG file

export_diagram
Idempotent

Exports the diagram, or one frame (frameId: the frame and everything inside it), as a PNG or SVG file and returns a download link for the person. Returns { downloadUrl, expiresAt, maxDownloads, downloadsLeft, reused, filename, mimeType, bytes, width, height, scale, requestedScale, seq, watermark, watermarkSource, watermarkStyle, watermarkPosition, externalImageCount, externalImageNodeIds, warnings }. The link downloads the file (it is not an inline image) until expiresAt (15 minutes), for up to 5 downloads, and anyone with the link can use it until then. Calling again with the same arguments while the diagram is unchanged returns the same open link (reused: true, with downloadsLeft) instead of a new file. PNG: scale 1–4 pixels per diagram unit (default 2), long edge up to 3072 px; scale in the result is the pixels per unit actually used, and warnings lists png_scale_capped (size limit) or png_size_reduced (file size limit) when it is lower than requested (for a large diagram, a frameId or format svg gives a sharper file). SVG: a still image unless animate is true. Files always have the theme’s opaque background and a fixed margin; PDF and JPEG files, a transparent background and custom margins are made in the editor (Share → Export). watermark adds the Archboard watermark; it is always added when the organization’s plan requires it (watermarkSource "plan"). watermarkStyle and watermarkPosition choose its look and corner; warnings lists watermark_style_adjusted when the requested style was replaced by badge. PNG is drawn by the same renderer as render_snapshot, with the same limits: external and AVIF images render as placeholders, colour emoji render in one colour, text inside nested SVG images is not drawn. In SVG, external and AVIF images are placeholders. When images point to a web address, warnings lists external_images_placeholder with externalImageCount and externalImageNodeIds (add_image imports them).

Input Schema

NameRequiredDescriptionDefault
scaleNoPNG only: pixels per diagram unit (default 2). The long edge is capped at 3072 px. The result’s scale is the value actually used.
themeNoColour theme (default light); the file’s background is the theme’s opaque canvas colour.light
formatNoFile format: png (default) or svg. PDF and JPEG files are made in the editor (Share → Export).png
animateNoSVG only: keep the diagram’s edge animations (SMIL). Default false: a still SVG.
frameIdNoExport only this frame (or any node) and its subtree.
filenameNoFile name without extension, in any language (default: the diagram title; with frameId, the title and the frame name).
diagramIdYesDiagram id (from list_diagrams or create_diagram).
watermarkNoAdd the Archboard watermark. Ignored when the organization’s plan always adds it (watermarkSource "plan").
watermarkStyleNoWatermark style: badge (default: logo, name and domain on a light chip), badge-dark (the same on a dark chip), mark (logo only; replaced by badge when the organization’s plan requires the watermark), band (edge band).
watermarkPositionNoCorner: bottom-right (default), bottom-left, top-right, top-left.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say non-read-only, idempotent, non-destructive; the description adds the meaningful behavior: link expires in 15 minutes, max 5 downloads, anyone with the link can use it, identical arguments on an unchanged diagram return the same link (reused: true). It also discloses that the organization's plan can force a watermark regardless of the watermark flag, and that scale can be silently capped.

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

Conciseness3/5

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

The opening sentence is well front-loaded, but the body is a single dense wall of text and one long sentence simply enumerates 19 result field names with no explanation of most of them, which is padding rather than guidance. The material is nearly all substantive, but the structure makes it hard to scan and the field list could be trimmed.

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 must carry the return contract, and it does: link semantics, expiry, download budget, reuse, scale caps, warning codes, watermark plan override, and placeholder behavior for external/AVIF images in both PNG and SVG. Nothing an agent needs to call it correctly or interpret the result 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, but the description goes beyond it by explaining outcomes rather than repeating definitions: the result's scale is the pixels-per-unit actually used and warnings reports png_scale_capped or png_size_reduced when it differs from the request. It also clarifies that frameId exports the frame and everything inside it and that watermark is ignored when watermarkSource is "plan".

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 and resource — exports a diagram or a single frame as PNG/SVG and returns a download link for the person. It also distinguishes itself from render_snapshot (inline render) and from editor-only PDF/JPEG export, so an agent can place it among its siblings immediately.

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 clear routing context: PDF/JPEG, transparent backgrounds and custom margins must be done in the editor (Share → Export); add_image imports external images that would otherwise become placeholders; a frameId or format svg yields a sharper file on large diagrams. It never states an explicit 'use this instead of render_snapshot when...' rule, so it falls just short of a 5.

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

All Archboard toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources