Routine Run

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write and non-idempotency profile is covered. The description adds conceptual context ("the person's record of what happened"), clarifying that notes are an append-style human log, but it does not say who is attributed, whether notes can later be edited or removed, or what a repeat call does.

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 short sentences, front-loaded with the action and attachment point. Every sentence earns some place, though the second is slightly loose in phrasing ("the person's").

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 two-parameter write tool with full schema coverage, no output schema, and annotations covering safety, the description is workable. It still leaves open whether a note id is returned and how notes relate to steps, which an agent might want before calling repeatedly.

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 100%, so both parameters (run uuid, note text) are already documented in the schema. The description adds no format or content guidance for `text` beyond what the schema states, 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 ("Writes a note on a run") and adds the attachment point ("at the step it is on"), which separates it from get_run/list_runs siblings. It doesn't explicitly name which sibling to prefer over it (e.g., add_step), but the resource is unambiguous.

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?

There is no guidance on when to use this versus add_step or set_value, no prerequisites, and no stated exclusions. The agent must infer the use case from the noun "note" alone.

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

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

Annotations already declare readOnly=false, idempotent=false, destructive=false and openWorld=false, so the safety profile is covered. The description adds a genuine behavioral detail — a link passed as the step becomes an openable step — but says nothing about what happens if the routine is not an open list or does not exist.

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 short sentences, front-loaded with the action and its scope constraint, with no padding. The second sentence is tersely phrased but does carry signal 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?

For a 3-parameter, non-destructive write with full schema coverage and no output schema, the essentials are there, but the description omits what happens on invalid/non-list routines and how this differs concretely from add_note in the same family.

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 baseline would be 3, but the description adds real meaning beyond the schema: the 'link becomes a step that opens it' sentence explains the link-handling semantics of the 'title' parameter. 'detail' remains unexplained in the description, keeping it off a 5.

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 ('Adds a step to a routine') plus the scope constraint that the routine stays open as a list, with concrete examples (Inbox, To read). It implicitly separates itself from run-oriented siblings like start_run or next_step, though it never names them.

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 'stays open as a list' qualifier hints at when this applies, and the title examples help, but there is no explicit when-to-use guidance, no named alternative (e.g. add_note vs this), and no stated precondition or failure behavior.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful behavioral context by enumerating the result states, including non-terminal ones like 'still waiting', which signals that the command may be asynchronous and that polling may be needed. It does not describe auth or rate limits, but the added state model is substantive.

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?

A single, front-loaded sentence with zero filler. The possible outcomes are listed compactly and directly after the core purpose, so the agent gets both the function and the result vocabulary immediately.

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?

There is no output schema, so the description appropriately compensates by enumerating the status values an agent might receive. Combined with the annotations and the fully described single parameter, this is close to complete. A minor gap is that it does not say whether 'still waiting' means the agent should poll again, but overall it is sufficient for a simple read-only status check.

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%, and the schema already explains that the parameter is 'The command id another tool returned.' The description reinforces that the command comes from another tool, but it adds no syntax, format, or example detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 gives a clear verb-and-resource: it reports what happened to a command. It also enumerates the possible outcomes (done, refused, too old, run moved, not found, still waiting), which sharpens the purpose. It does not differentiate against specific siblings by name, but the phrase 'one of the other tools sent' situates it within the async command workflow.

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?

Usage is implied rather than explicit: the tool is for checking a command that another tool sent. There is no explicit 'use this when...' guidance, no mention of when not to use it, and no named alternative. An agent can infer the polling use case, but the definition does not spell it out.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine behavior beyond that: matching is against name or description, and each result includes its steps plus a link that installs it in the app.

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 sentences, both front-loaded: the search scope first, the return shape second. No filler or repetition of the title.

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?

With no output schema, the description carries the return-value burden and does so ('each comes with its steps and a link that adds it'), while the schema covers the empty-query case. Nothing needed to call this tool correctly is missing.

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 100% and the single parameter is already documented ('what it is for, in a few words; leave out to list all'). The description adds only that matching targets name or description, a modest gain over the schema baseline.

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 (searches) and a precisely scoped resource: the routines the app ships, not user-created ones. The examples (mornings, focus, on call, chores) make the resource concrete and separate it from the sibling how_to_write_a_routine.

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 scoping to app-shipped routines implies this is the lookup path when you want a ready-made routine rather than authoring one, but no when/when-not or explicit alternative (how_to_write_a_routine) is named. Usage is inferable, not stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds meaningful scope boundaries — 'Never notes or values' — and sketches the return content, but says nothing about defaults, limits, or ordering beyond what the schema states. Useful addition, not rich behavioral context.

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 lead clause front-loads what the tool returns, and the final sentence gives the use case. The middle sentence is a long run-on enumeration, but every clause maps to real returned data, so little is wasted; it could be split for readability.

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?

