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

Annotations already declare destructive=true, idempotent=true, openWorld=true, readOnly=false, so the safety profile is covered. The description adds non-obvious behavioral context: activation starts recurring generation, is bounded by credit caps, and can cause previously approved delivery to publish to connected channels. The type-matching precondition is also useful. It stops short of saying how to reverse the activation or what the run cadence is.

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?

Three short sentences with the action and scope front-loaded and no filler. The middle sentence about automatic delivery is the only one that could arguably be tightened, but it carries real behavioral information.

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?

An output schema exists, so return values need not be described. For a destructive, open-world mutation, the description usefully discloses the publishing side effect and the type-match precondition, but the four required parameters remain opaque, leaving the agent unable to construct a correct call 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% with four required parameters (brandId, automationId, revision, idempotencyKey), and the description supplies no per-parameter meaning. Terms like 'saved recipe' loosely gesture at automationId, but revision and idempotencyKey semantics are entirely undocumented in both schema and description, so the description does not compensate for the coverage gap.

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?

States a specific verb (activate) and resource (recurring generation from a saved recipe), and narrows it with 'Only written social posts; the saved automation type must match this tool.' That last clause is a genuine attempt at sibling differentiation, though it doesn't name the sibling by name.

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?

Implies when to use: a saved recipe exists and the automation type is 'written social posts.' It notes that previously approved automatic delivery can publish to connected channels, which hints at prerequisites. But it never names the alternatives it sits among (resume_*, pause_automation, prepare_post_writer_automation), so the routing inference is left to the agent.

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