The Happy Hamper

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

Annotations already declare non-read-only, non-destructive, closed-world. The description adds two things annotations cannot: an authentication prerequisite (customer's Happy Hamper login) and a return-value behavior (serviceZoneId is null when the address is out of the pickup area). It doesn't say what happens on duplicate addresses or whether saving is idempotent.

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, action first, then the out-of-zone caveat, then the auth note. No filler; each sentence carries distinct 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?

No output schema exists, and the description usefully covers the one return signal an agent needs to interpret (null serviceZoneId). Auth requirement is stated. It stops short of describing what a successful save returns (an address id?) or validation failure modes.

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 86%, so line1, line2, city, state, postalCode, label and note are all already documented in the schema. The description adds nothing parameter-specific, 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?

Specific verb + resource: 'Save a pickup or dropoff address' makes the creation of a delivery address unambiguous. It doesn't distinguish itself from the sibling update_address or check_address, which is the only gap.

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 statement of when to use this versus update_address (change an existing one) or check_address (validate serviceability), even though both siblings compete directly. Usage must be inferred from the verb 'save' 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 declare readOnlyHint=true, and the description is consistent with that by framing the tool as handing back a link rather than collecting card data. It adds real behavioral context annotations cannot: the caller cannot capture card details directly, and the customer's Happy Hamper login is required. Link lifetime/expiry and reuse rules are unstated, keeping it below 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 no filler, and the security constraint ('You can't take card details yourself') is prominent. The opening sentence is a fragment whose grammar obscures whether the tool creates a link or is a link, costing some front-loaded clarity.

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 explain what comes back — it only gestures at 'a link' without saying the tool returns a URL to surface to the customer, nor what happens to links already issued. The auth prerequisite is covered, but the return contract, the most important missing piece, is not.

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 there is nothing for the description to disambiguate. Baseline 4 applies; the note about needing the customer's login is identity context rather than a 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 hints that the tool yields a link the customer uses to add a card ('A link where the customer adds their card on our site'), which usefully clarifies that it is not a card-storage call. But it never states the action explicitly (e.g. 'returns a URL') and does not distinguish itself from siblings like add_address or update_profile that an agent might pick instead.

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?

'booking needs one' implies this must be done before book_one_time_pickup, which is genuine context. However, no alternative is named, no when-not condition is given, and the prerequisite is left implicit rather than stated as an ordinal step.

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 is a non-destructive write; the description adds useful context beyond them: a Happy Hamper login is required and the booking must not proceed before the customer approves the quoted price. It stops short of saying whether the booking charges a card, whether it is cancellable afterward (cancel_pickup exists), or what confirmation is returned.

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 core action and then the prerequisites, with no filler. The opening is a telegraphic fragment ('One pickup on a date') rather than a complete statement, which costs a point but not usability.

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 mutation tool with no output schema, the description should describe what the caller gets back (a booking confirmation, pickup ID, charged amount) and cover the two undocumented optional parameters. Auth and price-approval preconditions are covered, but the return behavior is left entirely unspecified.

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 most parameters are already documented in the schema (bags tiers, date format, express surcharge). The description's reference to 'the price' only loosely hints that bags maps to 1-bag/2-bag pricing, and it adds nothing about discountCode or dropoffAddressId, which lack schema descriptions.

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 the resource precisely ('One pickup on a date'), which distinguishes it from subscription siblings like start_subscription and from update_pickup/cancel_pickup. The verb is only implied by the tool name rather than stated in the description, so it falls just short of a full verb+resource statement.

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 chain: quote_one_time_pickup first, then customer approval of the price. That is concrete sequencing with a named sibling. It does not, however, state when NOT to use it (e.g., recurring service should go to start_subscription).

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 mark this as destructive and not read-only; the description adds meaningful behavior beyond that: only one pickup is cancelled, the subscription continues, the charge cutoff is 8:00 AM, and customer login is required.

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, front-loaded sentences with no filler. The scope, charge policy, and auth requirement each earn their 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?

