Skip to main content
Glama

Árbol de capas

ps_layers

List Photoshop layers with type, visibility, opacity, blend mode, masks, effects, text, and smart objects. Limit depth or drill into a group to inspect specific layers.

Instructions

Lista las capas con tipo, visibilidad, opacidad, relleno, modo de fusión, contorno, máscaras, efectos activos, texto y objetos inteligentes (vinculado/incrustado). depth limita los niveles; group baja a un grupo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docNoDocumento (nombre o índice desde 1). Por defecto el activo.
rawNo
depthNo
groupNoCapa: nombre, 'Grupo/Capa', id numérico o {id|name|path|index|nth}
includeHiddenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. 'Lista' implies a read-only, side-effect-free operation, and it discloses depth-limiting and group-descent behavior. However, it does not state that the call is non-mutating, nor address output size/performance for large documents.

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?

Two sentences, front-loaded with what is listed before the parameter behavior. The attribute enumeration is long but earns its place given there is no output schema. Minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-param tool with no annotations and no output schema, the description does well explaining the returned fields and two of the parameters. But raw and includeHidden are undocumented and the read-only nature is only implied, leaving gaps an agent must guess at.

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 only 40% (doc and group documented), so the description must compensate. It does add meaning for depth and group ('baja a un grupo') beyond the schema, but leaves raw and includeHidden completely unexplained in both schema and description.

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 (Lista) and resource (capas), and enumerates the attributes returned (tipo, visibilidad, opacidad, relleno, modo de fusión, contorno, máscaras, efectos, texto, smart objects). This is clearly a layer-tree listing. However, it does not differentiate itself from siblings like ps_layer_info or ps_document_info, which an agent must infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining depth (limits levels) and group (descends into a group), suggesting when those parameters matter. But there is no explicit when-to-use vs. ps_layer_info, no when-not guidance, and no mention of prerequisites such as an open document.

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