Skip to main content
Glama
Bieuulls

Illustrator AI & MCP Control

by Bieuulls

illustrator_execute_task

Destructive

Execute structured batches of Illustrator operations to create, modify, and organize vector elements, layers, and styles in one validated request.

Instructions

Execute structured SOC operations or a compatibility callback pipeline.

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

WHEN TO USE:

  • Prefer params.batch for all 48 JSX operations; the nine pilot models retain stronger nested typing. {operation_index}

  • Compatibility params.payload remains supported for ordered mixed sequences under payload.params.ops; it uses the same static validation pipeline.

  • The payload route also accepts compatibility callback hooks: collect_fn selects a callable, while compute_fn and apply_fn are arbitrary ExtendScript callback bodies. They have the same File, Folder, and OS access as raw ExtendScript, so this tool is open-world while they exist.

  • Provide exactly one of params.batch or params.payload.

EXAMPLES: One structured operation (the preferred form): { "params": { "batch": { "operations": [ { "task": "element_create", "params": { "type": "rect", "x": 40, "y": 40, "width": 200, "height": 120, "fill": { "r": 0, "g": 150, "b": 136 } } } ] } } } Several operations, stopping at the first failure: { "params": { "batch": { "operations": [ { "task": "element_create", "params": { "type": "ellipse", "x": 0, "y": 0, "width": 60, "height": 60, "id": "dot" } }, { "task": "element_modify", "targets": { "type": "id", "ids": [ "dot" ] }, "params": { "x": 120 } } ], "stopOnError": true } } } Validate a batch without applying it: { "params": { "batch": { "operations": [ { "task": "element_create", "params": { "type": "star", "x": 100, "y": 100, "numPoints": 5, "outerRadius": 40, "innerRadius": 18 } } ], "mode": "validate" } } } Create a layer through the compatibility route: {"params": {"payload": {"task": "layer_create", "params": {"name": "Background"}}}} Create a layer, then a rectangle on it, in one batch: { "params": { "batch": { "operations": [ { "task": "layer_create", "params": { "name": "Background" } }, { "task": "element_create", "params": { "type": "rect", "x": 0, "y": 0, "width": 800, "height": 600, "layer": "Background" } } ], "stopOnError": true } } }

TARGET SELECTORS: {type: "selection"} — current selection (default) {type: "layer", layer: "Layer 1"} — all items on layer {type: "query", itemType: "PathItem", pattern: "axis_*"} — pattern match {type: "all", recursive: true} — all items in document {type: "id", ids: ["A1", "A2"]} — stable MCP ID targeting

OPTIONS: batch.stopOnError and payload.options.stopOnError stop after the first failed operation. They preserve earlier edits and do not provide transactional rollback. payload.options.mode and stopOnError are honored by the default structured SOC route. trace is honored by both structured and callback routes. payload.options.kind, skipCollect, minCreated, idPolicy, and the deprecated assignIds alias are callback-pipeline controls. The default SOC route forces kind="creation", resolves per-op targets, and has no apply callback. retry, idempotency, and timeout are compatibility fields that still validate but are currently ignored by this executor. It does not call the retry wrapper or use payload.options.timeout as its host deadline. dryRun — NOT SUPPORTED; rejected before execution. It could not prevent mutation (batch ops run during compute) and reported otherwise. To inspect without changing anything, use query_items, preflight_check, or get_document. rollback, snapshot, and recompute — NOT SUPPORTED; enabled requests are rejected before host dispatch. Explicit false/null disabled forms remain valid. Unknown task, payload, batch, operation, option, and nested retry fields are rejected. Use stopOnError instead of the internal strict spelling.

RESULT: structuredContent carries the canonical result object: execution status, data, effects, verification, recovery, warnings and truncation. isError reflects the EXECUTION outcome only — a failed or unavailable visual check never turns a successful edit into a tool error.

NOTES:

  • With the default SOC executor (no custom compute function), the server injects payload.options.kind="creation" so outer collection is skipped while each operation resolves its own targets. Callers may omit kind.

  • Both SOC routes validate the complete operation tree before dispatch. Availability, required fields, broad types, enums and unknown keys are checked from the shared contract. Pilot nested models remain stronger.

  • Path handles and mirror modifiers normalize once for single operations, batch operations and compound children. Runtime fields and targets stay deferred; stopOnError does not promise rollback or successful assertions.

  • Static request limits: 1000 operations, JSON depth 32, selector depth 16, 10000 expanded items and 100000 expanded geometry points. Dynamic values remain subject to host limits when evaluated.

  • For boolean ops use illustrator_path_boolean, not execute_task

  • For raw SVG path data use illustrator_path_import_svg

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

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?

The description states the CONTRACT line (readOnly=False, destructive=True, idempotent=False, openWorld=True) which matches and expands on the annotations. It discloses critical behavioral traits beyond the annotations: dryRun is NOT SUPPORTED and rejected because it could not prevent mutation; rollback/snapshot/recompute are rejected; unknown fields are rejected; isError reflects execution outcome only. It also explains the open-world risk from callback functions having File/Folder/OS access. This is far beyond what annotations provide.

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 extremely long, but it is exceptionally well-structured with clear sections (CONTRACT, WHEN TO USE, EXAMPLES, TARGET SELECTORS, OPTIONS, RESULT, NOTES) and front-loads the most critical facts (purpose, contract, usage guidance) early. Every section earns its place given the complexity of the tool; however, it could be trimmed without losing essential content (e.g., some NOTES details are redundant with OPTIONS). A 4 reflects its length, but the structure prevents it from being unwieldy.

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?

The description covers every aspect an agent needs to call this tool correctly: the two input routes, target selectors, option semantics (including unsupported ones), static request limits, validation behavior, result structure, and alternatives. It explains the relationship between batch and payload, and how callback pipelines differ. Given the enormous schema and no output schema, the description leaves no major gap.

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?

Though the schema coverage is 0%, the description compensates comprehensively. It explains the meaning of the top-level params.batch and params.payload, details options like stopOnError, mode, dryRun (unsupported), retry/timeout (ignored), and clarifies which options apply to which route. It even provides examples of parameter structures. This is a textbook case of description carrying the full semantic weight.

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 opening line 'Execute structured SOC operations or a compatibility callback pipeline' states a specific verb (execute) and a specific resource (SOC operations / callback pipeline). It also distinguishes itself from siblings in the WHEN TO USE section by naming alternatives like illustrator_path_boolean for boolean ops and illustrator_path_import_svg for SVG data, making the tool's scope 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?

The WHEN TO USE section is explicit: 'Prefer params.batch for all 48 JSX operations' and explains when the payload route is appropriate (ordered mixed sequences, callback hooks). It also provides direct exclusions: 'For boolean ops use illustrator_path_boolean, not execute_task' and 'For raw SVG path data use illustrator_path_import_svg'. This gives unambiguous guidance on when to use this tool vs alternatives.

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