Provides enough high-level context for a simple cancellation, including charge timing and login requirement. However, it omits how to obtain the required pickupId and does not describe the confirmation or result, and no output schema fills that 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 description coverage is 0% and pickupId is undocumented in both schema and description. The phrase 'one upcoming pickup' implies the parameter selects a pickup, but it gives no ID format, source, 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 and resource: cancel one upcoming pickup. The parenthetical clarifies scope by noting the subscription carries on, distinguishing it from subscription-level changes and from uncancel_pickup.

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 clear usage context: use before 8:00 AM to avoid a charge, and a login is required. It does not explicitly compare against alternatives such as update_pickup or state when not to cancel.

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 tell the agent this is a non-read-only, non-destructive, closed-world mutation, and the description adds the crucial side effect that the subscription "starts again at the current price, with its pickups booked right away." That restart-and-rebook behavior is exactly the kind of consequence annotations cannot express. It stops short of saying whether existing pickups are cancelled or whether the restart is reversible.

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 sentence front-loads the action and the three changeable dimensions, then adds behavior and the auth requirement. Dense but no wasted words; the colon-delimited structure reads slightly run-on but is easy to parse.

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 mutating tool with a real restart side effect and no output schema, the description covers the key consequence and the auth prerequisite, which is most of what an agent needs. It leaves open what happens to already-booked pickups, what the response contains, and the role of dropoffAddressId.

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 only 40%, so the description must compensate, and it partly does: "another option" maps to serviceZoneScheduleId, "address" to addressId/dropoffAddressId, and "number of bags" to bags. But dropoffAddressId is left ambiguous (is it a different thing from addressId?) and the description doesn't clarify it, so the low coverage is not fully rescued.

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?

"Moves a subscription to another option, address or number of bags" names a specific verb (move) and the three resources that can change, which reads clearly against the sibling update_subscription only implicitly. The differentiation from update_subscription is implied by the field list rather than stated, 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?

It states a prerequisite ("Needs the customer's Happy Hamper login") but gives no explicit when-to-use guidance. An agent facing update_subscription vs change_subscription has to infer the distinction from the listed fields rather than being told which to pick.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the shape of the result (cadence, first pickup, return, discounted prices), though it is silent on what happens when an address is not serviceable.

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 sentence, front-loaded with the core question ('whether we pick up at an address') before detailing the payload. Dense but every clause conveys return-value information; only the parenthetical cadence aside is mildly verbose.

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 must describe returns and it does so thoroughly — availability, cadence, first/return pickups, and pricing. The one gap is the negative case: an agent cannot tell whether unserviceable addresses return a flag, an empty list, or an error.

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?

