Skip to main content
Glama
Sign In
PaintPilot

PaintPilot

by lavalava45
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

photoshop_guard_art_director

Persist Director plans and evidence-bound assessments for a verified art run, and process review, interrupt, or completion actions while enforcing required evidence gates.

Instructions

Persist Director plans and evidence-bound assessments for a verified art-run document; use photoshop_guard_resume(document_id, director_fields) to read saved fields and photoshop_guard_status for readiness. review requires directive and issues/updates tasks; interrupt requires an allowed reason and marks an active directive for replanning; complete requires final_comparison and pre_final_hostile_review against the exact current frame and rejects outstanding completion blockers. This closes a satisfied directive, not the whole painting, and does not certify painted quality. directive carries style/strategy and observed value/refinement assessments; observed claims need current registered image evidence. anchor_decision explicitly manages classified whole-frame anchors; capture_restore_state additionally reads pinned layer/selection state. incomplete_hypothesis records a bounded experiment with rollback and review horizon; its resolution is explicit. whole_image_glance supplies due whole-frame/relationship review, never an invented pass. Writes Guard state without painting; optional anchor capture reads Photoshop. Returns ok, bounded document/Director state and next guidance. Payload errors return guard_art_director_contract_invalid with issues; state/evidence failures return guard_art_director_rejected. Retrieve saved fields and correct the request; do not replay painting or bypass evidence gates.

Input Schema

NameRequiredDescriptionDefault
actionYesreview: requires directive and updates plans/tasks; interrupt: requires reason for an active directive; complete: requires final_comparison and pre_final_hostile_review and passing completion gates.
detailNoOptional audit/artistic guidance for an interrupt.
reasonNoRequired enumerated structural reason for action=interrupt; explanatory detail alone does not authorize an interrupt.
directiveNoRequired for action=review: durable goal, style/strategy, hypotheses/tasks and value/refinement assessments.
document_idYesPositive id of the verified document with the art run and Director state being updated.
anchor_decisionNoWhole-image anchor decision.
final_comparisonNoRequired for action=complete.
whole_image_glanceNoIndependent whole-image observation only at a stage, global-change, or final boundary.
incomplete_hypothesisNoBounded artistic hypothesis that may temporarily lose a named quality but must retain a real rollback anchor and finite review horizon.
global_brief_assessmentNoBounded whole-brief evaluation.
pre_final_hostile_reviewNoRequired for action=complete.
incomplete_hypothesis_resolutionNoExplicit outcome for the existing bounded hypothesis: resolved, accepted or reversed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.8.3
    • addedInput schema / properties / action / description
      Added value: +"review: requires directive and updates plans/tasks; interrupt: requires reason for an active directive; complete: requires final_comparison and pre_final_hostile_review and passing completion gates."
    • addedInput schema / properties / directive / description
      Added value: +"Required for action=review: durable goal, style/strategy, hypotheses/tasks and value/refinement assessments."
    • addedInput schema / properties / document_id / description
      Added value: +"Positive id of the verified document with the art run and Director state being updated."
    • addedInput schema / properties / incomplete_hypothesis_resolution / description
      Added value: +"Explicit outcome for the existing bounded hypothesis: resolved, accepted or reversed."
    • addedInput schema / properties / reason / description
      Added value: +"Required enumerated structural reason for action=interrupt; explanatory detail alone does not authorize an interrupt."
  2. First observedv1.8.0-preview.1

TDQS

A4.6/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 discloses key side effects: 'Writes Guard state without painting; optional anchor capture reads Photoshop.' It also states scope limitations ('closes a satisfied directive, not the whole painting, and does not certify painted quality'), evidence gates, and exact error codes for contract and state/evidence failures.

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 purpose and action rules. It could be more scannable with bullet points, but every sentence contributes information and there is little redundancy.

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 complex 12-parameter tool with nested objects and no output schema, the description covers purpose, action semantics, side effects, return behavior, and error handling. Nothing critical for correct invocation appears to be missing.

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 12 parameters in detail. The description adds some cross-parameter context (e.g., how actions map to required fields), but much of it repeats existing schema prose, such as the anchor_decision and capture_restore_state explanations. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with a specific verb and resource: 'Persist Director plans and evidence-bound assessments for a verified art-run document.' It immediately distinguishes itself from sibling read tools by naming photoshop_guard_resume and photoshop_guard_status for retrieval/readiness, so an agent can tell what this tool uniquely does.

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?

It gives explicit when-to-use rules for each action ('review requires directive and issues/updates tasks', 'interrupt requires an allowed reason', 'complete requires final_comparison and pre_final_hostile_review'). It also names alternatives for reading saved fields and checking readiness, and warns against replaying painting or bypassing evidence gates.

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