With no output schema, the description carries the burden of describing returns and does so thoroughly (counts per status, skipped/deferred steps, finished runs with start and end step). Scope exclusions and use cases are present, so an agent has enough to call it correctly; only return ordering and volume limits are unaddressed.

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%, with both `days` (default seven, max 92) and `routine` fully documented in the schema. The description only implicitly gestures at date range and single-routine filtering via 'review a week' and 'each routine'; it adds no syntax or semantics beyond the schema. 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?

The description names a specific resource (a summary of runs over a recent period) and enumerates exactly what the summary contains: per-routine completion status, most-skipped/deferred steps, and finished runs with start time and end step. That level of specificity separates it from siblings like list_runs or get_run, which return raw runs rather than an aggregate review.

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 gives concrete usage contexts: 'Use it to review a week, or to see which steps a routine could lose,' which tells the agent when aggregation is the right shape of answer. It does not name the alternative tools (list_runs, get_run) or state when not to use it, so the routing guidance is clear but not exhaustive.

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

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful return-content context by specifying ordered steps, ids, details, minutes, and version, though it does not describe error behavior or response shape beyond that.

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 definition is a single compact sentence with no obvious waste. It is somewhat dense but efficiently conveys the returned fields and the version-proposal usage hint.

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 single-parameter read tool with strong annotations and no output schema, the description covers what the tool returns and includes a relevant workflow note. It could do more to distinguish the tool from list_routines or get_run, but it is usable as written.

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%, and the single routine parameter is already documented as accepting a name or id. The description does not add meaningful syntax or format detail beyond what the schema provides, so the baseline of 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?

The description identifies a specific resource and scope: one routine's ordered steps, ids, details, minutes, and version. It does not use an explicit retrieval verb and does not name a sibling tool, but the intended operation is clear from the content.

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 gives a workflow hint by saying to name the routine's version when proposing a change, which connects it to propose_routine_change/propose_new_routine. However, it does not explicitly say when to use get_routine versus list_routines, find_starter_routine, or get_run.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description still earns credit by disclosing permission-gated data ('if the person has let this assistant read them') and how finished/stopped runs are represented (ended set, unreached steps marked notReached).

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 sentences, front-loaded with the primary return content and followed by edge-case behavior. The phrasing 'each done, in hand or ahead' is slightly literary and less precise than plain status terminology, a minor cost.

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?

With no output schema, the description carries the burden of describing return values, and it does: ordered steps, notes, values, ended flag, and notReached marking. Combined with full annotation coverage and a documented single parameter, an agent has what it needs to call this correctly.

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?

