Skip to main content
Glama
lavalava45

PaintPilot

by lavalava45
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

photoshop_guard_status

Checks guard readiness, pending review or acknowledgement debts, active jobs, and uncertain work, returning the next required action or solving requested construction geometry.

Instructions

Inspect Guard readiness, pending review/ack debts, active jobs and uncertain work. Use photoshop_get_state for Photoshop/UI state or photoshop_guard_lint_next_pass for lint alone. No arguments returns global status; document_id scopes readiness, next_pass adds candidate lint, and construction_model or construction_ref selects a geometry solve instead. Returns readiness/next_required_action or solved geometry; geometry is not image proof. Does not paint; never replay uncertain mutations. Status may reconcile missing-document journal state; diagnostic_timing_marker writes benchmark metadata. Keep the established local Photoshop workflow unless its route is unavailable.

Input Schema

NameRequiredDescriptionDefault
next_passNoUse the exact next_pass schema published by photoshop_guard_cycle_auto; validation returns all field corrections without mutation.
document_idNoOptional document scope for readiness. With next_pass, must match its document_id; otherwise the candidate supplies the scope. Does not switch the active Photoshop document or authorize a mutation.
construction_refNoSolve a completed durable model by document_id/model_id and include retained geometry review state. Choose this or construction_model; neither can be combined with next_pass or diagnostic_timing_marker.
construction_modelNo
diagnostic_timing_markerNoBenchmark-only: append a continuation timing marker for operation_id/phase and return the recorded marker; may also include next_pass lint. Omit for ordinary readiness checks.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.8.0
    • addedInput schema / properties / construction_ref / description
      Added value: +"Solve a completed durable model by document_id/model_id and include retained geometry review state. Choose this or construction_model; neither can be combined with next_pass or diagnostic_timing_marker."
    • addedInput schema / properties / diagnostic_timing_marker / description
      Added value: +"Benchmark-only: append a continuation timing marker for operation_id/phase and return the recorded marker; may also include next_pass lint. Omit for ordinary readiness checks."
    • changedInput schema / properties / document_id / description
      Previous value: -"Optional read-only document scope. Unrelated invalid scene geometry remains validated by its own document operations; global status stays unchanged."New value: +"Optional document scope for readiness. With next_pass, must match its document_id; otherwise the candidate supplies the scope. Does not switch the active Photoshop document or authorize a mutation."
  2. First observedv1.8.0-preview.1

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the safety burden and discloses important side effects: it does not paint, never replays uncertain mutations, may reconcile missing-document journal state, and diagnostic_timing_marker writes benchmark metadata. It is still somewhat dense and does not fully clarify all side-effect boundaries across every mode, but it provides strong behavioral context beyond the schema.

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 front-loaded with the core purpose and packs necessary mode-routing and behavioral details into a dense paragraph. It is longer and more clause-heavy than ideal, but most sentences carry relevant information for this complex multi-mode tool.

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?

For a five-parameter tool with no output schema and complex nested geometry inputs, the description gives enough context to select the correct mode and understand the main return categories: readiness/next_required_action or solved geometry, with the caveat that geometry is not image proof. It could be more explicit about exact output structure, but the core invocation context is covered.

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 already 80%, and the description adds useful mode semantics: document_id scopes readiness, next_pass adds candidate lint, and construction_model or construction_ref selects a geometry solve instead. It explains key parameter interactions and constraints, though it does not detail every nested field or the diagnostic phase semantics.

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 states a specific verb and resource: inspect Guard readiness, review/ack debts, active jobs, uncertain work, and geometry solve status. It explicitly distinguishes this from photoshop_get_state and photoshop_guard_lint_next_pass, so an agent can tell when this tool is the right status surface.

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 routing: use photoshop_get_state for Photoshop/UI state and photoshop_guard_lint_next_pass for lint alone. It also explains mode selection by argument: no arguments for global status, document_id for scoped readiness, next_pass for candidate lint, and construction_model or construction_ref for geometry solve.

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