All four parameters are required and self-evident (line1, city, state, postalCode), with 75% schema description coverage. The description adds no addressing guidance beyond the schema, 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+resource ('whether we pick up at an address') and enumerates what the response contains: frequency, first pickup, return date, and prices with subscriber discounts. It is clearly distinguishable from mutation siblings like add_address/update_address, though it never explicitly contrasts with get_pickup_options.

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: an agent can infer this is a pre-signup serviceability/quote lookup. There is no explicit 'use this before start_subscription' or any statement of when to prefer this over get_pickup_options or quote_one_time_pickup.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; the description adds the non-obvious auth requirement, which is genuine added context. It stops short of covering behavior on failure (e.g. what happens without a login) or any limits on the booking lists.

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 returned data and closed with the auth prerequisite. The content list is dense but each item is distinct and useful; slightly run-on phrasing keeps it from a 5.

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 by naming the major data groups the agent will receive. For a zero-parameter read tool with read-only annotations, the only meaningful gap is error/unauthenticated behavior.

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; scoring follows the 0-param baseline. The listed return fields are informational rather than parameter clarification.

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 which account data is returned (profile, addresses with ids, laundry preferences, saved card status, subscriptions, bookings, upcoming pickups), which makes the resource unmistakable against siblings like update_profile or list_past_pickups. It lacks an explicit verb (no 'retrieve'/'fetch'), reading as a noun phrase, but the read intent is clear.

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 states the prerequisite ('Needs the customer's Happy Hamper login'), which is real usage guidance, but never says when to call this versus the more targeted siblings such as get_pickup_options or list_past_pickups. Usage is implied by the enumerated contents 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful non-annotation detail, the Happy Hamper login requirement, but says nothing about failure modes such as an out-of-service-zone address or missing options.

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, no filler; the returned-field enumeration is front-loaded and the auth prerequisite is a short trailing clause. The first sentence is dense with field names but every item earns its place by pre-describing an output that has no output schema.

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 enumerates the return shape (serviceZoneScheduleId, day, frequency, nextDate, backDate, prices with discount), and the auth prerequisite is covered. Remaining gaps are error and empty-result behavior for a single-required-param read tool, which is a minor omission.

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 single addressId parameter has 0% schema description coverage, so the description must carry the load. 'At one of their addresses' implies the id must be a customer-owned address, which is real added meaning, but format and source (e.g. from get_account) are never specified.

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 and scope: the subscription options a customer can start at one of their addresses, plus the exact fields returned. It is clearly not a booking or quote tool, but it never names a sibling (quote_one_time_pickup, get_service_info, start_subscription) to sharpen the boundary.

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: because the tool returns 'subscriptions the customer can start', an agent can infer it is the discovery step before start_subscription, and the login prerequisite is stated. There is no explicit when-to-use, when-not-to-use, or stated 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=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral detail that the annotations do not: prices are in cents and pre-tax, and a subscriber discount is included. It does not address staleness of prices, whether the first-bookable-day reflects real-time availability, or any caching 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 sentence that leads with the most important item (service areas) and enumerates the rest efficiently. Slightly awkward as a bare noun phrase with no verb, and the title 'What we charge and where' partly duplicates the first clause, but there is 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 is the only contract for return values, and it enumerates the four pieces of information an agent should expect. That is sufficient to decide whether a follow-up call (e.g. quote_one_time_pickup) is needed, though it does not say whether the values are structured per-region or flat.

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; the description correctly implies a parameterless global lookup rather than anything scoped by address or account.

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 the specific content the tool returns: pickup areas, current prices in cents before tax, the subscriber discount, and the earliest bookable pickup date. That is concrete enough for an agent to distinguish it from pricing-adjacent siblings like quote_one_time_pickup, though the noun-phrase phrasing never states a verb ('returns'/'retrieves'), so the purpose is inferred rather than declared.

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 explicit when-to-use or when-not-to-use guidance, and no sibling is named. An agent must guess whether to call this or quote_one_time_pickup/get_pickup_options for pricing questions. The content list implies a static service/pricing lookup, but that is inference, not 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 establish that this is a non-destructive write in a closed world. The description adds one useful behavioral fact beyond that: a follow-up email is sent when the area becomes serviceable. It still doesn't say what gets stored, how duplicate signups are handled, or what a success response contains.

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 no filler, and the purpose comes first. The phrasing 'address we don't pick up at yet' is slightly awkward and forces a second read, which costs it a point.

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 five-required-parameter mutation with no output schema. The description covers intent and the deferred-notification behavior, but it never says what the agent gets back or how failures are surfaced. That leaves an agent unable to predict the outcome of a call.

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 only 60%. The email and city properties have no descriptions at all, yet the description addresses only 'email' and gestures vaguely at 'address'. It adds no format, normalization, or validation guidance to compensate for the two undocumented fields.

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 concrete verb-and-resource pair: it captures an email tied to an address that is not yet serviced, and promises a notification when service arrives. That is clearly distinct from siblings like add_address or start_subscription. It stops short of naming any sibling, so the agent has to infer the boundary itself.

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 precondition is implied: you use this only for an address we don't pick up at yet. The description never says so explicitly, though, and it doesn't tell the agent whether to check_address first or whether an already-served address is rejected here. The guidance is present but only by 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?

Beyond the annotations' read-only and non-destructive hints, the description adds useful behavioral context: results are capped at 20, only finished pickups are included, ordering is newest first, and authentication is required. It does not discuss pagination or error behavior, but the annotations already cover the safety profile.

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 result description and followed by the authentication prerequisite. Every sentence earns its place 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 parameterless read tool with no output schema, the description gives enough to understand what will be returned: up to 20 finished pickups in descending order, requiring login. It stops short of describing the returned fields, but that is a minor gap given the tool's simplicity.

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 has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description appropriately focuses on scope and prerequisites instead.

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 resource and scope: the customer's last 20 finished pickups, returned newest first. It distinguishes this history-retrieval tool from sibling tools such as get_pickup_options or cancel_pickup, though the verb is implied by the tool name rather than stated in the description.

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 provides the prerequisite that a Happy Hamper login is needed, but gives no guidance on when to use this tool versus alternatives or when not to use it. The usage context is only implied by the resource name.

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 and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the authentication requirement (Happy Hamper login) and describes what information is returned (cost, availability, return date).

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 core purpose and output, followed by the single prerequisite. No 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?

For a 2-parameter read-only tool with no output schema, the description covers what the call returns and the auth prerequisite, which is close to sufficient. The one gap is the origin/format of addressId, which an agent needs to supply 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 50%: 'date' is documented as YYYY-MM-DD but 'addressId' has no schema description. The description loosely maps 'at one of their addresses' to addressId and 'on a date' to date, but does not clarify where addressId comes from or its format, so it only partially compensates.

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 (quote/price) and resource (one-time pickup), and enumerates the three outputs: cost, bookability, and return date. This clearly separates it in spirit from book_one_time_pickup, though it does not explicitly name 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?

Usage is implied by the quote-vs-book framing and the prerequisite 'Needs the customer's Happy Hamper login,' which is useful context. However, it never explicitly says to call this before book_one_time_pickup or contrasts with get_pickup_options, leaving the routing 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 this is a non-read, non-destructive, closed-world write, so the safety profile is covered. The description adds two genuinely useful pieces of context beyond that: the authentication requirement ('Needs the customer's Happy Hamper login') and the override precedence with subscriptions/pickups. It does not say whether the call replaces existing preferences wholesale, which matters since both parameters are required.

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 no filler, leading with what the preferences mean and following with the login requirement. Nothing could be cut 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 simple two-parameter write with full schema coverage and no output schema, the description supplies the authentication requirement and the scope of the setting. It leaves open the return behavior and whether existing subscription-level preferences are touched, which is a modest gap rather than a blocking one.

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 schema itself documents the important semantics (null scent = unscented, free_clear is fragrance-free and takes no scent). The description restates the two field concepts but adds no format, default, or interaction detail beyond the schema, 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 names the two resources being configured (detergent and scent) and their scope as standing defaults for every load, which is enough to tell it apart from siblings like change_subscription or update_pickup that override those preferences. It never uses an explicit setting verb, but the tool name carries that, so intent is clear.

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 clause 'unless a subscription or pickup says otherwise' implies this is a global default versus per-order overrides, which is useful precedence context. However, there is no explicit statement of when an agent should call this versus change_subscription or update_pickup, and no prerequisites for the login are framed as 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 declare readOnly=false, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely useful context beyond that — the auth requirement (Happy Hamper login) and the confirmation-before-booking rule — but says nothing about card charging, effective start date, or failure behavior for a mutation.

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 core action and followed by the prerequisite. No filler, though the opening fragment lacks an explicit verb and reads slightly telegraphic.

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 6-parameter mutation with no output schema, the description covers the workflow entry point and auth but omits what happens on success (subscription id? first pickup date?), billing implications, and the meaning of the optional params. 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?

