Skip to main content
Glama
jinkeda

Illustrator MCP

by jinkeda

illustrator_execute_script

Destructive

Execute raw JavaScript/ExtendScript in Adobe Illustrator for one-off tasks, prototypes, or direct DOM access not covered by structured tools.

Instructions

Execute raw JavaScript/ExtendScript code in Adobe Illustrator.

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

WHEN TO USE:

  • Single one-off items, quick prototypes, or operations not covered by higher-level tools

  • Full DOM access when structured tools are insufficient

  • Reading document state with custom logic

ABSTRACTION LADDER — prefer higher levels before using raw script: Level 5 — illustrator_path_boolean: boolean sculpt (unite/subtract/intersect/xor) Level 4 — illustrator_execute_task + element_create_batch: batch-create identical shapes Level 3 — illustrator_path_import_svg: import SVG d-string paths Level 2 — illustrator_execute_task + element_create: smooth curves, handles, mirror Level 1 — illustrator_execute_script (THIS tool): raw ExtendScript

DECISION RULES:

  • Subtract/unite shapes — MUST use illustrator_path_boolean

  • Creating >=3 identical shapes — MUST use illustrator_execute_task + element_create_batch

  • setEntirePath with >12 coord pairs — STOP and use smooth:true or illustrator_path_import_svg

COORDINATE SYSTEM:

  • API coordinates use top-left origin with y increasing downward (screen space)

  • ExtendScript expects Y-up internally; use -y when calling Illustrator DOM methods

  • Units: points (1 pt = 1/72 inch)

  • Example: to place at visual position (100, 200), use position = [100, -200]

EXAMPLES: Rectangle: doc.pathItems.rectangle(top, left, width, height) ⚠ width & height must be POSITIVE. Negative height → shape above artboard (invisible). Ellipse: doc.pathItems.ellipse(top, left, width, height) Line: var p = doc.pathItems.add(); p.setEntirePath([[x1,-y1], [x2,-y2]]) Color: var c = new RGBColor(); c.red=255; c.green=0; c.blue=0; shape.fillColor = c; Text: var tf = doc.textFrames.add(); tf.contents = "text"; tf.position = [x, -y]; Grid helpers: artboardGrid(cols, rows), itemsInCell(cell, mode)

ELEMENT DISCOVERY:

  • Use artboardGrid(cols, rows) to partition the artboard into a labeled grid

  • Use itemsInCell(cell, mode) to find items in a specific grid cell

  • Modes: 'containsCenter' (default) or 'intersects'

  • Cell labels follow A1 scheme (letter row + number col, e.g. A1, B3)

MUTATION SAFETY:

  • Each call increments a mutation counter for VLM QA cadence tracking

  • Failed executions auto-decrement the counter to avoid cadence drift

  • Use final_step=true on the last mutation to force a visual checkpoint

NOTES:

  • Every call increments a mutation counter; annotated preview auto-injected at VLM cadence

  • Set final_step=true on the last mutation to force a VLM checkpoint

  • setEntirePath() creates corner points only; set handles after creation

  • ExtendScript can access File/Folder and OS — treat as open-world

SAFETY:

  • __mcp_check() watchdog: call as FIRST line inside every for/while body

  • Never iterate live Illustrator collections if adding/removing items

  • Use __mcp_forEachSnapshot(collection, fn) or __mcp_snapshot(collection) instead

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly=false, destructive=true, idempotent=false, openWorld=true, and the description's CONTRACT line is consistent with them. Beyond that it discloses non-obvious behavior: coordinate-system inversion (Y-down API vs Y-up ExtendScript), the mutation-counter/VLM cadence mechanism, auto-decrement on failure, and that ExtendScript can touch File/Folder/OS. This is substantial added context rather than restating annotations.

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?

Headed sections and front-loaded verb make it scannable, and every block is actionable. It loses a point for redundancy: the mutation counter is explained in MUTATION SAFETY and again in NOTES, and final_step appears twice.

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?

For a powerful, destructive, open-world scripting tool the description covers usage, safety patterns for iterating live collections, coordinate conversion, and worked examples. An output schema exists, so return-value explanation is correctly omitted, and the preview/validation parameters are documented in the schema itself.

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?

The visible schema nests a single 'params' object, and the description adds meaning that the schema cannot convey: the y -> -y coordinate convention, units (points), positive width/height requirement for rectangle, and corner-point-only behavior of setEntirePath. It does not walk through fields like max_ms, max_ops, or includes, but the field-level schema descriptions already cover those, so the description usefully compensates for the outermost-layer coverage gap.

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?

Opens with a specific verb+resource: 'Execute raw JavaScript/ExtendScript code in Adobe Illustrator.' The abstraction ladder and DECISION RULES explicitly name sibling tools (illustrator_path_boolean, illustrator_execute_task, element_create_batch, illustrator_path_import_svg) and state which one wins in each situation, so an agent can distinguish this tool from its neighbors without opening a schema.

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?

WHEN TO USE lists three concrete scenarios (one-offs, full DOM access, custom read logic) and the DECISION RULES give hard 'MUST use X instead' constraints for boolean ops and batch creation. Exclusions and alternatives are explicit rather than implied.

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