Export Photoshop PNGs or Illustrator SVGs from a session to a destination, choosing color or data usage and the export kind.
Export native-depth Photoshop PNG or vector Illustrator SVG by default; PNG24 is explicit.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| usage | No | color | |
| session_id | Yes | ||
| application | Yes | ||
| destination | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| copy | Yes | ||
| document | Yes | ||
| retry_safe | Yes | ||
| session_id | Yes | ||
| operation_id | Yes | ||
| source_sha256 | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is not read-only, non-destructive, and closed-world. The description adds the useful default behavior that Photoshop exports PNG and Illustrator exports SVG unless PNG24 is explicitly requested, but it does not disclose how destination files are handled, whether overwrites occur, or what file-system effects the export has.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted wording. However, terms such as 'native-depth' and 'PNG24' are compressed to the point of ambiguity, so brevity comes at some cost to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters with zero schema description coverage, and the description leaves most of them unexplained. Although an output schema exists and annotations cover safety hints, the definition is still missing key behavioral and parameter context needed to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for five undocumented parameters. It hints at the relationship between application and default format selection, but it does not explain destination, usage, session_id, or the exact meaning of the kind enum and PNG24 behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (export) and identifies the default output formats for Photoshop and Illustrator. It is understandable at a high level, but it does not clearly distinguish this tool from siblings such as after_effects_render or explain the full scope of the export operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a default format behavior but gives no explicit guidance on when to use this tool versus alternatives. It does not cover when to choose PNG24 explicitly, when to prefer vector SVG, or any prerequisites for exporting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.