Aprender un estilo

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

With no annotations, the description carries the full burden and does reasonably well: it discloses that it opens and closes PSDs without saving (no mutation of source files) and that it persists a named style plus generates a guide (a durable side effect). It omits permissions, error behavior, and whether an existing style is overwritten, which keeps it short of a 5.

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

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

Front-loads the core action ('Lee ... y aprende el estilo') and puts the file-handling caveat inline rather than in a trailing afterthought. The long enumeration of extracted attributes is dense but each item tells the agent what will be modeled, so it earns its place.

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

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

For a 5-parameter tool with no annotations and no output schema, the description covers the source options, the write side effect, the scope of analysis, and the produced artifacts (named style + guide). It is nearly self-sufficient; only auth/preconditions and failure modes are left out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so the schema already documents docs, name, files, and merge. The description usefully clarifies the two input modes ('abiertos o por ruta', i.e. docs vs files) and that the result is stored 'con nombre', but adds nothing for merge and the undocumented description parameter. Baseline 3 is appropriate.

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

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

States a specific verb+resource: reads one or more PSDs and learns a person's style, then saves it under a name and generates a guide. The enumerated extraction targets (canvas format, palette, typography, effects recipes, layer structure) make the purpose unambiguous. It does not, however, distinguish itself from near-siblings like ps_capture_style or ps_style_set.

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

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

"Úsalo con trabajos terminados de la persona" gives an implied condition for use (finished work, not drafts), which is real guidance. But no alternative tool is named and there is no when-not guidance, so selection among ps_capture_style / ps_style_get / ps_style_set is left to inference.

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