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

Annotations already declare this is a non-read-only, destructive motion command, and the description adds meaningful behavior on top: the self-expiring 5 s lease, the renewal path via reins_renew, and the owner-confirmation gate that surfaces as a pending_confirmation return. These are exactly the traits an agent cannot infer from destructiveHint alone.

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?

Four short sentences, each carrying distinct information (action, lease expiry, renewal alternative, confirmation outcome), with the core purpose front-loaded and 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?

With no output schema, the description helpfully names the pending_confirmation return, but it leaves ambiguous whether the call blocks for duration_s or returns immediately, which matters for a timed motion command. Otherwise complete for a 5-parameter 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 description coverage is 100%, with units, bounds, staleness, replay, and the confirmation threshold all documented per parameter. The description adds only the combined 'constant speed and turn rate' framing, 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 with scope: 'Drive at a constant speed and turn rate for a bounded time, then stop.' The bounded-time framing and the pointer to reins_renew for extension let an agent separate this from the stop/renew siblings.

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?

Clearly establishes the operating context: a lease of at most 5 s that self-terminates, with reins_renew named as the way to continue. It stops short of an explicit when-not-to-use statement or a comparison against reins_stop, so it is strong but not fully routing.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds content-level context (the policy covers actions, bounds, and limits), but says nothing about the return shape, freshness, or scope of the policy, which matters since there is no output 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 tight phrase with no filler — every word earns its place and it is front-loaded. It loses a point for being a fragment rather than a complete, structured statement of purpose.

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 zero params, no output schema, and read-only annotation, the definition is close to sufficient, but the description should clarify the return format and meaning of 'bounds/limits' since no schema documents the output. It is adequate but leaves interpretation gaps.

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 for the description to disambiguate. Baseline 4 applies; no parameter semantics are missing or contradicted.

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 phrase names the resource (this robot's policy) and its contents (actions, bounds, limits), which is more than a tautology. However it is a noun fragment with no verb — it never says what the tool actually does (retrieve/read the policy) — so an agent cannot cleanly distinguish it from reins_status or reins_renew without opening the 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?

There is no when-to-use, when-not-to-use, or alternative routing. Siblings like reins_status and reins_stop exist but are never mentioned or contrasted, leaving the agent to guess which reins_* tool answers a policy question.

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 supply readOnlyHint=false. The description adds a genuinely non-obvious behavioral limit: the 20 s total lease lifetime cap, which is not encoded anywhere in the schema. It still omits failure behavior (e.g., what happens when the total cap is exceeded) and what the operation returns.

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 core action front-loaded and constraints appended. No filler, no restatement of the tool name.

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 state-mutating, no-output-schema tool, the description covers the action and its hard limits but not the lease lifecycle context an agent needs — what an expired or unknown lease_id yields, whether the renewal is idempotent, or how it relates to reins_status/reins_stop.

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 0%, so the description must carry the load. 'At most 5 s from now' partially explains extend_s (seconds, capped), but lease_id is left unexplained beyond its self-descriptive name, and the per-call vs. total limits are easy to conflate.

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: 'Extend the running motion lease (heartbeat).' The parenthetical disambiguates the domain meaning of 'renew.' It does not explicitly contrast with siblings like reins_stop or reins_status, but the purpose 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?

The 'heartbeat' framing implies periodic calling to keep a lease alive, and the caps hint at how often it may be used, but there is no explicit statement of when to call it, when not to, or what happens if the lease has already lapsed. Usage is only implied.

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?

readOnlyHint=true already tells the agent this is a safe read with no side effects, lowering the bar. The description adds genuine value by naming the returned state fields (stopped?, running lease, pending confirmations), but it leaves 'the robot's status fields' vague and says nothing about freshness or polling behavior.

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, with the primary subject ('Reins state') front-loaded and the detail in a parenthetical. Nothing is padded, though the phrasing 'and the robot's status fields' is loose.

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 is the only source of information about what comes back, and it gives only a partial sketch: three reins fields are named but 'the robot's status fields' is left undefined. For a zero-parameter status tool this is adequate but not complete.

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 for the description to disambiguate; the 4 baseline applies. No parameter text is needed or 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?

The description identifies the resource (Reins state plus the robot's status fields) and enumerates the key contents (stopped?, running lease, pending confirmations), which distinguishes it from siblings like reins_stop and reins_renew. It lacks an explicit verb such as 'get', but the read intent is unambiguous given the name and the enumerated fields.

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 statement of when to call this versus alternatives, and none of the siblings (reins_stop, reins_policy, reins_renew, drive, set_led) are referenced. Usage is only implied by the name and the returned fields.

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 readOnlyHint=false and destructiveHint=false; the description adds the crucial behavioral fact that motion stays blocked afterward until the owner resumes, which is post-call state an agent must know. It does not explain how long the block persists or how resumption is triggered beyond 'the owner'.

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 short sentences, front-loaded with the action ('Stop the robot now'), then eligibility, then consequences. Every sentence carries distinct information 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?

For a single-purpose stop tool with no output schema this covers the action and its lasting effect adequately, but it leaves the sole input parameter entirely unexplained and gives no detail on the resumption mechanism. Adequate but with a clear 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 one parameter ('reason') at 0% schema description coverage, and the description never mentions it, so an agent gets no guidance on whether it is needed, what format it takes, or how it is used. With a real undocumented parameter, the description should compensate but does not.

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 ('Stop the robot') with an immediacy qualifier ('now'), which clearly separates it from sibling tools like drive, reins_policy, and reins_renew. An agent can identify this as the halt action without opening the 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?

'Always allowed' tells the agent this can be invoked unconditionally with no permission or state prerequisites, which is valuable routing context. It does not name alternatives or when-not conditions, so it stops short of the top score.

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 declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered, but the description adds nothing beyond them. For a mutation tool it says nothing about permissions, staleness/replay rejection (only in the schema), or what happens to the light state on failure.

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 short sentence with no wasted words and the action front-loaded, but its brevity comes from omission rather than discipline — there is simply nothing else to say.

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 simple setter with no output schema and adequate annotations, the description is still too thin: it omits the staleness/replay contract and any permission or targeting context an agent would need to invoke it 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?

The description contributes no parameter meaning beyond 'status light' loosely implying the color enum. With 67% schema coverage, the one undocumented parameter (color) is at least bounded by its enum, but the description does not compensate for the gap or explain issued_at/request_id 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?

States a specific verb and resource ('Set the status light'), which is enough to tell it apart from the reins_* siblings and 'drive'. It is clear but bare: nothing indicates scope, target device, or effect beyond the name.

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 guidance, no preconditions, and no mention of alternatives. The agent gets no help deciding when this tool is appropriate versus the other five siblings.

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