There is a single parameter with 100% schema description coverage ('The run's id'), so the schema fully documents it. The description adds no format, sourcing, or lookup hints beyond what the schema provides, which fits the baseline 3 for high-coverage schemas.

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 identifies the resource as a single run ('One run's steps') and enumerates what is returned: ordered steps, notes, and values. The word 'One' implicitly distinguishes it from list_runs, but no sibling is named explicitly, keeping it just short of a 5.

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?

Usage is only implied by the content description; there is no statement of when to call this versus get_history, list_runs, or get_routine. An agent can infer it reads a single run's current state, but no exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral information by describing what the call returns — the complete field set and action vocabulary of a routine — which is the key trait for a zero-argument reference 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?

Two short sentences, with the description of the output leading and the usage trigger following. No filler or repetition of the title, though the opening clause 'The JSON form Routine Run reads a routine in' is slightly convoluted.

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 no-parameter, no-output-schema reference tool, the description covers the two things an agent needs: what the payload contains and when to fetch it. It could be marginally stronger by naming an example field or step action, but nothing essential is missing.

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 tool takes no parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs, and it correctly spends no words on parameter semantics.

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 goes beyond the name by stating that the tool returns the JSON form Routine Run reads — every field and every action a step can take. That identifies it as a schema/reference tool rather than an action tool, which is enough to separate it from routine_link and find_starter_routine. It stops short of explicitly contrasting itself with those siblings, so it lands at 4 rather than 5.

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 gives an explicit trigger: 'Use it when writing a routine for routine_link, start_new_run or propose_new_routine.' That is concrete when-to-use guidance tied to named consumers of the output. It does not state when *not* to call it, which keeps it below a 5.

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

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

Annotations already declare this as a safe, read-only, idempotent operation. The description adds useful context beyond that: the data comes from the phone itself and the phone must be reachable, which affects whether the call will succeed.

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 two sentences are front-loaded with the core purpose and the returned fields, followed by the optional filter and reachability constraint. There is no wasted text.

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?

With no output schema, the description usefully names the fields returned and notes the phone reachability requirement. It is nearly complete for a simple list operation, though it could mention ordering or empty results.

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 100%, so the `match` parameter is already documented in the schema. The description restates that it narrows by name but adds no syntax, matching rules, or format details beyond what is already provided.

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 gives a specific verb and resource: it lists a person's routines and names the fields returned (id, name, step count, open-list status). It is clearly distinct from get_routine, but it does not explicitly contrast itself with that sibling.

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 tells the agent to use `match` to narrow by name and notes that the phone must be reachable, which implies when the call is appropriate. However, it does not state when to use this tool instead of get_routine or list_runs.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the returned field set and by tying the step id to next_step's expectsStep parameter — a cross-tool contract the agent could not infer from annotations or the empty schema.

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?

A single compact sentence that front-loads the scope ('the runs going now') before the field list. The parenthetical about next_step's expectsStep is slightly dense but earns its place by encoding a real dependency.

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 zero-param read tool with no output schema, the description carries the return-shape burden and does so adequately by naming each field. It omits ordering, whether paused/blocked runs count as 'going', and any volume limits, which leaves modest gaps for a list operation.

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 tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly spends no space on inputs and instead describes outputs.

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 ('the runs going now') and enumerates the returned fields (id, name, routine, status, current step), so the agent knows exactly what it gets back. It implicitly separates itself from get_history (past runs) and get_run (a single run) via 'going now', though it never names those siblings explicitly.

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?

Usage is only implied by the phrase 'going now' — the agent can infer this is for currently active runs rather than historical ones. There is no explicit when-to-use/when-not or named alternative such as get_history or get_run, and no mention of whether paused runs are included.

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

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

With annotations already covering mutation and safety hints, the description adds important behavioral detail: it marks the step done, advances the run, and explicitly does not press any step buttons, even onNext. The expectsStep caveat also discloses how concurrent movement is detected.

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 short and front-loaded: it starts with the core action, then explains the optional guard, then clarifies a key non-behavior. Every sentence contributes useful information.

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 two-parameter mutation tool with no output schema and rich schema descriptions, the definition covers the action, the concurrency guard, and the important side-effect boundary around step buttons. Nothing essential for correct invocation is missing.

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 100%, so the baseline is 3. The description adds useful semantic meaning for expectsStep by explaining it as a guard against another actor having already moved the run.

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 states a specific verb and resource: it marks the current step done and advances the run. The final sentence about not pressing buttons further clarifies the exact scope, distinguishing it from actions that would trigger step buttons.

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 gives clear usage context for expectsStep as an optimistic-concurrency guard: pass the step id you believe the run is on to detect if something else moved it first. It does not explicitly compare against siblings such as put_off_step or pause_run, so there is no full when-to-use/when-not-to-use routing guidance.

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

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

Annotations already cover safety (destructiveHint=false, idempotentHint=true, readOnlyHint=false), so the description's contribution is the state semantics: timers stop and stay stopped until resumption. That is real behavioral context an agent could not get from the annotations. It stops short of saying what happens to an in-flight step or whether paused state persists indefinitely.

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?

One sentence, front-loaded with the action, and every clause carries information (scope of the pause plus the timer consequence). No padding or restatement of the title.

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-parameter control operation with full schema coverage and annotations, the description covers the essential effect and its reversibility. The remaining gap is minor: it does not say what the caller gets back or whether a currently executing step completes before the pause takes effect.

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 100% with a single required UUID parameter fully documented in the schema, so the baseline of 3 applies. The description adds no extra meaning about the run identifier or how to obtain one (e.g. via list_runs or get_run).

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 ('Pauses a run') and adds a scope qualifier ('where it stands'). The reference to 'until it is resumed' implicitly signals the counterpart operation, but it never names resume_run or any other sibling, so differentiation is left to the agent.

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 phrase 'until it is resumed' implies this is a temporary suspension rather than a termination, which implicitly contrasts with stop_run, but no explicit when-to-use or when-not-to-use guidance is given. The agent must infer the choice between pause_run, stop_run, and resume_run from names alone.

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

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

Beyond annotations (readOnly=false, idempotent=false, destructive=false), the description discloses visible side effects: the item appears on the phone as a Planned run, the person can move or delete it there, it begins at that moment, and the answer carries `run`. It stops short of stating whether re-planning the same moment duplicates a plan (relevant given idempotentHint=false) or what happens on conflict.

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 sentences plus a comma-clause, front-loaded with the core action and the future-moment scope. Every clause adds usable information — example, phone visibility, timezone requirement, return field — with no 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?

There is no output schema, but the description names the return payload (`run`). With 5 parameters at full schema coverage, the description covers the remaining questions an agent would have: deferred timing, phone-side editability, timezone format, and start_run-consistent naming/values.

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 100%, so baseline is 3, and the description earns a bump by adding a real constraint not spelled out in prose in the schema: the moment must carry its time-zone offset in ISO 8601. It also tells the agent `name`/`values` behave as in start_run, which is useful cross-tool semantics beyond the per-field schema text.

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 ('Plans a run of one of the person's routines') and pins the distinguishing scope: a future moment rather than now. The example 'Morning tomorrow at seven' and the contrast with start_run ('Takes name and values as start_run does') let an agent tell it apart from the sibling without opening either 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?

The description makes clear when to use it: scheduling for a moment to come, as opposed to start_run for immediate execution. It explicitly covers the ask_first case via the schema, but does not state an explicit exclusion ('do not use to run now') or what happens if the moment is invalid/in the past.

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

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

Annotations only declare the non-read-only, non-destructive, non-idempotent profile; the description adds genuinely new behavior — the proposal is surfaced to the person for approval, or auto-saved if the assistant is configured that way, plus a ~30,000 character size cap. What it does not cover is whether a saved proposal returns an identifier or how the agent learns of the outcome.

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?

A single front-loaded sentence carries the action, format reference, user-review behavior, auto-save exception, and size limit with no filler. Every clause earns its place.

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-parameter mutation with no output schema, the description covers format, approval flow, and size limit — enough to invoke correctly. The only omission is what the call returns or how the agent detects save vs. pending review.

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?

With one parameter at 100% schema coverage the baseline is already 4, and the description adds real constraints beyond the schema: no `from` field and a length ceiling. It does not further explain the `written` JSON shape because the schema already does.

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 opens with a specific verb+resource ('Suggests a new routine for the person's iPhone') and pins the format to the sibling reference tool how_to_write_a_routine. It implicitly separates itself from propose_routine_change via 'new' but never names that sibling explicitly, so the distinction is left to inference.

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 conveys the workflow (phone shows it, person saves or drops) but gives no explicit when-to-use versus when-not guidance, and does not contrast itself with propose_routine_change or find_starter_routine. Usage is implied rather than stated.

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

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

Goes well beyond the annotations, which only say non-read-only, non-destructive, non-idempotent. The description discloses the human approval loop (shown on the phone for save or drop), the auto-save bypass, that the previous version is retained, and a size ceiling of about 30,000 characters.

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: purpose, exact call sequence, then side effects. The workflow and the version requirement are front-loaded, and even the trailing character limit is operationally necessary.

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 non-destructive mutation with a review step, the description covers prerequisites, side effects, version retention and size limits. With no output schema, it never says what the call returns (a pending proposal, a confirmation), which is the one thing an agent cannot infer.

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 100%, so the schema already documents all three parameters. The description still adds value by explaining provenance: `version` must be the value get_routine returned and `written` must be the whole routine with `from` preserved, which is the semantics that matters for correctness.

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 ('Suggests a change to one of the person's routines') and, via 'one of the person's routines', implicitly separates it from propose_new_routine. It never names the sibling explicitly, so an agent must infer the boundary from the tool names rather than the prose.

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 an explicit prerequisite workflow: fetch with get_routine, edit the `written` form, send the whole thing back with the returned version. It does not state a when-not case (e.g. use propose_new_routine instead when the routine does not yet exist), which is the only gap.

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

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

Annotations only give the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds the actual state effects the annotations cannot express: the run's position is unchanged, the next step comes into hand, and the deferred step is reordered. It also explains that expectsStep is an optimistic-concurrency guard ('make sure nothing else moved it first'), which is behavior an agent needs before calling.

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 with no filler, but the leading clause 'Not now, for the step a run is on' is the least informative part and occupies the front-loaded position, forcing the reader past it to reach the useful enum semantics.

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 3-parameter mutation with no output schema and full schema coverage, the description covers effect and concurrency guard adequately, but omits what happens if expectsStep mismatches, whether step history is recorded for the deferred step, and what the call returns.

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 100%, so the baseline would be 3, but the description genuinely adds meaning: it clarifies what `later` and `last` do to the step in the run's ordering and reframes expectsStep as a guard against concurrent modification, which the schema only describes neutrally as 'the id of the step the run should be on.'

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 conveys that the current step is postponed rather than skipped, then defines the two modes: `later` moves it one place down, `last` to the end. However, the opening phrase 'Not now, for the step a run is on' is oblique and never names the resource explicitly as a step-ordering operation, so the agent has to infer the verb+resource from the enum meanings rather than reading it directly.

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?

There is an implied condition ('not now'), but no explicit statement of when to choose this over adjacent tools such as next_step, pause_run, or stop_run, all of which are plausible alternatives for the same situation. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds a state precondition (paused/held), but says nothing about side effects such as whether execution restarts from the current step or whether a scheduling delay applies.

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?

A single front-loaded sentence with no filler. It is efficient, though arguably under-informative rather than tight.

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-parameter state-transition tool with annotations covering safety and idempotency, this is minimally adequate. The vague phrase 'held in another status' leaves the agent unsure which exact run states accept this call, and there is no output schema to clarify the result.

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 100% and the single 'run' parameter is documented as a UUID, so the schema already does the work. The description adds no format, lookup, or identifier semantics beyond what the schema provides, 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?

The description states a specific verb ('Resumes') and resource ('a run'), so the action is unambiguous. It does not explicitly contrast itself with the inverse siblings pause_run and stop_run, but the verb itself makes the distinction inferable.

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 a precondition ('paused or held in another status'), which is a genuine usage signal. However, it does not say what to do if the run is already running, nor does it point to pause_run/stop_run as alternatives for the opposite operation.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is low; the description adds real context beyond them by explaining what the link does on an iPhone (opens the app's review screen, where the user chooses to save), that nothing is persisted here, and that the JSON should be passed along as a fallback.

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?

Purpose is front-loaded in the first sentence, and the remaining sentences each add operational value (link behavior, no persistence, hand off link plus JSON). The informal phrasing adds length but stays within a reasonable size.

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?

There is no output schema, so the description must describe the return, and it does: a link plus JSON with a note on the link's on-device behavior. Combined with annotations covering the safety profile, an agent has enough to invoke and route the result, though invalid-routine/error behavior is left unstated.

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 100% and the single parameter is already documented in the schema as accepting an object or JSON text. The description adds only an indirect pointer to how_to_write_a_routine for the format, so baseline 3 is appropriate.

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 action (checks a routine, returns a link) and names the resource, and ties the input format to the sibling how_to_write_a_routine. It's distinguishable from find_starter_routine, but the phrasing is narrative rather than crisp, so it doesn't quite reach 5.

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?

Implicitly routes the agent to how_to_write_a_routine for the input form and tells it to hand the user both the link and the JSON. However, it never states when to call this tool versus find_starter_routine, nor any precondition beyond the referenced form, leaving usage largely inferred.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description only needs to add context above that. It does add one genuinely useful behavior — an empty value deletes the entry — but says nothing about whether an existing key is silently overwritten, whether it works on stopped runs, or what the call returns. Note the mild tension between 'empty value removes it' and destructiveHint=false.

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 short sentences, zero filler, with the set semantics first and the edge case second. Nothing is wasted or buried.

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 3-required-param mutation with annotations and no output schema, this is only just enough. The agent still cannot tell whether the call overwrites existing values, what happens on a completed run, or what the response body contains beyond the schema-declared inputs.

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 100%, so all three parameters (key, run, value) are already documented in the schema. The description adds only one extra semantic — value='' means delete — and does not explain accepted value encodings or whether key namespaces collide with other run data. Baseline 3 is appropriate when the schema carries the load.

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 states a concrete effect — storing a named value on a run ("a reading or a number") — and adds the important twist that an empty value removes it. It is clear what the tool does, though it never contrasts itself with siblings like add_note or add_step that also attach data to a run.

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 only usage-ish signal is the empty-value deletion rule. There is no statement of when to prefer set_value over add_note/add_step, no prerequisites (must the run be active? paused?), and no guidance on overwrite behavior for an existing key.

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

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

With annotations already covering safety, the description adds substantial behavior: the run begins immediately with a Lock Screen card, off-phone steps arrive disabled, allowlisted webhooks must reuse the address/method/secret names exactly, and onNext buttons are also triggered by the person's own Next while next_step won't press them. It never says what calling twice produces, which is the notable gap given idempotentHint=false.

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 purpose and immediacy are front-loaded, then the constraints follow in logical order. Sentences are long and clause-heavy, but each one carries distinct information about steps, webhooks, or button behavior.

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 2-parameter creation tool with no output schema, the description covers the starting behavior, persistence, and step-configuration rules an agent needs to write a valid payload. It stops short of saying what comes back or how to follow the run afterwards (get_run / next_step exist as siblings), leaving a small 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?

Schema coverage is 100%, so the baseline is 3. The description restates the ask_first guidance almost verbatim from the schema and adds only a pointer to how_to_write_a_routine for the 'written' payload, which is marginally useful but not new parameter semantics.

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 states a specific verb and resource ('Starts a run on the person's iPhone from steps you write') and scopes it as a one-off rather than a routine. The distinction from the sibling start_run is implied through 'without making a routine of it' rather than named explicitly, which keeps it just short of a 5.

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?

Concrete use cases are given ('a checklist for today, a test plan, a one-off errand') along with the persistence rule ('stays out of the person's routines unless they keep it') and a pointer to how_to_write_a_routine for the payload format. It doesn't explicitly say when to prefer start_run over this tool, so the alternative is left implicit.

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

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

Goes well beyond the annotations: it discloses that a card appears on the Lock Screen, that the response carries `run` (the new run's id) for set_value/next_step, and that a single-run routine already in progress returns alreadyGoing with the existing run unless `restart` is true. That is real behavioral context an agent could not infer from readOnlyHint=false / idempotentHint=false.

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-loads what the tool does, then the return value, then the concurrency/restart cases — a sensible order. Some phrasing is dense and awkward ('the `values` its steps or name quote ({param:company})'), but every sentence carries information.

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?

With no output schema, the description correctly explains the return shape (`run` id, alreadyGoing case). It covers concurrency and restart semantics well. It does not mention what happens when the routine name is unknown or whether the phone must be reachable, which are the remaining gaps for a mutation tool.

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 already 100%, so the baseline is 3; the description earns more by explaining why `name` and `values` matter (telling concurrent runs apart) and how `restart` interacts with the alreadyGoing outcome. It adds rationale the per-property schema text does not carry, though it says nothing about `ask_first`.

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: starts a run of one of the person's routines on their iPhone, resolved by name (any case) or id. An agent can tell what it does without opening the schema. It does not, however, distinguish itself from the sibling start_new_run or from plan_run, so sibling differentiation is missing.

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 gives conditional guidance for parameter choices — supply a `name` and `values` when the routine allows concurrent runs so they can be told apart, and `restart` only when the routine is single-run and already going. It never says when to pick this tool over start_new_run, plan_run, or start_new_run alternatives, so tool selection is left to inference.

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

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 genuinely non-obvious behavior: the run is preserved in history with all its collected data and can be reopened from the phone. This materially softens the 'destructive' read and is exactly the context annotations can't convey. It does not contradict the annotations.

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 tight sentences with the core action front-loaded and the recovery outcome appended. No filler, though the phrasing is conversational rather than precise.

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?

One required param, full schema coverage, rich annotations, and no output schema, so the description only needs to convey side effects. It does that by explaining history preservation and reopenability, leaving only the response shape unstated, which is a minor 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?

There is a single parameter ('run') at 100% schema description coverage, so the schema already explains it as the run's id. The description adds nothing about parameter format or source, which is acceptable at this coverage level but not above baseline.

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 ('Stops') and resource ('a run') and anchors it to a familiar UI action ('as the Stop button does'). It doesn't explicitly distinguish itself from pause_run, which is a close and semantically overlapping sibling, so it falls short of a 5.

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?

No when-to-use vs when-not guidance and no mention of pause_run, the obvious alternative for a temporary halt. The Stop-button analogy implies intent but leaves the pause-versus-stop decision to inference.

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