Skip to main content
Glama
Sign In
PaintPilot

PaintPilot

by lavalava45
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

photoshop_get_capabilities

Checks Photoshop version-derived feature flags and UXP bridge reachability to verify installation compatibility and whether the bridge is available for document operations.

Instructions

Report version-derived Photoshop feature flags plus current UXP bridge availability. Use for installation/version compatibility and whether the UXP bridge is reachable; use photoshop_get_version for version alone, photoshop_guard_capabilities for Guard rules/exact command schemas, and photoshop_get_painting_method_capabilities for registered painting methods. Takes no arguments. Reads the detected Photoshop version and probes bridge reachability without painting or changing document state. Returns JSON with version and features, including uxp_bridge_reachable; neural_filters is gated by bridge reachability and the version-derived UXP flag. Feature flags are not proof that a particular document operation will succeed or that Guard permits direct mutation. Detection/probe failures return the structured error response.

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": "photoshop_get_capabilities"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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, the description carries the full burden and does so: it declares the operation is non-mutating ('probes bridge reachability without painting or changing document state'), discloses conditional gating of neural_filters on bridge reachability and the UXP flag, warns that flags are not proof of operation success or Guard permission, and specifies structured error behavior on probe failure.

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?

Purpose is front-loaded and every sentence carries distinct information (routing, side-effect profile, gating logic, caveats, error behavior). Dense but not padded, though the routing sentence is long enough to be a single dense block.

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?

No output schema exists, so the description compensates by naming the return shape ('JSON with version and features, including uxp_bridge_reachable') and the gating rule. Nothing an agent needs in order to call this correctly is missing.

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?

Zero parameters, so the baseline is 4; the description confirms 'Takes no arguments,' which is consistent with the empty schema but adds little beyond it.

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?

States a specific verb and dual resource: 'Report version-derived Photoshop feature flags plus current UXP bridge availability.' An agent can distinguish it from photoshop_get_version and photoshop_guard_capabilities from the description alone.

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?

Explicitly assigns scenarios ('installation/version compatibility', 'whether the UXP bridge is reachable') and names three sibling alternatives with their respective domains, leaving no ambiguity about which tool to pick.

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