Skip to main content
Glama
Bieuulls

Illustrator AI & MCP Control

by Bieuulls

illustrator_preflight_check

Read-onlyIdempotent

Validate an Adobe Illustrator document before export. Detect out-of-bounds items, zero-size objects, empty text frames, and locked layers without modifying the file.

Instructions

Perform observational validation on the active document.

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

WHEN TO USE:

  • Before export to catch common issues

  • Validating document state after a series of modifications

KEY CONCEPTS: Checks for: items outside artboard bounds, zero-size items, empty text frames, locked layers/items. Does NOT modify the document.

EXAMPLES: Check supplied publication thresholds: { "params": { "publication": { "output_width_mm": 89, "min_font_pt": 5, "min_stroke_pt": 0.25, "min_image_ppi": 300 } } } Check the active artboard before exporting: {"params": {}} Check one artboard, counting any overlap as on-artboard: {"params": {"artboard_index": 0, "policy": "intersects"}}

NOTES:

  • Returns ok=true only when the scan ran and found no non-info issues

  • Locked layers/items are reported as info and do not fail the check

  • If the scan cannot be read back, the result is an error with diagnostics.scan_status='unavailable' — never a passing check

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

The CONTRACT line mirrors annotations (readOnly=True, destructive=False, idempotent=True, openWorld=False) and adds precise behavioral details beyond annotations: locked items are reported as info, ok=true only for no non-info issues, and an error with scan_status='unavailable' if readback fails. This enriches understanding of return semantics and edge cases without contradicting the 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?

The description is well-structured with clear section headers (CONTRACT, WHEN TO USE, KEY CONCEPTS, EXAMPLES, NOTES) and front-loaded purpose. It is moderately long but each sentence carries useful information, such as error handling and locked-item behavior. The organization makes it scannable and efficient, though it could be slightly trimmed without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a validation tool with no output schema, the description covers essential return semantics (ok flag, info vs. non-info issues, error condition with scan_status). The EXAMPLES illustrate realistic calls, and the 'NOTES' section clarifies behavior around locked items and unavailable scans. Given the tool's complexity (many optional parameters and nested thresholds), this is adequately complete, though it doesn't spell out the full output structure.

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

Parameters2/5

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

The description does not describe parameters at all; schema_description_coverage is 0%. While the input schema contains detailed descriptions for each property, the tool description only gives examples that illustrate usage patterns (e.g., publication thresholds, artboard_index with policy). It does not add semantic meaning beyond what the schema already provides, and the lack of parameter paragraphs in the description is a 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?

The description opens with a clear, specific verb and resource: 'Perform observational validation on the active document.' It enumerates concrete checks (items outside artboard, zero-size items, empty text frames, locked layers/items) and explicitly states it does not modify the document. This clearly distinguishes it from sibling tools like illustrator_query_items or illustrator_execute_script.

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 provides explicit contexts: before export and after a series of modifications. It gives clear scenarios for invocation but does not list exclusions or alternative tools. It stops short of saying 'do not use when...' or naming a specific sibling to prefer, which would justify a 5.

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