Set layer properties

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

The description goes beyond the sparse annotations by disclosing that all values are set statically and that animation should be handled separately. This is a meaningful behavioral trait, though it stops short of explaining what happens if a property already has keyframes or whether changes are reversible.

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?

The description is one efficient sentence that front-loads the primary action and property scope, then adds the key static-versus-animated distinction. Every clause earns its place, and there is no redundant restatement of the name or title.

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 mutation tool with 21 parameters and no output schema, the description gives the essential context: what is changed, that values are static, and the keyframes alternative. It could be more complete by noting behavior around existing keyframes or selecting layers when omitted, but the schema covers selection defaults and the description is sufficient for most invocation decisions.

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?

The input schema already documents many parameters with units and examples, and the description adds a useful category-level summary such as 'timing' and 'switches'. However, with 21 parameters and only 62% schema coverage, the description does not fully compensate for the undocumented parameters like anchorPoint, adjustmentLayer, or motionBlur, though many are inferable from their names.

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?

The description states a clear action ('Change'), a specific resource ('a layer'), and enumerates the affected property categories: name, transform, timing, parenting, blend mode, and switches. It also distinguishes itself from ae_set_keyframes by clarifying that values set here are static, which is exactly the kind of differentiation an agent needs.

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?

The description explicitly instructs the agent to use ae_set_keyframes when animation is desired instead of static values. This is a clear when-to-use signal for the most important alternative, though it does not address possible overlap with other sibling tools like ae_set_property or ae_set_text.

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