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

Goes well beyond the annotations by disclosing real side effects ('sending emails and changing contacts') on an ongoing, event-driven basis, plus a concrete cost ('Each run uses 3 credits'). This is exactly the context an agent needs before invoking a destructive, open-world, non-idempotent tool.

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, front-loaded with the action, then consequences, then cost. Every sentence supplies distinct, decision-relevant information with no restatement of the name.

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 one-param mutation tool with no output schema, it covers effect, trigger behavior, cost, and a reference for inspecting steps. A note on how to verify the resulting state or undo (pause/stop) would close the remaining gap.

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?

The single 'id' parameter has full schema coverage with its aut_xxx format documented, so the schema already carries the semantics. The description adds nothing parameter-specific, which is acceptable at 100% coverage but is baseline rather than added value.

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+resource ('Start or resume an automation') and clarifies the ongoing consequence that the automation then fires runs on matching events. It implicitly distinguishes itself from trigger-automation (one-off run) by framing runs as event-triggered, but never names that sibling to make the boundary explicit.

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?

'Start or resume' plus the trigger/event framing gives a clear context for use, and the pointer to get-automation tells the agent where to inspect steps first. It stops short of explicit exclusions, e.g., when to prefer trigger-automation for a single manual run or pause/stop for the inverse operation.

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