Skip to main content
Glama
lavalava45

PaintPilot

by lavalava45
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

photoshop_guard_set_priorities

Persist a Photoshop document's whole-frame problem priorities after visual assessment, including scale, severity, status, and dependencies, so Guard blocks finer work until must-fix defects resolve.

Instructions

Persist the document's whole-frame problem priorities after visual assessment; use photoshop_guard_status to inspect readiness and photoshop_guard_lint_next_pass to validate a proposed pass. Writes Guard state without painting. problems supplies the ordinary problem set for this update, matched by stable problem_id; omitted ordinary problems are removed, while unresolved structural defects are retained. Open larger must-fix problems block finer work, and dependencies constrain blocker selection. Each problem needs scale and severity; status defaults to open. Changing an existing open problem's status/scale/severity requires evidence_operation_id from an exact-current visual operation with a verdict. Structural defects require an exact-current Critic finding and cannot be resolved by a priority label. current_stage cannot override the durable painting stage. Returns ok=true, updated document state and next guidance; rejected updates return isError=true with ok=false, code=guard_priority_rejected and message. Recording priorities does not certify image quality.

Input Schema

NameRequiredDescriptionDefault
problemsYesProblem set to persist by stable problem_id. Include ordinary problems to retain; omitted ordinary problems are removed, but unresolved structural defects remain protected.
document_idYesPositive Photoshop document id whose durable Guard priorities are updated; does not activate a document or paint.
current_stageNoOptional stage context. Must agree with an existing durable painting stage; stage transitions belong to guarded visual passes, not priority edits.
evidence_operation_idNoExact-current visual operation with a completed verdict. Required when changing the status, scale, or severity of an existing open perceptual problem; prevents arbitrary blocker dismissal/reclassification.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.8.2
    • addedInput schema / properties / current_stage / description
      Added value: +"Optional stage context. Must agree with an existing durable painting stage; stage transitions belong to guarded visual passes, not priority edits."
    • addedInput schema / properties / document_id / description
      Added value: +"Positive Photoshop document id whose durable Guard priorities are updated; does not activate a document or paint."
    • addedInput schema / properties / problems / description
      Added value: +"Problem set to persist by stable problem_id. Include ordinary problems to retain; omitted ordinary problems are removed, but unresolved structural defects remain protected."
    • addedInput schema / properties / problems / items / properties / hypothesis / description
      Added value: +"Optional explanation or proposed correction for this visual problem; a hypothesis is not evidence that it is resolved."
    • addedInput schema / properties / problems / items / properties / problem_id / description
      Added value: +"Stable non-empty problem identifier, reused when updating the same observed defect."
    • addedInput schema / properties / problems / items / properties / region / description
      Added value: +"Optional human-readable location of the observed problem in the image; does not select or modify Photoshop pixels."
    • addedInput schema / properties / problems / items / properties / scale / description
      Added value: +"Visual scale of the defect. Open larger must-fix defects take priority over finer work; do not relabel scale to bypass a blocker."
    • addedInput schema / properties / problems / items / properties / severity / description
      Added value: +"Correction urgency: must-fix participates in blocking finer work; should-fix and optional retain advisory priorities."
    • addedInput schema / properties / problems / items / properties / status / description
      Added value: +"Problem state; defaults to open. Resolving an existing open perceptual problem requires exact-current verdict evidence; structural defects need Critic review."
  2. First observedv1.8.0-preview.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations present, the description carries the full behavioral burden and does so richly. It discloses that the tool writes Guard state without painting, explains removal and retention semantics for omitted problems, describes evidence requirements, and documents both success and rejection responses including the guard_priority_rejected error code.

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?

The description is dense but front-loaded, with the core purpose and sibling alternatives stated immediately. Every sentence contributes operational detail, though the single-paragraph format is long and could be slightly easier to scan given the tool's complexity.

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?

The tool is complex and lacks annotations and an output schema, so the description must explain behavior and return handling itself. It does this well by covering state persistence semantics, evidence rules, stage constraints, success output, and failure output with an explicit error code.

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 schema already documents each parameter, establishing a baseline of 3. The description still adds meaningful workflow semantics beyond the schema, including that omitted ordinary problems are removed while unresolved structural defects are retained, and that dependencies constrain blocker selection.

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 description names a specific action and resource: persisting the document's whole-frame problem priorities after visual assessment. It also distinguishes the tool from related siblings by pointing to photoshop_guard_status for readiness inspection and photoshop_guard_lint_next_pass for validation. An agent can identify the tool's role without opening another schema.

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?

The description explicitly states when to use it and names alternatives for adjacent tasks: status for inspecting readiness and lint_next_pass for validating a proposed pass. It also lays out critical usage constraints, such as evidence requirements for changing problem state and restrictions around structural defects and current_stage.

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