automation_runRun an automation now, to try it (a mail-triggered one on the newest matching message). It runs in the background: its steps reach the agent as separate tasks, so a hosted agent gets them only after it finishes its current one. Look at the result with automation_get.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The automation id (automation_list). | |
| agent | No | Your hosted agent's name, when you have several (a hosted agent leaves it out). |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does substantial work: it discloses asynchronous background execution and that steps arrive as separate tasks, including the sequencing caveat for hosted agents. It omits any mention of side effects (the automation may send mail or mutate data) and any auth/idempotency notes, which is a real gap for a trigger 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 tight sentences, front-loaded with the action and followed by execution semantics and the result-routing hint. Each sentence earns its place; the parenthetical is dense but relevant rather than 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?
No output schema exists, and the description correctly redirects the agent to automation_get for results, which covers the return-value gap. The async delivery model is explained; the only missing piece is a warning about the side effects of actually running an automation.
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%, so the schema already documents both id and agent, including when to omit agent. The description adds context about mail-triggered runs on the newest matching message but no parameter-level syntax or format detail beyond the schema, so the baseline 3 applies.
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 and resource ('Run an automation now') plus the trigger scope ('a mail-triggered one on the newest matching message'), and names automation_get as the result-reading sibling. An agent can distinguish this from automation_list/automation_get/automation_save without opening any 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?
Gives clear usage context ('to try it') and points to automation_get for inspecting the outcome, which implicitly frames this as the execution step. It does not state when NOT to use it or contrast it with automation_save, so no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.