modify_effect_properties

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Modify properties,' implying mutation but not explaining how existing properties are merged/replaced, whether the operation is idempotent, or what happens if multiple identifiers (e.g., compId vs compName, layerName vs layerIndex) conflict. The description is too shallow to be behaviorally transparent.

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 a single short sentence with no filler, but it is under-specified rather than appropriately concise. For a tool with 7 parameters and a nested required object, this brevity omits essential context and cannot be credited as good conciseness.

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?

Given 7 parameters, a nested required object, no output schema, and no annotations, the description is completely inadequate. An agent cannot determine how to identify the target composition/layer/effect or how to format the properties object from the description alone.

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 0%, and the description adds no meaning to any of the 7 parameters except the word 'properties,' which merely echoes the required parameter name. It does not explain the structure of the properties object, how to select the effect, or the relationship between compId/compName, layerName/layerIndex, and effectName/effectIndex.

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 clearly states the action ('Modify') and the target resource ('properties of an existing effect'), making the basic purpose understandable. However, it does not add enough detail to distinguish it strongly from sibling effect-management tools like apply_effect, remove_effect, or reorder_effects, beyond the word 'existing'.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that apply_effect or apply_effect_template should be used for adding new effects, or that remove_effect handles deletion, so the agent is left to infer appropriate usage from the tool name.

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