trigger_automation

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

No annotations are provided, so the description carries the full burden. It discloses the behavioral trait that response type depends on component type, and explains what each response looks like. It does not mention potential errors, permissions, or idempotency, but for a trigger operation the disclosed behavior is adequate.

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 concise and well-structured with a clear opening sentence, bullet points for response types, and a closing usage tip. Every sentence earns its place without unnecessary fluff.

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 tool with two parameters and an output schema (though not shown), the description covers purpose, response types, and monitoring guidance. It does not discuss edge cases or error handling, but it is sufficiently complete for typical usage.

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% — both route_name and data have clear descriptions. The description adds little beyond reinforcing that route_name comes from get_automations and that data matches the endpoint trigger schema. Baseline of 3 is appropriate since the schema already documents parameters well.

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 clearly states the tool's purpose: 'Trigger an automation via its Operations Manager endpoint' and 'Executes any automation (workflow or agent)' with specific response types. It distinguishes from siblings by explaining the two response paths and corresponding monitoring tools.

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?

The description provides clear guidance on when to use: it recommends using get_automations to discover automations and their component_type before triggering, and describes how to monitor results via describe_job or describe_session. It does not explicitly state when not to use it, but the context is sufficient.

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