Skip to main content
Glama

photoshop_get_layers

List layers in the active Photoshop document with kind, visibility, and opacity to inspect document structure before editing.

Instructions

List all layers in the active document with kind, visibility, and opacity.

Use photoshop_get_state for a lighter session summary.

Input Schema

NameRequiredDescriptionDefault
document_idNoOptional Photoshop document id from photoshop_get_state / photoshop_list_documents. When set, the tool verifies that this document is already active and fails closed if another tab is active. It never switches the active Photoshop document automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.0-preview.1

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must carry behavioral disclosure; 'List' implies a read-only operation but that is inference, not statement. It says nothing about cost, result size for documents with many layers, or response shape, though it does at least name the attributes returned.

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

Conciseness5/5

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

Two short sentences with no filler; the core capability is stated first and the disambiguation second. Every clause earns its place.

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 one-optional-param read tool with full schema documentation and no output schema, listing the returned fields is the right compensating detail. The only meaningful gap is that the description does not confirm the operation is read-only or note how large results are handled.

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 coverage is 100% and the single optional document_id is documented thoroughly, including the fail-closed behavior and the fact that it never switches the active document. The description adds no parameter-level meaning beyond that, which is acceptable given the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List all layers in the active document') and enumerates the returned fields (kind, visibility, opacity), which pins down scope. It does not contrast with nearby read tools like photoshop_get_document_info, but it is unambiguously not the state/summary tool.

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?

Explicitly routes the agent to photoshop_get_state when a 'lighter session summary' is wanted, giving a concrete alternative and the condition that selects it. It stops short of stating when not to use this tool (e.g., very large documents), so it is not a full 5.

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