Skip to main content
Glama

photoshop_recipe_csv_to_cards

Convert a CSV of variable values into Photoshop data sets, applying each row to an active template PSD to export one image per row for name cards, badges, or certificates.

Instructions

Data-driven graphics batch: convert a CSV file into Photoshop data sets, apply each row to the active template document and export one image per row. "Mail merge for images" — name cards, badges, certificates, personalized banners.

Users often say: csv to images, batch name cards, personalized banners, generate badges from spreadsheet, sertifika bastır.

CSV rules: first row = variable names matching the variables defined in the template PSD (Image > Variables > Define). A cell holding an absolute path to an image file (.png/.jpg/.webp/.tif/.psd) is treated as a pixel-replacement variable.

Use when: the user has a template PSD with variable-bound layers and a CSV of rows. Do NOT use when: the document has no variables defined — define them in Photoshop first (Image > Variables > Define).

Returns: { ok, summary, details: { rows, exported, output_paths, xml_path } }.

Preconditions: active document with variable-bound layers; readable CSV file. Side effects: writes a temp variables XML and one output file per row into output_dir.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoOutput format (default JPEG)JPEG
csv_pathYesAbsolute path to the CSV file (first row = variable names)
output_dirYesDirectory for generated files (created if missing)
document_idYesPhotoshop document id from photoshop_get_state / photoshop_list_documents. Send null or 0 to use the active document. A positive number activates that document before the tool runs. When no document is open, a stale id does not block the call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.33
    • changedInput schema / properties / document_id / description
      Previous value: -"Photoshop document id from photoshop_get_state / photoshop_list_documents. Send null to use the active document. A number activates that document before the tool runs."New value: +"Photoshop document id from photoshop_get_state / photoshop_list_documents. Send null or 0 to use the active document. A positive number activates that document before the tool runs. When no document is open, a stale id does not block the call."
  2. Changed4 schema fields changedv1.7.32
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / document_id / description
      Previous value: -"Optional 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."New value: +"Photoshop document id from photoshop_get_state / photoshop_list_documents. Send null to use the active document. A number activates that document before the tool runs."
    • changedInput schema / properties / document_id / type
      Previous value: -"number"New value: +[
      +  "number",
      +  "null"
      +]
    • changedInput schema / required
      Previous value: -[
      -  "csv_path",
      -  "output_dir"
      -]New value: +[
      +  "csv_path",
      +  "output_dir",
      +  "document_id"
      +]
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare the generic safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), so the description carries real weight and delivers it: preconditions, side effects (writes a temp variables XML plus one output file per row into output_dir), and the return shape. It leaves one notable gap: it never says whether applying rows mutates or saves the active template document, which matters for a non-destructive-hinted write tool.

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?

Long but well-structured with labeled sections (CSV rules, Use when, Do NOT use when, Returns, Preconditions, Side effects), so scannability is high and the core purpose is front-loaded. The 'Users often say' line is slightly padded with a non-English example, but it serves retrieval.

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?

For a multi-parameter batch tool with no output schema, the description supplies the return shape, the CSV contract, preconditions, and side effects, plus clear sibling routing. An agent has everything needed to decide to call it and to prepare valid inputs; only document-mutation behavior is left slightly open.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics not in the schema: the CSV's first row must match variables defined in the template PSD, and cells containing absolute image paths are treated as pixel-replacement variables. It does not expand on format/output_dir behavior specifically, so it stays short of a 5.

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 ('convert a CSV file into Photoshop data sets, apply each row ... export one image per row') and names its scope as a batch/mail-merge operation. This clearly separates it from nearby siblings like photoshop_import_datasets, photoshop_generate_from_datasets, and photoshop_export_as, which an agent could otherwise confuse it with.

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 an explicit 'Use when' condition (template PSD with variable-bound layers plus a CSV of rows) and a matching 'Do NOT use when' exclusion with a remediation path (define variables in Photoshop first). It even lists colloquial user phrasings, which helps the agent route natural-language requests.

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