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

Annotations declare idempotentHint=false, yet the description asserts 'Retry-safe: a repeat call with the same idempotency_key returns the original result' — a direct contradiction of the idempotency annotation. The destructiveHint alignment ('Overwrites the settings') is good, but a description that contradicts a structured hint is misleading and warrants the minimum score.

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?

Four short sentences, front-loaded with the action and target, followed by effects and return value. Slightly redundant between 'using the configuration in body' and 'Overwrites the settings', but no filler.

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 destructive, open-world mutation with a nested free-form body object and no output schema, the description covers effects and the return value but never explains the structure of the configuration payload or the behavior for settings left unspecified. Combined with the idempotency contradiction, it is only minimally complete for a 6-parameter update.

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 only 50%, so the description must carry more weight. It does explain the role of id ('identified by id'), body ('configuration in body'), and idempotency_key (retry behavior), but it says nothing about workspace_id, brand_id, or query, leaving half the parameter surface with only sparse or boilerplate schema text (e.g., the workspace_id note about 'required when creating content' is irrelevant/misleading for an update).

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 gives a specific verb+resource ('Update the saved content automation rule identified by id') and clarifies what the rule controls (future generation, destinations, approval behavior), so the agent knows exactly what is being mutated. It does not explicitly distinguish itself from the create/get/delete/trigger content-automation siblings, which is the only gap.

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?

There is no when-to-use/when-not-to-use guidance and no alternatives named. The phrase 'saved content automation rule identified by id' implies an existing rule must be referenced, but the description never says how this differs from aidelly_create_content_automation or aidelly_trigger_content_automation, nor what prerequisites (permissions, brand/workspace scope) apply.

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