cancel_active_fast

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the crucial detail of what destruction actually means: a recurring fast survives with its schedule intact, a one-off is deleted. That is real value beyond the structured hints. It stops short of stating permission requirements, error behavior on an already-ended fast, or rate limits.

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?

Front-loaded with the action, then the behavioral split, then the alternative route, all in three tight sentences. The trailing Args block is slightly mechanical but is the only place parameter provenance is documented, so it earns its space.

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?

An output schema exists, so return values need no prose, and the destructive mutation profile is covered by annotations plus the recurring/one-off outcome note. The only residual gap is failure behavior (e.g., what happens if the fast already ended), which is minor for a single-parameter cancel.

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 0%, so the description must compensate, and it does: fast_id is described as "the running fast's id, from get_fasting_history," which both explains the value and points at the tool that produces it. Type and requiredness come from the schema, so nothing essential is missing.

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?

Specific verb plus resource plus scope: "Cancel a fast that is still running." It then splits the outcome by fast type (recurring keeps its schedule, one-off is removed), which no sibling name alone would reveal, so an agent can tell it apart from edit_fast and delete_fast.

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?

It names the alternative explicitly (edit_fast) and the condition that selects it (ending the fast with the time fasted kept). Combined with the "still running" precondition, the agent has a clear routing rule rather than an inferred one.

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