Run an automation now (201); a period that already ran needs force

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

The annotations only say readOnlyHint=false and openWorldHint=true; the description adds substantially: this is a WRITE, there is a client-side confirm gate rather than a server dry run, success is 201, and the operation is irreversible enough that no server-side preview exists. That is strong added context, though it does not say what the returned preview contains or whether rules must be enabled.

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?

Two dense sentences, front-loaded with the action and the force condition before the write/confirm caveat. The telegraphic parentheticals are efficient rather than wasteful, though the title duplicates the first clause of the description.

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 write endpoint with no output schema, the description covers the essentials: the gate to execution, the preview fallback, the status code, and the force semantics. Gaps remain on what the preview returns and on failure behavior for an already-run period without force, which matters given the title's emphasis on 201/period semantics.

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%: confirm and idempotencyKey already have schema descriptions, so only 'id' and 'force' need help. The description does cover those two (id is the rule in the path; force re-runs an already-executed period), which compensates well, but it never mentions idempotency-key behavior for retries, which matters for a write tool.

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 uses a specific verb+resource ("Run an automation now") and pins it to POST /v1/rules/{id}/run, plus it distinguishes the scoped variant (force needed for a period that already ran). It never names the obvious sibling rules_simulate, which is the natural read-only alternative, so an agent still has to infer the boundary from sibling names alone.

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?

Explicit execution condition is given: nothing is executed unless confirm: true, and without it a preview of the request is returned. It also tells the agent when force is required (a period that already ran). What is missing is the when-not/alternative routing to rules_simulate for a true dry run, and the error behavior if force is omitted.

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