Skip to main content
Glama
Bieuulls

Illustrator AI & MCP Control

by Bieuulls
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

illustrator_path_boolean

Destructive

Combine or cut Illustrator paths using boolean geometry. Apply unite, subtract, intersect, or xor operations to shape vector artwork, merge forms, and cut holes in fills.

Instructions

Perform boolean operations (subtract, unite, intersect, xor) on paths.

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

WHEN TO USE:

  • Combining shapes (unite), cutting holes (subtract), finding overlaps (intersect)

  • Any shape sculpting that needs boolean geometry

PIPELINE:

  1. Extract geometry from Illustrator paths (ExtendScript)

  2. Flatten Bezier curves if present (Python)

  3. Run boolean operation via Clipper (Python)

  4. Reconstruct result as PathItem or CompoundPathItem (ExtendScript)

  5. Delete originals on success (if delete_originals=True)

EXAMPLES: Unite: {"params": {"operation": "unite", "subject": "body_id", "clip": ["wing_id"]}} Subtract a hole: {"params": {"operation": "subtract", "subject": "plate_id", "clip": ["hole_id"]}}

NOTES:

  • Operates on fill geometry only — strokes are ignored (warning emitted)

  • Simple results produce PathItem; shapes with holes produce CompoundPathItem

  • Each operand is an MCP ID or a selector resolving exactly one path.

  • Untagged paths use handle selectors from query/observe; notes are not stamped.

  • Duplicate/overlapping operands and stale handles are refused before commit.

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?

The description goes far beyond annotations. It declares the CONTRACT (readOnly=False, destructive=True, idempotent=False, openWorld=False), outlines a 5-step pipeline, and details important behaviors: strokes are ignored, result type depends on holes, selectors must resolve exactly one path, untagged paths use handles, and duplicate/overlapping operands are refused. This fully discloses side effects and constraints.

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 structured into labeled sections (CONTRACT, WHEN TO USE, PIPELINE, EXAMPLES, NOTES) that front-load the purpose and then provide procedural and edge-case details. It is longer than average but appropriately so for a tool with this complexity; every section earns its place without redundancy.

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 the operation, use cases, execution pipeline, concrete examples, and important behavioral notes (fill-only, result types, selector constraints, duplicate refusal). There is no output schema, but the description compensates by specifying the expected result types. For a tool of this complexity, nothing essential is missing.

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?

Although the schema already provides rich parameter descriptions (e.g., clip, subject, operation), the description adds practical clarity through examples (Unite, Subtract) and notes about selector resolution and handle behavior. It explains that each operand must resolve to exactly one path, which is critical for correct use, and clarifies the distinction between PathItem and CompoundPathItem results. This exceeds the schema's static 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 precise statement: 'Perform boolean operations (subtract, unite, intersect, xor) on paths.' This identifies the specific verb, resource (paths), and operation set, making the tool's purpose unmistakable. It naturally distinguishes itself from sibling tools (scripting, export, job status, etc.) as the only path-boolean tool.

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?

The 'WHEN TO USE' section explicitly lists common scenarios (combining shapes, cutting holes, finding overlaps) and broad applicability ('any shape sculpting that needs boolean geometry'). It lacks an explicit 'when NOT to use' or named alternatives, but given the tool's unique role among siblings, this is a minor omission.

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