graphite-art-mcp

Overview Schema Source Related Servers Discussions Admin

Graphite: export the active document

graphite_export

DestructiveIdempotent

Export all artwork in the active Graphite document to SVG or raster formats such as PNG, JPG and WebP, saving the result to disk and returning its absolute path.

Instructions

Render the active Graphite document (all artwork) to a file and write it to disk. Returns the absolute path. Use svg for editable/scalable output and png for a bitmap; png with scale 0.25–0.5 is a cheap way to check what Graphite actually rendered. Fails with EXPORT_FAILED if the document has no layers, BRIDGE_TIMEOUT if rendering did not finish within GRAPHITE_MCP_EXPORT_TIMEOUT_MS (the first raster render of a large document can be slow: simply retry, or raise the limit), and EXPORT_PATH_NOT_ALLOWED if path escapes the approved export directories.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	No	Where to write the file. A bare file name goes into the connector's export directory; an absolute path must lie inside one of the approved export roots. The extension is fixed to match format. Omit to use the document name.
`scale`	No	Raster scale factor (2 = 2× resolution; 0.25–0.5 gives a quick preview). Ignored for svg.
`format`	No	Output format. svg keeps vectors; the raster formats are rendered at the document's pixel size times scale.	svg

Output Schema

TableJSON Schema

Name	Required	Description
`path`	Yes	Absolute path of the written file.
`bytes`	Yes
`format`	Yes
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by enumerating three concrete failure modes (EXPORT_FAILED, BRIDGE_TIMEOUT with the env var and 'just retry' advice, EXPORT_PATH_NOT_ALLOWED) and the path-sandbox constraint. The destructiveHint=true annotation is consistent with a tool that writes/overwrites files.

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?

Front-loads the core action and return value, then layers guidance and failures compactly. Every sentence carries actionable information with no filler.

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?

An output schema exists, so return details are covered; the description still names the returned path. Combined with error codes, timeout behavior, and path restrictions, an agent has everything needed to invoke it correctly.

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 already 100%, but the description still adds practical meaning: svg vs raster trade-offs and the 0.25–0.5 cheap-preview tip for scale. It doesn't restate the path rules beyond what the schema says, so it is additive without redundancy.

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 ('render the active Graphite document to a file and write it to disk') plus the return value (absolute path). The emphasis on writing to disk implicitly distinguishes it from sibling graphite_preview, so an agent can tell what this tool produces.

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 format-selection guidance ('svg for editable/scalable output', 'png for a bitmap') and a cheap verification workflow via png at scale 0.25–0.5. It never explicitly names graphite_preview as the alternative for on-screen inspection, so the when-to-use-this-vs-sibling routing is implied rather than stated.

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

Deploy Server