Exports the current view of the active Photoshop document as a PNG file to an absolute path, letting AI agents save check frames for the user to review.
Export the current view of the active document as a PNG file to path (absolute). Use it for check frames the user will look at; name the file descriptively.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | absolute .png path | |
| quality | No | for JPEG/WebP only |
Changes observed during successful MCP inspections.
v1.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and only partially does so. It discloses format and that `path` must be absolute, but says nothing about overwrite behavior if the file exists, whether the export alters document state or selection, whether an unsaved document matters, or what gets returned on success. These are precisely the details an agent needs before calling an unannotated file-writing tool.
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?
Two front-loaded sentences, the core operation first and the practical advice second, with no filler. Slightly less tight than a 5 because 'name the file descriptively' is soft guidance that competes for attention with the missing behavioral details.
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?
Low complexity (two parameters, one required) means the description does not need to be long, and there is no output schema to compensate for. Still, it omits what the tool returns and how it differs from the export/preview siblings, leaving real gaps for an agent choosing among them.
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 100%, so the baseline is 3. The description's '(absolute)' restates what the schema already says for `path`, and it says nothing about `quality`, which the schema notes is for JPEG/WebP only — clarifying that it is ignored for PNG output would have been genuine added value.
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?
States a specific verb (export), a specific resource (current view of the active document), and the output format (PNG file at `path`). An agent understands the operation immediately. However, it does not differentiate itself from close siblings in the list such as photoshop_export_as or photoshop_get_preview, which is the one thing keeping this from a 5.
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?
'Use it for check frames the user will look at' gives a purpose context, so usage is implied rather than absent. But no alternative is named and no when-not condition exists — an agent cannot tell from this text why it should pick ps_export_frame over photoshop_export_as or photoshop_get_preview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.