Skip to main content
Glama
Bieuulls

Illustrator AI & MCP Control

by Bieuulls
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

illustrator_export_document

Destructive

Export the active Illustrator document to PNG or JPG for raster deliverables, with optional scale, artboard clipping, and inline image feedback.

Instructions

Export the active document to PNG or JPG. Native SVG and PDF are refused.

CONTRACT: readOnly=False, destructive=True, idempotent=False, openWorld=True

WHEN TO USE:

  • Generating raster output (PNG, JPG) with optional scale factor

  • Native SVG is disabled: live export changed the source file association

  • Getting visual feedback by setting return_image=True (PNG/JPG only)

  • NOT for looking at your work in progress. Exporting writes a file to disk and overwrites whatever was there. To see the artwork, call illustrator_observe: it returns the image inline together with a numbered map of items, their handles and their bounds, with no file to create, locate and open. Export when you want a deliverable

EXAMPLES: PNG at twice the size: {"params": {"file_path": "C:/out/fig.png", "format": "png", "scale": 2.0}} PDF refusal; use a separate working copy with Illustrator PDF save: {"params": {"file_path": "C:/out/fig.pdf", "format": "pdf"}} SVG refusal after source-association failure; use a separate working copy: {"params": {"file_path": "C:/out/fig.svg", "format": "svg"}} PNG of the artboard, returned inline as well: {"params": {"file_path": "C:/out/fig.png", "return_image": true, "artboard_only": true}} Refuse rather than overwrite an existing file: {"params": {"file_path": "C:/out/fig.png", "format": "png", "overwrite": "fail"}} Keep the old file and write beside it: {"params": {"file_path": "C:/out/fig.png", "overwrite": "version"}}

NOTES:

  • artboard_only=True clips export to artboard; a pre-check warns if nothing is on it

  • Native PDF is temporarily disabled because saveAs changes source state

  • Native SVG is temporarily disabled after a measured source-association failure

  • return_image returns base64 image bytes as ImageContent for visual verification

  • An existing file is resolved before dispatch per overwrite, so Illustrator is never asked to confirm a replacement. Its Replace Files prompt is modal and would hang the host until a person clicked it

  • overwrite='replace' retains a unique sibling backup until completion

  • Unknown completion retains the backup; use illustrator_job_status with finalize_export=true on the returned jobId after completion is established

  • Backup ownership is in-memory; after server restart use manual recovery

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already indicate destructive=true and readOnly=false, but the description adds crucial behavioral detail: exporting writes a file and overwrites existing ones, the overwrite modes avoid Illustrator's modal prompt, and the backup/recovery nuances. It also explains why SVG/PDF are refused (source-association failure, state changes). This goes well beyond the annotations and warns of side effects.

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 deliberately structured with sections (contract, when-to-use, examples, notes). The opening sentence is a clear summary, and subsequent sections add necessary depth. Every paragraph serves a purpose; for a tool with this complexity (overwrite modes, async job handling, format restrictions), the length is justified. It is not redundant or padded.

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 the tool's complexity—multiple formats, overwrite policies, async job completion, artboard options, and destructive nature—the description covers all critical aspects: format refusal rationale, overwrite behavior with backup, return_image usage, artboard clipping, and even how to finalize via illustrator_job_status. The agent has everything needed to call it correctly and safely.

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

Parameters3/5

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

The schema itself provides thorough descriptions for every parameter (scale, format, overwrite, return_image, etc.), so the schema coverage is high. The description adds marginal semantic value—it reinforces format restrictions and explains the overwrite behavior in the notes, but most parameter meaning is already in the schema. The examples illustrate usage but don't redefine semantics. Baseline 3 applies.

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 statement: 'Export the active document to PNG or JPG. Native SVG and PDF are refused.' This names the exact verb, resource, and acceptable formats, and explicitly differentiates from sibling tools like illustrator_observe (which returns images inline for viewing) and import tools. The purpose is unmistakable.

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?

A dedicated WHEN TO USE section provides explicit guidance: it states when to use (raster export, visual feedback) and when not to (NOT for looking at work in progress) and names the alternative tool (illustrator_observe) with its advantage. It also gives concrete examples covering normal export, refusal cases, and overwrite strategies, leaving no ambiguity about selection.

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