ArtCraft and PhotoCraft CLI: how do you automate it with CLI and MCP?

PhotoCraft exposes a command-line binary, a JSON control channel and an MCP server, which means one edit definition can drive a single file, a whole directory or an agent conversation. Start with one command on one file, move to a JSON action set for a batch, then expose MCP only once the action set is stable.

Install the CLI build All guides

Written against the build verified on 2026-10-13.

The order to learn these in

Three surfaces, one escalation ladder. The CLI is for a repeatable single operation. The JSON action file is for the same operation across many files, and it is where you stop typing parameters. MCP is for letting a program decide which action to run, and it should be the last thing you adopt, because it inherits every mistake in your action definitions at machine speed.

One command, one file

photocraft-cli run input.psd \ --cmd filter.sharpen.smartSharpen \ --params '{"amount":80}' \ --out output.png

photocraft-cli --help

The shape that matters is the separation of the three arguments: which file, which operation, which parameters. Because parameters are a JSON value, you can build the same call from a script instead of typing it, which is what makes the step to batching small rather than a rewrite.

Batch a directory from an action file

photocraft-cli batch --actions grade.json --in ./raw --out ./graded

An action file describes a sequence rather than a single call: which adjustments apply, in what order, with what parameters. Treat it as code. Put it in version control next to the project it belongs to, name it after the job rather than the tool, and test it against three files before pointing it at three hundred.

Handing the editor to an agent

photocraft-cli mcp

This is the part that changes the shape of a workflow. Instead of describing a job to a person, an agent can execute it: open a file, apply a known action set, export, report what it did. Two guards are worth writing down before you let anything run unattended. First, restrict the agent to named action files rather than arbitrary parameters, so a confused model cannot invent a destructive operation. Second, keep the input directory read-only and let output land in a fresh folder; the failure mode of automation is not a bad edit, it is a bad edit applied to everything.

Making the batch trustworthy

What breaks first

• Parameter names, because the project is alpha and the CLI surface is still moving. Pin the version you tested.
• Colour management assumptions, because a headless run has no screen to argue with.
• Font-dependent text layers, which substitute differently when no interactive session resolves them.
• Any workflow that writes back over its own input; the second pass then grades an already graded file.

Write the action file before you write the loop. That ordering sounds obvious and is regularly inverted in practice, and it matters because a JSON definition can be reviewed, versioned and reused, while a shell loop tends to become a one-off line nobody can audit six months later when the output looks different from last time.

Store the action file, the build version and one sample input together. Three artefacts, and a pipeline that ran in the spring can be reproduced in the autumn rather than re-invented. That is the whole difference between automation as a convenience and automation as an asset.

Keep a changelog of your own action files. When a delivery comes back with a note that the whites look different from last month, the answer is rarely in the editor and almost always in the definition: a parameter that moved, a step that was reordered, a build upgraded between two runs. Three artefacts in version control, the definition plus the build version plus one sample input, and the question has an answer instead of a theory.