Schema coverage is 67%, so the schema carries most of the parameter meaning. The description only hints that serviceZoneScheduleId comes from get_pickup_options; it does not clarify the confusing bags-vs-bagCount distinction (price tier vs. total bags) or explain discountCode, which the schema leaves undocumented.

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 outcome — setting up regular/recurring pickups — and anchors it to an option returned by get_pickup_options, which implicitly separates it from book_one_time_pickup. The verb is somewhat elliptical ('Regular pickups on an option...'), but the resource and scope are unmistakable.

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 prerequisite chain: call get_pickup_options first, confirm day and price with the customer, then start. It does not explicitly name when to prefer book_one_time_pickup or change_subscription/update_subscription instead, so the sibling routing 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 only state the safety profile (not read-only, not destructive, closed-world); the description adds genuinely new behavior: the restoration is state-preserving ('as it was'), it is time-boxed to 1:00 AM on the pickup day, and it needs an authenticated customer session. It does not say what happens if the slot is no longer available or whether the restore can fail, so it stops short of full transparency.

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 sentence with the core action front-loaded, followed by the deadline and auth requirement — no filler, nothing that could be cut without losing 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 one-parameter mutation with no output schema, the description covers the essentials: what is restored, the hard time window, and the auth prerequisite. It is only missing the pickupId provenance and failure/edge-case behavior (expired window, unavailable slot).

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 required parameter, pickupId, with 0% schema description coverage and no mention in the description — the agent gets no guidance on where to obtain it (e.g., list_past_pickups). The name is largely self-explanatory and the tool is single-parameter, so the gap is modest rather than blocking.

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 ('bring back a pickup canceled by mistake') and adds the key qualifier 'as it was', which distinguishes it from a general update_pickup by signaling restoration of prior state rather than new values. It never names a sibling tool explicitly, so differentiation is inferential rather than stated.

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 context is clear: use it for a pickup canceled by mistake, and it must happen before 1:00 AM on the pickup's day, plus it requires the customer's Happy Hamper login. There is no explicit exclusion or pointer to an alternative (e.g., what to do after the deadline, or use update_pickup to change details), 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?

Goes beyond the annotations by disclosing the pickup-booking lock on street edits and the required Happy Hamper login — real operational context not captured by readOnlyHint/destructiveHint=false. It still doesn't say whether omitted fields are preserved, nor what error surfaces when the lock is violated.

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 the primary action first, then the constraint and auth requirement. No 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?

