Skip to main content
Glama

plan_edit

Read-only

Hire an editor for an open photo: a persona with a whole point of view and its own styles, not a filter. Use it when someone asks for a persona, an editor, a style or a photographer's eye, or just wants the photo to look great. Each editor (documentarian, cinematographer, art_director, printmaker, feed_creator) has a creed, ethics (what they will and will not change), frame habits, a method stage by stage with recipes in this server's tools, styles, and a voice. This returns all of that for the photo, the critic's read of where it starts (attention, subject, light, mood, recipe), and the rules of an optional job (wedding, portrait, real_estate, product, food, pet, event). After this, every edit on the photo returns the editor's notes on what the edit changed, and review_edit gives the full critique. Without editor it lists the cast ranked for this photo, best fit first (or, without image, just the cast); when the user named no editor, choose one yourself from what the user said and that ranking, and say which and why. Mark the subject with subject [x1, y1, x2, y2] in image pixels (and up to 6 named story elements to keep) for much better notes; without it the critic guesses from the strongest attention. Calling it again on the same photo keeps the measured start (restart true starts over). Changes nothing in the photo.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "plan_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobNoWhat the photo is for; its rules hold whichever editor does it.
imageNoImage id, as returned by open_photo.
storyNoStory elements the edit must keep in the frame.
styleNoOne of the editor's own styles (each editor lists theirs); default: their first.
editorNoWhich editor to hire. Omit to see the cast and how each suits the photo.
restartNoMeasure the start again from the photo as it is now.
subjectNoThe subject's box [x1, y1, x2, y2] in image pixels.
deliverableNoWhere it will run, in a few words ("instagram feed", "a 40x50 print", "web banner").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description confirms 'Changes nothing in the photo.' Beyond that it discloses genuine state behavior the annotations cannot express: every subsequent edit on the photo will return the editor's notes, and calling again keeps the previously measured start unless `restart` is true. That explains the idempotentHint=false annotation rather than merely restating it.

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

Conciseness3/5

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

The purpose is correctly front-loaded in the first sentence, but the middle is a single breathless sentence chaining creed, ethics, frame habits, method, styles, voice, critic read and job rules. The parenthetical cast list and nested clauses ('or, without `image`, just the cast') make it slow to scan, and several ideas could be separated or trimmed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With eight optional parameters, no output schema and persistent cross-call state, the description carries real weight and largely succeeds: it describes what is returned, how the editor is chosen, and what happens on repeat calls. The one gap is that the shape of the returned 'cast ranking' is described only qualitatively, so the agent cannot anticipate the ordering criteria beyond 'best fit first'.

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 description coverage is 100%, so the baseline is 3, but the description adds consequence-level meaning the schema does not: supplying `subject` (and up to six named `story` elements) yields 'much better notes' while omitting it makes the critic guess from the strongest attention; `style` defaults to the editor's first; `restart` re-measures from the current photo. It does not explain the enum values themselves, which the schema handles.

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?

The opening sentence states a concrete verb and resource: 'Hire an editor for an open photo', and immediately disambiguates it from a filter. It goes on to enumerate exactly what the call returns (creed, ethics, frame habits, method, styles, voice, critic's read, job rules) and names the sibling that does the complementary job (review_edit gives the full critique). An agent can distinguish this from apply_look or editor_studio without opening any schema.

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

Usage Guidelines4/5

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

It gives explicit trigger language ('when someone asks for a persona, an editor, a style or a photographer's eye, or just wants the photo to look great') and handles the ambiguous case by instructing the agent to pick an editor itself from the ranked cast and explain the choice. It also routes the follow-up critique to review_edit. What it lacks is a clear when-not-to-use or a named alternative for the case where the user only wants a mechanical adjustment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources