GetBody

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

Annotations already declare non-readonly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new behavioral context: the lease must be CONFIRMED and the call only works within a timing window. It doesn't say what happens if called outside that window (error vs. no-op), which would complete the picture.

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, zero filler, with the primary action and its effect front-loaded and the timing constraint as a compact second sentence.

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, non-destructive, idempotent action with full schema coverage and annotations, the description covers precondition, effect, and timing window. Only the failure behavior outside the window is left implicit.

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% for the single lease_id parameter, so the baseline is 3. The description adds a modest constraint on the id's referent ('one of your CONFIRMED leases'), implying it must be an owned, confirmed lease, but supplies no format or lookup guidance.

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 ('Activate') and resource ('one of your CONFIRMED leases') with the outcome spelled out: 'so its robot can take commands.' This is clearly distinguishable from sibling mutations like cancel_lease or return_lease.

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 applicability window ('5 minutes before the window starts until it ends') and a state precondition (lease must be CONFIRMED), which tells the agent when the call will succeed. It does not name alternatives (cancel_lease, return_lease) or say when not to use it, keeping it short of 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?

Beyond the readOnly and non-destructive annotations, the description discloses the privacy boundary: no owner and no exact location, with location approximated to about 11 km. It also clarifies that asking prices are display-only and that filtering does not modify anything, which adds useful behavioral context beyond structured 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?

The key constraint, no account needed, is front-loaded, and the description is compact overall. The long enumeration of returned fields is dense and partly duplicated by the output schema, but it remains a single efficient paragraph rather than sprawling prose.

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?

Given rich annotations, a present output schema, and 89% schema description coverage, the description supplies the remaining context an agent needs: access model, privacy limits, approximate location, display-only pricing, and non-mutating filter behavior. Nothing critical for correct invocation appears to be 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 description coverage is high at 89%, so the input schema already does most of the parameter documentation. The description only says filters narrow results and does not add filter-specific meaning beyond that 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?

The description uses a specific verb and resource: it returns approved robot listings with a detailed public-field inventory. The title and description clearly establish the browse/list scope and the no-account condition, enough to distinguish it from transactional siblings such as request_lease or activate_lease.

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 clearly states the usage context: no account is needed, filters narrow results, and nothing is changed. It does not explicitly compare this tool with the more task-oriented sibling find_robot_for_task, so the alternative-routing guidance is implied rather than spelled 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?

The description aligns with the annotations (destructiveHint=true, idempotentHint=true) by framing the operation as a withdrawal/cancellation. It adds useful precondition context about which inquiries and promises can be cancelled, but with annotations already covering safety and idempotency, it does not disclose further behavioral details such as permissions, side effects, or what happens on repeated cancellation.

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 a single, front-loaded sentence with no wasted wording. It efficiently communicates the action and the conditions for use.

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 tool with rich annotations, the description covers the purpose and preconditions, but it leaves the key parameter ambiguous: how to cancel a promise when only inquiry_id exists. That gap is significant enough to limit completeness despite the tool's otherwise low complexity.

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 compensate, but it does not explain the sole parameter inquiry_id. It also creates ambiguity: the tool can cancel a 'promise', yet the only parameter is inquiry_id, and the description does not explain how a promise is identified or whether the same ID 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 uses specific verbs (withdraw, cancel) and resources (inquiry, promise), and it distinguishes inquiry cancellation by stating the inquiry must be one the caller sent and still open or offered. It is clear, but it does not explicitly differentiate this from the sibling cancel_lease tool, which could matter given the overlapping idea of cancelling a 'promise'.

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 state-based usage conditions: the inquiry must be one you sent and still open or offered, and the promise must be one you accepted. It does not state when not to use it or point to the cancel_lease alternative, so it stops short of full 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?

Goes well beyond the annotations by enumerating the concrete side effects: the robot is freed, the not-yet-live control token is revoked, the host is notified, and nothing is charged. It also discloses an automatic server-side cancellation path, so an agent understands the null-action case. This matches destructiveHint=true without contradicting it.

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, zero filler. The eligibility constraint and side effects are front-loaded before the secondary auto-cancellation caveat.

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?

Covers eligibility, side effects, billing, and the automatic-cancel edge case for a single-parameter mutation, which is close to complete. The one gap is return behavior (there is no output schema, so an agent can't tell what a successful cancel returns or what errors look like for a lease already ACTIVE).

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?

Only one parameter with 100% schema coverage, so the schema already carries the documentation burden and baseline is 3. The description adds mild value by implying ownership scoping ("one of your leases") and constraining the id to a REQUESTED/CONFIRMED lease, but says nothing about format or error behavior for a wrong-state id.

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 (cancel) and resource (one of your leases) plus the exact eligibility window (REQUESTED or CONFIRMED, before ACTIVE). The parenthetical state names distinguish it cleanly from activate_lease and return_lease without needing to open their schemas.

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 the condition for use (lease must still be REQUESTED or CONFIRMED) and implicitly routes post-ACTIVE cases elsewhere via "before it goes ACTIVE". The auto-cancellation note is useful guidance that sometimes no call is needed, though it never names return_lease as the explicit alternative.

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, openWorldHint=true, idempotentHint=false and destructiveHint=false. The description adds genuinely new behavior: nothing is reserved, and the reply arrives via notification settings and in list_inquiries. It doesn't warn that repeated calls create separate inquiries despite non-idempotency, which would have closed the gap.

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 purpose and trigger, followed by the no-reservation guarantee and the reply channel. No filler or repetition of schema fields.

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?

Explains where the response appears, which is important given there is no output schema. Minor gaps remain around what granted_permissions should contain and whether duplicate inquiries are expected, but the agent has enough to call 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?

Schema coverage is 83%, so the schema already documents message, body_kind, and both window fields. The description's 'offer other windows' hints at what window_start/window_end mean in an inquiry context, but adds nothing about granted_permissions, the most consequential required parameter.

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 ('Ask a listing's host about a robot') and scopes it to offline or currently-leased robots. The 'Reserves nothing' clause distinguishes it cleanly from request_lease, a sibling that obviously does reserve something.

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 a clear trigger condition (robot offline or currently leased) and describes the two request shapes (come online now, or offer other windows). It never names request_lease or cancel_inquiry explicitly, so the routing 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?

Annotations already flag the write-class profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), but the description adds real context beyond them: it discloses the side effect ('records the request' when nothing matches), that auth is unnecessary ('No account needed'), and that some bots are remote vs delivered. It doesn't mention rate limits or the follow-up flow in depth.

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 trigger sentence, and the example list is genuinely useful rather than filler. It runs a bit long and could compress the chore enumeration, but no sentence is purely redundant.

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 an output schema present, return values need no prose, and the description still covers auth (no account), side effects (request recording), and delivery modes. Nothing an agent needs to call this 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 description coverage is 100%, so all four parameters are already documented with examples in the schema itself. The description only restates the task-input idea ('Describe the task in plain words') and adds no syntax or format detail the schema lacks, 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 ('find') and resource ('robot') scoped by task, and the domain (real-world physical work) separates it cleanly from the lease/inquiry/listing siblings. An agent can identify what this does 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?

'Use whenever the user needs something done in the physical world' with a concrete category list gives a clear when-to-use trigger, and 'The user doesn't need to mention robots' preempts a common failure mode. It does not, however, name any sibling alternative or an exclusion case, so it stops short of 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 cover readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds meaningful behavior: a sensor fault is reported and does NOT stop the lease, and the lease-state requirement. It omits timeout/rate behavior, keeping it short of a 5.

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, with the read-only safety signal and the core resource front-loaded, followed by the precondition and edge case. 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?

There is no output schema, and the description still explains the return form (an image, or the latest reading of a named feed) plus the failure mode. That is everything an agent needs 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?

Schema coverage is 100%, so both parameters are already documented. The description adds only marginal meaning for `feed` (that it returns the latest reading of another offered feed) and nothing about lease_id beyond the schema's 'Lease id.' 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?

Names a specific verb (read/get) and resource (latest frame from the leased robot's camera feed), and covers the alternate case of a named feed. An agent can distinguish it from get_robot_status or list_robot_commands 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?

States the precondition that the lease must be ACTIVE and supervisory, which tells the agent when the call is valid. It does not name a sibling alternative for cases where no frame is available, but the context is clear.

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=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only marginal behavioral context: that the result may be a renter or host inquiry and may include a 'promise'. It says nothing about not-found behavior or access requirements.

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 short sentence with the core subject front-loaded and no filler. The sentence-fragment phrasing ('One inquiry...') is slightly terse but efficient.

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 hinting at the return shape, and it does so only partially ('including its promise if one was made'). For a simple read-only, single-parameter tool whose safety profile is covered by annotations, this is minimally adequate but leaves the response contents underspecified.

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% and the description never mentions inquiry_id or its type/format expectations. With a single parameter named inquiry_id the meaning is mostly self-evident from the schema, but the description does nothing to compensate for the missing schema documentation.

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 single inquiry) and its scope ('renter or host'), which distinguishes it from the sibling list_inquiries without opening either schema. It stops short of saying exactly what an inquiry object contains, so it's clear but not maximally specific.

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 guidance and no named alternative, even though list_inquiries and respond_inquiry/cancel_inquiry sit right next to it. An agent must infer that this is the single-record fetch rather than the list or mutation tools.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only 'current state', which hints at a point-in-time snapshot but provides no additional behavioral context (e.g. whether state changes over time, staleness, or error behavior for unknown lease ids).

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 padding or waste, and the key noun is front-loaded. However, the brevity reflects under-specification rather than tight editing, so it does not reach the top of the scale.

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 with a full safety annotation profile, this is minimally adequate. With no output schema, the description's brief mention of 'current state' is the only hint at what is returned, and it is too thin to fully carry that burden, but nothing critical is misleading.

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% for the single lease_id parameter, though the schema's own description ('Lease id.') is itself thin. Per the rubric, full schema coverage establishes a baseline of 3, and the description adds no format or sourcing detail beyond it.

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 (a lease) and indicates it returns current state, but it is a noun phrase that closely echoes the title 'Get a lease' rather than stating a specific verb+resource. It does nothing to distinguish this read tool from the many sibling lease operations (activate_lease, cancel_lease, dispute_lease, reclaim_lease, etc.).

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 guidance, no prerequisites, and no mention of alternatives despite a crowded sibling set of lease tools. The agent must infer that this is the read path for lease state.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, and the description reinforces 'Read-only' while adding meaningful behavioral context. It discloses that the response includes lease state, control mode, online/halted status, granted commands, feeds, and whether the robot can accept a command now with the reason if not; the only notable gap is that it does not explain error behavior for invalid leases.

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 front-loaded with 'Read-only' and then packs the relevant status fields into a single efficient sentence. It is dense but largely free of waste, though the long enumerated clause could be slightly easier to scan if structured.

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?

Because there is no output schema, the description carries the burden of describing what status information is returned, and it does so with a detailed list of lease, robot, command, and feed status fields. It is complete enough for an agent to understand the tool's value and call it with a lease_id, though it does not specify the exact response shape or failure cases.

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 lease_id clearly typed and described as 'Lease id.' The description adds only the ownership implication 'One of your leases' and does not provide additional syntax, format, or constraint details beyond the schema.

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 states the specific resource and scope: status for one of the caller's leases and its associated robot. It lists the concrete status dimensions returned, so an agent can tell this is a read-only status lookup, though it does not explicitly contrast itself with siblings like get_lease or list_robot_commands.

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 by the phrase 'One of your leases and its robot' and the detailed status fields, which suggests when an agent would want this tool. However, it gives no explicit when-to-use guidance, exclusions, or named alternatives such as get_lease for lease-only details.

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 safety is covered. The description adds genuine context beyond them: the result ordering ('newest first') and that unanswered inquiries appear with the answer absent ('when there is one'). It says nothing about pagination, result caps, or volume, which matters for a list 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 tight sentences, with the scope and ordering front-loaded and no filler. Every phrase 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?

An output schema exists, so return shape needn't be described, and annotations cover the safety profile. The remaining gaps — valid values for 'status' and any limit on how many inquiries are returned — leave the tool callable but not reliably callable.

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% — the single 'status' parameter is an undescribed free-form string with no enum. The description calls it an optional status filter but never enumerates valid status values, so an agent cannot construct a valid filter without guessing.

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 resource ('the inquiries you sent') plus its ordering ('newest first') and content ('with the host's answer'), which is enough to separate it from get_inquiry (single item) and cancel_inquiry/create_inquiry. It never names a sibling explicitly, 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?

'Optional status filter' implies the tool can be narrowed, and 'you sent' implies a personal scope, so usage is inferable. But there is no statement of when to prefer this over get_inquiry for a single item, nor any prerequisite or exclusion.

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, idempotent read operation. The description adds useful behavioral context beyond that: it returns owner-allowed commands with descriptions, parameters, examples, and available feeds, which is meaningful because 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?

The description is compact and front-loaded: 'Read-only' establishes safety immediately, then the return contents are described without filler. Every clause 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 simple one-parameter read tool with no output schema, the description sufficiently explains what is returned and the lease/owner scoping. It could be stronger by explicitly routing users to send_robot_command for executing commands, but otherwise it covers the essential context.

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% for the single lease_id parameter, so the schema already documents it. The description reinforces that the listing is scoped to the lease, but adds no format or validation details beyond that.

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 and resource ('List robot commands') and scopes it to commands the owner allows on a lease. It clearly describes what is returned, but it does not explicitly distinguish the tool from the sibling send_robot_command.

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 read-only nature and lease scope imply discovery use, but the description never states when to use this versus send_robot_command or any other sibling. The intended usage is inferable but not explicit.

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 the annotations (readOnlyHint=false, idempotentHint=false), the description discloses the asynchronous approval workflow, that a human operator at GetBody approves, the three possible states, that rejection comes with a reason, that the robot is controlled one command at a time, and that nothing is charged. These are exactly the behavioral facts an agent cannot infer from structured fields.

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 tight sentences, front-loaded with the action and the permission semantics, then the approval lifecycle, then the billing clarification. No sentence is redundant or could be dropped without losing 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 7-parameter, non-idempotent mutation with no output schema, the description covers the lifecycle, polling target, and cost implications well. It omits what the call returns (a lease identifier) and the activation step via activate_lease, which an agent would need to complete the workflow.

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 high (86%), so the baseline is 3, but the description adds real meaning by explaining granted_permissions as 'the subset of the listing's command names you want to use' and by pointing at browse_listings for the listing_id source. The window and payment parameters are left to the schema, which already documents them.

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 and resource ('Request a time-boxed lease on a listing') and anchors listing_id to the sibling browse_listings. It does not explicitly distinguish itself from lifecycle siblings like activate_lease or create_inquiry, so sibling differentiation is only partial.

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 context for when to call it and what happens next ('stays REQUESTED until then (poll get_lease), then CONFIRMED, or REJECTED'), which effectively tells the agent the follow-up tool. It stops short of naming when to prefer an alternative, such as find_robot_for_task before requesting, or activate_lease afterward.

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, idempotentHint=true and openWorldHint=true, so the safety profile is carried. The description adds only the ACTIVE-lease precondition and the finding values, but says nothing about consequences of a 'damage' finding (fees, disputes) or that the robot becomes available again.

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 scope, with no padding. The lowercase 'finding' sentence reads as an afterthought rather than an integrated constraint, but the text is 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?

This is a destructive mutation with no output schema and 0% parameter documentation. The description does not say what the response contains, what happens to the robot or the lease record on return, or how a 'damage' finding affects the outcome — significant gaps for an irreversible-feeling 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It only restates the enum values ('clean' or 'damage') that are already visible in the schema, and says nothing about lease_id beyond hinting it must be one of the caller's active leases.

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 ('End one of your ACTIVE leases and hand the robot back'), which is clearly distinct from activation/requesting flows. However, it never distinguishes itself from the sibling 'cancel_lease', so an agent cannot tell from the text alone which of the two to pick.

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?

'ACTIVE' implies a precondition (the lease must currently be active), which is useful. But there is no explicit when-to-use versus 'cancel_lease', and no statement of what to do if the lease is not active or already returned.

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, the description discloses that the robot acts in the physical world, that an idempotency_key makes retries safe, and that a fault or non-response stops the lease. This adds critical operational context not captured by readOnlyHint/openWorldHint/destructiveHint.

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 tightly written sentences, front-loaded with the action and immediately moving into preconditions, safety, and failure behavior. No sentence is redundant.

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?

The description covers preconditions, physical-world consequences, retry semantics, and fault handling. With no output schema, 'returns the robot's result' is a bit thin on return shape, but for an arbitrary robot command this 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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantic constraints: command must be one of the lease's granted commands, and idempotency_key reuses return the first result rather than acting again. It also notes that params follow the command's schema.

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 runs one command on the leased robot and returns the robot's result. This is clearly distinguishable from siblings like list_robot_commands (listing) and activate_lease (lease management).

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 preconditions for use: the lease must be ACTIVE and supervisory, and the command must be one of the lease's granted commands. It does not explicitly name alternatives such as list_robot_commands, but the context is strong enough to guide selection.

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 readOnly/idempotent/non-destructive, but the description adds genuinely non-obvious traits: no authentication required, no payment side effect ("nothing is charged"), and the exact derivation logic (median of similar approved listings vs. declared value). It stops short of rate-limit or freshness/staleness details, keeping it at 4 rather than 5.

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 key constraint (no account needed) front-loaded, followed by output semantics and the no-charge reassurance. Zero filler; every clause 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?

An output schema exists, so return values needn't be described, and annotations cover safety. The description handles auth, side effects, and fallback logic; the only material omission is the semantics of the required interface_mode value and what "body" refers to.

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 67%, so the bar is roughly baseline. The description does add meaning for robot_type (similarity matching) and declared_value (fallback basis), but the required interface_mode enum receives no explanation anywhere, leaving a real gap for the one mandatory parameter.

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: suggesting USD asking rates (hour/day/week/month) for a robot listing, plus the derivation rule (median of approved listings, else declared value). It is trivially distinguishable from siblings like browse_listings or request_lease, which do entirely different things.

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 account needed" and "Display only: nothing is charged" give clear situational context, but the description never says when an agent should call this rather than proceeding straight to create_inquiry or browse_listings. Usage is implied (pre-listing pricing), not explicitly routed.

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 non-readOnly, idempotent, non-destructive, and closed-world, so the bar is lower; the description still adds real value by disclosing that webhook mode performs a POST to the supplied http(s) URL and that the change is scoped to the caller and permitted while pending. It does not describe failure behavior for an invalid or unreachable target.

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 the mode semantics before the scoping notes. Nothing is redundant; even the parentheticals carry parameter meaning.

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 setter with no output schema, the description covers semantics, scope, and availability. The only gap is what the call returns or how to verify the new setting took effect, which the agent must 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 only 50% (notify_method has no description), yet the description compensates fully: it maps each enum value to the expected notify_target form ('POST to notify_target, an http(s) URL' vs 'an address' vs 'none'). This adds meaning beyond the schema's bare enum and the partial target description.

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 ('Change how GetBody pings YOU') and immediately enumerates the three notify_method modes with their target semantics. No sibling tool touches notification settings, so the agent can identify this unambiguously.

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?

Explains the situations that produce notifications (operator decisions on listings and lease requests, lease inquiries and host responses) and two important preconditions: it works while the agent is still pending, and it only affects the caller's own agent. It does not name a when-not condition, but there is no competing sibling to route away from.

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 (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds genuine behavior: it explains the admission gating ('approved once your owner email is verified') and that it functions while pending, which an agent could not infer from structured fields 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?

A single dense sentence with zero filler, and the most important clause (what you get back, and the pending caveat) is front-loaded. Slightly telegraphic phrasing, but nothing is wasted.

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 an output schema present, the description does not need to explain return format, yet it names the key fields anyway. Combined with the admission-state caveat, an agent has everything needed to call it correctly; only explicit call conditions for its siblings are 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 zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument self-query with nothing for the agent to supply.

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 enumerates exactly what the tool surfaces: agent id, verification, owner-email verification, and admission state. The verb is implicit (report/return), but the resource and scope are unambiguous, and no sibling tool exposes identity/status, so it is clearly distinguishable.

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?

'Works while pending' tells the agent this is usable even before admission, which is useful context. However, it never states when an agent should call this versus other status tools (e.g. get_robot_status), so usage is only implied rather than directed.

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