svg_animate

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

Since no annotations are provided, the description carries the behavioral burden. It does disclose that animation is applied to existing objects by id and lists supported operation categories, presets, easing curves, and motion paths. However, it does not mention side effects such as file overwriting, whether the source file is mutated, or how existing animations are replaced.

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 three short sentences with the core behavior front-loaded and no filler. The final sentence about Inkscape's lack of animation support earns its place as differentiation context, though the operation list could have been formatted more cleanly.

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 22-parameter tool with no required parameters, no output schema, and no annotations, the description is not complete enough. It does not explain which parameters apply to which operation, how object_ids and input/output paths interact, or what the tool returns or writes. Schema-level parameter descriptions help, but operation-level workflow guidance is missing.

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 100%, so the description can rely on the schema for per-parameter meaning. It adds value by supplying the operation enum values that the schema omits, and by stating capability constraints like 12 presets, 7 easing curves, and motion along any path in the document.

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?

Description names a specific function: applying SMIL/CSS animation to existing document objects by id, and lists the operation modes. It distinguishes itself from sibling transform/style tools by noting that Inkscape has no animation action of any kind, though the individual operations remain under-specified.

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?

No explicit when-to-use or when-not-to-use guidance is given. The phrase 'objects ALREADY IN THE DOCUMENT' implies a constraint, and the note that Inkscape has no animation action gives context, but it does not tell the agent when to prefer object_transform for transforms or object_style for color work, nor does it explain which operation fits which task.

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