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

Annotations already declare readOnly=false, destructive=false, openWorld=true. The description adds genuinely new behavior: it starts content generation, results are scheduled or published per approval settings, it returns the trigger result, and it is retry-safe under a repeated idempotency_key. This is consistent with idempotentHint=false, since idempotency here depends on supplying the key rather than being inherent. No permission or rate-limit detail, so not a 5.

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 compact sentences, front-loaded with the action, then outcome, return, and retry semantics. Each sentence carries distinct information, though the 'results can be scheduled or published' clause is slightly padded and could be tightened.

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 mutation tool with no output schema and nested override objects, the description covers purpose, side effects, return, and retry safety. It omits prerequisites (e.g., the workspace_id requirement noted in the schema when creating content) and any guidance on the body/query override params, which keeps it from a 5.

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 50%. The description gives meaning to the two required params: id is the saved rule, and idempotency_key yields the original result on retry. It says nothing about brand_id, body, or query overrides, whose sparse schemas are the least self-explanatory. Baseline 3 is appropriate given partial coverage.

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 first sentence gives a specific verb and resource: 'Run a saved content automation rule by id on demand.' It implicitly separates this from create_content_automation, update_content_automation and get_content_automation by emphasizing an already-saved rule addressed by id. An agent can identify the operation 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?

'On demand' and the note that results follow the rule's approval settings give some context about when this fires. However, there is no explicit statement of when to pick this over create_content_automation, run_prompt, or the create_* posting tools, and no stated prerequisites beyond 'saved rule by id'. Usage is implied rather than specified.

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