Skip to main content
Glama
imgly

CoDesign

Official
by imgly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

export

Turn a design revision into a final deliverable: PDF, image, SVG, print-ready PDF/X, HTML, or editable .imgly. Renders the full document or a chosen block and saves the result to the workspace.

Instructions

Export a revision to a final deliverable — format picks it: pdf (print PDF), png/jpeg/webp (image), svg (vector SVG), pdfx (print-ready PDF/X), html (responsive HTML5), imgly (editable design file). Renders blockId — or the whole document when blockId is omitted — and writes the result into the workspace under exports/<shard>/<rev>/ (revision-pinned, deterministic).

Returns JSON: { uri, httpUrl, bytes, format, revision } (plus path when you pass outPath). uri (a workspace:// URI) is the durable handle. httpUrl is a fetch link tied to this process — fetch it to download the bytes to disk, or hand it to the user.

outPath (optional, absolute path including the filename): ALSO write the artifact to that local path — the workspace copy is still written, and the response then carries path. Use it when the file is wanted on disk, and always when your environment cannot fetch localhost URLs (sandboxed harnesses, e.g. Claude Cowork — target your session's outputs folder there).

format=svg is the engine's vector export: text is outlined into paths (renders identically everywhere, but is not editable text in the SVG), and raster images are embedded in the file at source resolution — an SVG of a photo-heavy design can be much larger than its source images.

format=imgly writes a portable, self-contained .imgly design file (scene + all asset bytes bundled) — the inverse of import, and the only format that stays editable. Whole-design only: blockId is not accepted. Every edit already auto-persists to the workspace, so you never need this to keep your work — use it to take an editable copy OUT: hand it to a human, back it up, move it between servers.

format=pdfx runs the print PDF through a PDF/X conversion (Ghostscript): CMYK with an embedded ICC profile and PDF/X conformance markers, ready for a print shop. Tune it via the optional pdfx object — conformance standard (X-4 default / X-3), output profile (fogra39/gracol/srgb/custom), transparency flattening, OutputIntent metadata. Conversion adds a few seconds.

format=html renders ONE page (blockId required — pass a page id) to responsive HTML5. Default is a single self-contained .html (assets inlined; animated designs get a CDN GSAP player injected so the file plays as-is); html: { assets: "external" } delivers html + separate image/font files as one .zip.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoOptions for `format=html` only (invalid with any other format).
pdfxNoOptions for `format=pdfx` only (invalid with any other format). Omit entirely for sensible print defaults: PDF/X-4, fogra39, embedded ICC.
formatYesThe deliverable: pdf → print PDF; png/jpeg/webp → image; svg → vector SVG; pdfx → print-ready PDF/X; html → HTML5 page; imgly → editable design file.
blockIdNoThe page or block to render. Omit to export the whole document — for `format=pdf` a multi-page PDF, for an image format one composite image of all pages. Required for format=html (pass a page id).
outPathNoAbsolute path (including filename) to ALSO write the artifact to — the workspace copy is still written, and the response then carries `path`. Use when you need the file on disk and cannot fetch localhost URLs (sandboxed harnesses).
revisionYes

Schema Changelog

Changes observed during successful MCP inspections.

  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?

With no annotations, the description carries full behavioral burden. It discloses side effects (writes into workspace under a deterministic revision-pinned path), return shape (JSON with uri, httpUrl, bytes, format, revision, plus path), and format-specific quirks (SVG outlines text, imgly is self-contained, pdfx adds seconds, html injects GSAP). It also notes httpUrl is process-bound and warns about sandboxed harnesses. No contradictions.

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?

The description is long but well-structured: it front-loads the purpose and format list, then dedicates focused paragraphs to outPath, svg, imgly, pdfx, and html. Every section earns its place given the tool's complexity; no filler. It could be slightly tighter but is appropriately detailed for the scope.

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?

Given 6 parameters, nested objects, and no output schema, the description fully covers invocation and behavior: return JSON, workspace path, format nuances, blockId rules, outPath usage, and sandbox limitations. An agent has everything needed to call the tool correctly and handle results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 83%, yet the description adds substantial meaning beyond the schema: it explains the format enum's practical implications (e.g., pdfx print-ready, imgly editable), clarifies blockId omission behavior (whole document), details outPath use cases, and expands on html and pdfx nested options with trade-offs. This goes far beyond the schema's terse descriptions.

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 specific verb and resource ('Export a revision to a final deliverable') and enumerates all supported formats with one-line outcomes (pdf, png/jpeg/webp, svg, pdfx, html, imgly). It distinguishes itself from siblings by framing imgly as the inverse of import and noting that edit auto-persists, so an agent can clearly tell export apart from preview, view, and edit.

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 description gives explicit when-to-use guidance: when to pass outPath (when file needed on disk, when sandboxed cannot fetch localhost), when to use imgly (to take an editable copy out), when to use pdfx (print shop), and when html is required (single page, blockId mandatory). It also tells the agent when not to use it ('you never need this to keep your work') and contrasts with edit.

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