Skip to main content
Glama
lazyq666

Illustrator MCP Unified

by lazyq666

validate_cards

Destructive

Reopens saved AI outputs to check card, layer, text, image, and path correspondence and optionally export artboard previews, using the prepared plan so packaged link paths match.

Instructions

Independently reopen a saved, closed AI output, check card/layer/text/image/path correspondence, and optionally export artboard previews without the clipboard. This tool does not perform visual judgment. Use the prepared plan from get_batch_status so packaged link paths match.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cardsYes
output_pathYes
preview_directoryNo
expected_sublayersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.0-local.1

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and openWorldHint=false, lowering the bar. The description adds useful boundary context ('does not perform visual judgment', 'without the clipboard'), but it never explains the destructive aspect (e.g. that reopening can alter the current document state), which is the main behavioral risk an agent should know.

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?

Three compact sentences with the primary action front-loaded and the prerequisite stated last. It is reasonably sized for the tool's complexity, with only mild density in the opening clause.

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

Completeness2/5

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

For a destructive, 4-parameter tool with a fully undocumented nested schema and no output schema, the description leaves major gaps: no parameter guidance, no explanation of the destructive behavior, and no statement of what the validation returns or how to act on it.

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?

Schema description coverage is 0% across 4 parameters including nested card structures, so the description must carry the burden. It only obliquely hints at cards correspondence and artboard preview export, clarifying neither the required output_path/cards nor the optional preview_directory/expected_sublayers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific multi-part verb (reopen, check correspondence, optionally export previews) on a clear resource (a saved, closed AI output). It is distinguishable from siblings batch_cards and get_batch_status, though the sentence is dense and bundles several operations.

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?

It gives explicit context and a prerequisite: 'Use the prepared plan from get_batch_status so packaged link paths match,' which tells the agent the correct sequencing. It stops short of stating when NOT to use it versus batch_cards, so it falls short of a 5.

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