Set a property value

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

Annotations already carry readOnlyHint: false and openWorldHint: false, so the mutation intent is known. The description adds that the value is static (vs animated) and that it can apply to 'anything ae_comp_info shows'. However, it does not disclose side effects like overwriting existing keyframes, whether the property must already exist, or error conditions—but since annotations already cover basic non-read-only behavior, a 3 is fair.

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?

Two sentences, front-loaded with the purpose and the distinguishing instruction ('use ae_set_keyframes to animate instead'). No filler or repeated schema facts. Every sentence 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?

The description gives the main decision point (static vs keyframes), a pointer to ae_comp_info for discovering properties, and a clear example path. The only missing piece is what happens to existing keyframes or animation on the property when setting a static value—worth mentioning, but given the schema+annotations already carry the required and mutating behavior, the description is quite complete for correct selection and usage.

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 coverage is listed at 100%, so the schema already provides all param descriptions. The description adds meaning by explaining 'static value', 'by path', and giving examples that overlap the schema but are not redundant. It gives gentle extra context (effect parameters, mask feather, shape sizes) beyond the raw schema, which is helpful but does not heavily compensate because the schema already covers the structure.

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 specific verb ('set') applied to a concrete resource ('any property by path') with explicit examples (effect parameters, mask feather, shape sizes). It also differentiates itself from the sibling ae_set_keyframes by saying 'use ae_set_keyframes to animate instead', so an agent can distinguish purpose without opening the schema.

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?

It explicitly tells when to use this tool (setting a static value on a property) and when not to (use ae_set_keyframes to animate instead). It additionally grounds usage by referencing ae_comp_info for discovering property paths, which is a practical routing hint for the agent.

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