Skip to main content
Glama
alisaitteke

Photoshop MCP Server

by alisaitteke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

photoshop_recipe_batch_mockup_replace

Batch-render a mockup PSD for every asset image by replacing a named Smart Object and exporting a flattened JPEG per variant, preserving the mockup's perspective.

Instructions

Iterate a directory of asset images, replace the contents of the named Smart Object in the active mockup PSD for each asset, and export a flattened JPEG per variant. The mockup's perspective/warp on the Smart Object is preserved.

Use when: the user has a mockup PSD and wants to render it once per design asset (logos, screens, product photos). Do NOT use when: the asset is not a single layer (use photoshop_place_image manually) or when the active document has no Smart Object with the requested name.

Returns: { ok, summary, output_paths, details: { variants: [{ source_asset, output_path }] } }.

Preconditions: active document containing a Smart Object layer named exactly as requested; assets_dir must exist and be readable. Side effects: writes one JPEG per asset; the active mockup PSD ends up with the LAST asset placed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qualityNoJPEG quality on the Photoshop 1-12 scale. Default 10.
assets_dirYesAbsolute path to the directory containing asset files. Subdirectories are NOT recursed. Allowed extensions: jpg/jpeg/png/tif/tiff/psd/psb/webp.
document_idNoOptional Photoshop document id from photoshop_get_state / photoshop_list_documents. When set, the tool activates that document before running so a UI tab switch cannot retarget the edit.
smart_object_layer_nameYesExact name of the Smart Object layer in the active document. Case-sensitive.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and handles it well: it discloses side effects (writes one JPEG per asset and leaves the last asset placed in the active PSD), preconditions, and return shape. It also notes that the mockup's perspective/warp is preserved, which clarifies an important behavioral guarantee.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized into clear labeled sections: usage conditions, exclusions, returns, preconditions, and side effects. Every sentence contributes information an agent needs, and the key action is front-loaded.

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?

Despite having no output schema, the description specifies the return structure with ok, summary, output_paths, and details. It covers when to use, when not to use, prerequisites, side effects, and the persistence of mockup perspective, making the tool fully callable by an agent.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters and their constraints. The description reiterates the overall batch role but does not add meaningful parameter-level semantics beyond what the schema provides.

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?

States a specific verb and resource: iterate a directory of assets, replace Smart Object contents in a mockup PSD, and export flattened JPEGs per asset. It clearly distinguishes this from sibling tools by framing it as a batch mockup workflow with the perspective/warp preserved.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use when' and 'Do NOT use when' guidance, including the exact alternative (photoshop_place_image) for single-layer assets. It also lists preconditions for the active document and assets_dir, so an agent knows the required context before calling.

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