Handles auth and the conditional street restriction, and annotations already declare the safety profile. For an 8-parameter mutation tool with 13% schema coverage and no output schema, it leaves meaningful gaps: partial-update semantics, which parameters the pickup lock actually covers, and failure behavior.

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 only 13%, so the description must carry the semantic load. It partially does by naming the mutable fields, but 'street' is ambiguous against five separate schema properties (line1, line2, city, state, postalCode), and required addressId plus null/omission semantics are undocumented in both places.

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 (change) and resource (address), then enumerates the mutable parts — label, notes, and street — which clearly separates it from add_address and check_address. It stops short of naming sibling tools or covering the full address field set, so it's clear but not fully differentiated.

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?

Provides a concrete when-not condition: street fields may only be changed until a pickup has been booked at that address. It also states an auth precondition. It does not point to alternatives (e.g. add_address for a new address, check_address to inspect state), 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 establish that this is a non-destructive mutation with no open-world side effects. The description adds useful behavioral context beyond those annotations: it requires the customer's Happy Hamper login and only applies before the pickup is collected. It does not discuss failure modes or partial-update behavior, but the added auth and timing context 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?

The description is front-loaded and efficient: the first sentence states the action, timing, and mutable fields, and the second adds the login prerequisite. There is no redundant or wasteful 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?

For a non-destructive update tool with annotations covering safety and no output schema, the description supplies the key missing context: auth requirement, timing constraint, and the modifiable fields. It could be more complete by clarifying partial updates or expected behavior after the change, but it is largely sufficient.

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 only 60% schema description coverage, the description usefully names four of the five parameters in plain language: bag count, Job notes, 24-hour turnaround, and detergent/scent. It does not explain the required pickupId parameter or elaborate on null/default behavior, but the field mapping is clear and compensates for much of the schema gap.

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 — change one upcoming pickup — and enumerates the modifiable attributes: bag count, job notes, turnaround, detergent and scent. This is specific enough to distinguish it from siblings such as cancel_pickup or book_one_time_pickup 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?

It gives clear usage context: use this for an upcoming pickup before collection, and it names the customer login prerequisite. It does not explicitly say when not to use it or point to cancel_pickup for cancellations, so it stops short of full alternative 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 declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation profile is partly covered. The description adds a genuine auth prerequisite (customer login), which is real context beyond the annotations, but it says nothing about whether the change is reversible, what happens to the unset field, or error 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?

Two short sentences, front-loaded with the action and followed by the prerequisite; nothing is padded. The second sentence is slightly vague ('Happy Hamper login') but earns its place as an auth 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?

This is a mutation tool with no output schema and an under-specified schema (no required fields), yet the description covers none of the consequential details: partial-update semantics, what a success response contains, or failure modes. For an update operation it leaves too much to inference.

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?

At 50% schema coverage only 'phone' is documented (as a US number), and the description merely restates the two parameter names. Critically, the schema marks zero required parameters while the description says 'name or phone', leaving the agent unsure whether at least one must be supplied — a gap the description should close and 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 ('Change') and precise resource ('customer's name or phone number'), which implicitly separates it from update_address and update_subscription among the siblings. It does not name an alternative explicitly, but the scope 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 description gives a prerequisite ('Needs the customer's Happy Hamper login') but never says when to reach for this versus update_address or get_account, nor any exclusion. Usage is only implied by the resource name.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description still adds real consequence information beyond the annotations: 'Canceling also cancels its upcoming pickups', plus the auth requirement. It stops short of saying whether a cancel can be undone or whether the operation is atomic across the listed 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?

One sentence front-loads the primary state changes before the attribute edits, and the parenthetical '(until a date, or until resumed)' disambiguates pause modes efficiently. The trailing auth sentence is short and earns its place. Minor density in the middle clause list, but 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 destructive, 7-parameter mutation with no output schema, the description covers the side effect of cancel and the login prerequisite, which are the two things most likely to cause a bad call. What remains missing is whether cancel is reversible and whether multiple fields can be combined in one call, keeping it below the top score rather than inadequate.

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 57%, and the description restates the fields that the schema already documents well (pausedUntil date, bag count, job notes, detergent and scent). cancelReason has no schema description and is not covered by the description either, leaving a gap. The null-resets-to-Laundry-preferences behavior is valuable but is already present in 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 names concrete operations on a specific resource: pause, resume, cancel, and edits to bag count, Job notes, detergent and scent. An agent knows exactly what capability is behind the name. It does not differentiate against the sibling change_subscription, which plausibly overlaps with the 'change its bag count / detergent / scent' half, so a 5 is not warranted.

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 enumerates what can be done but never states when to choose this tool over change_subscription or when-not to use it. Usage is only implied by the operation list. The one piece of genuine guidance is the prerequisite 'Needs the customer's Happy Hamper login', which tells the agent a credential context is required.

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