WaitApp

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

Annotations already declare it is a non-read-only, non-idempotent, non-destructive write, but the description adds the genuinely valuable workflow trait: this is a REQUEST the venue reviews and confirms, not an instant confirmation — an agent needs that to set user expectations and to handle polling via check_booking_status. It does not add auth/permission or rate-limit detail, so it stops 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, zero waste, with the scoping exclusion front-loaded in the first parenthetical and the request-vs-confirmation caveat placed last as the key behavioral takeaway.

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 purpose, alternatives, and the approval-workflow semantic, but for a 7-parameter, 4-required write tool with 14% schema coverage and no output schema, the description leaves most parameters unexplained and does not indicate what the request response contains or how to follow up.

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 14% — only 'datetime' is documented — so the description carries the burden and largely fails it. It mentions the venue's city/countryCode provenance (fields that do not even appear in the schema's properties) but says nothing about restaurantId, guestName, guestPhone, guestCount, guestEmail, or notes.

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 ('Book a table reservation') with an explicit scope qualifier that rules out the closest sibling ('not a room/stay — use book_room for that'). An agent can distinguish this from book_room and book_service without opening any 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?

Explicitly names the alternative (book_room) and the condition that selects it, states the upstream dependency (city/countryCode come from search_venues), and sets expectations that this is a review-and-confirm request rather than an instant booking. When-to-use and what-to-use-instead are both covered.

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

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

Annotations declare readOnlyHint=false and non-destructive, non-idempotent. The description adds crucial context: it's a request not confirmation, no payment collected upfront, deposit may follow. Lacks disclosure of what happens on failure or request lifetime, but substantial value added.

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 well-structured sentences: purpose, cross-references, and key behavioral caveat. Every sentence earns its place; front-loaded with the main action.

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 9 parameters with low schema coverage, the description covers the key behavioral aspects (request nature, payment) but doesn't explain all parameters or failure modes. Still sufficient for an agent to understand the main flow and when to use it.

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 22%, so more parameter semantics would help. Description mentions dates via check_room_availability and city/countryCode from search_venues, implying required fields like location. But doesn't explain the roles of restaurantId, roomFacilityTypeId, guestName, guestPhone, etc. Baseline 3 given the low coverage and minimal compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Submit a stay booking request') and distinguishes it from siblings by referencing check_room_availability and search_venues. The 'REQUEST not instant confirmation' framing is precise.

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?

Explicitly names alternatives (check_room_availability for free dates, search_venues for city/countryCode) and states the condition. Makes clear this is a request subject to venue review, unlike potential instant booking siblings.

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

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

Annotations only declare the generic hint set (readOnlyHint=false, destructiveHint=false, idempotentHint=false), which is consistent with the description. The description adds genuinely non-derivable behavior: real slot is atomically reserved, confirmation is instant unlike book_room, and no payment is collected here (guest pays at the venue). This is meaningful operational context for money and reservation semantics.

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 dense sentences, front-loaded with the action and scope, followed by prerequisites and the two behavioral facts that matter (instant/atomic, no payment). No filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema to replace, and the description covers the confirmation and payment model well. The remaining gap is the unlabeled identifier naming (restaurantId on a spa booking tool) and the fact that half the parameters get no semantic treatment, which an 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 25%, so the description must carry weight. It hints at guest semantics ('on behalf of a real guest') and points at check_service_availability for practitioner selection, but it never explains restaurantId vs serviceTypeId (venue/service identifiers for a spa), guestPhone (a required param), or guestEmail/notes — the remaining required parameters stay undocumented in both the schema and the 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+resource ('Book a ... SERVICE slot on behalf of a real guest') and immediately scopes it against siblings, naming check_service_availability, search_venues, and explicitly contrasting with book_room. An agent can distinguish it from book_reservation/book_room without opening any 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?

Gives an explicit prerequisite chain: use check_service_availability to find free slots, search_venues to obtain the venue's city/countryCode. It also states the differentiator vs the alternative (book_room) — instant vs presumably non-instant confirmation — which is exactly the routing information an agent needs.

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

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

Annotations only declare the safety profile (non-readonly, non-destructive, non-idempotent, closed-world); the description adds real behavioral context beyond them: a real charge is initiated, the guest must approve a prompt on their own phone, and the ticket is issued only after payment confirms. It does not, however, warn about duplicate charges on retry despite idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each carrying distinct load: the action/channel, the payment/approval flow, and the card alternative. The critical constraint (real charge, guest approval) is front-loaded with zero 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 7-param mutation with no output schema and low schema coverage, the description covers the essential async payment loop and the card fallback, so an agent knows the flow will not complete synchronously. It still leaves tier/quantity semantics and retry-safety 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 description coverage is only 29% (mobileNumber and billingCountry), so the description should compensate. It reinforces that mobileNumber is the guest's own phone for approval, but says nothing about tierId, eventId, quantity limits, customerName, or customerEmail — a notable gap given tier selection is likely required to buy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+channel ('Buy event ticket(s) via mobile money on behalf of a real guest'), which immediately distinguishes it from the reservation/room/service booking siblings. It also names the adjacent read tool (check_event_availability) that exposes what is available.

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 explicit routing: use this for mobile money, and card payment is not supported here — check_event_availability returns a cardCheckoutUrl for that case. What is missing is guidance on prerequisites (e.g. whether availability/tier must be resolved first) and whether retries are safe.

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 (destructiveHint=true, idempotentHint=true). It discloses the two-phase confirmation protocol — the first call cancels nothing and returns what would be cancelled until a call passes confirmed: true — plus a hard rate limit of 3 per day and the fact that refunds are never automatic. These are exactly the operational 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?

Dense and front-loaded: purpose first, then eligibility rules, then refund behavior, then the confirmation mechanism. Every clause carries information, but the single run-on sentence packs four distinct policies together, which costs a little scannability.

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, no-output-schema mutation tool, the description covers eligibility, confirmation, rate limits, and refund semantics, so an agent can act correctly. It never describes the shape of a successful normal response, which is the one remaining 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 already 80%, and the description still adds the crucial semantics for 'confirmed' by defining the dry-run-then-commit protocol, which the schema only labels as 'the person agreed to cancel'. It does not add anything for reason or the orderCode/restaurantId disambiguation, which the schema already covers.

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 precise verb and resource ('Cancel the connected person's own order') and immediately anchors the scope to a known reference point ('under the same rules as the WaitApp website'). No sibling tool competes for this action, and the scope qualifier ('own order') prevents ambiguity with anything else in the catalog.

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?

Explicitly enumerates the when-and-when-not conditions: allowed while neither venue nor rider has started, refused once the rider is collecting or has the food. It also states the downstream consequence (paid orders flagged for venue review, never an instant refund), which tells the agent what outcome to expect before calling.

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, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds that no sign-in is needed, explains the 'pending' status meaning, and clarifies that the phone number is askable from the person – behavior beyond the annotations. It does not cover rate limits or error conditions, hence not 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?

Two sentences, front-loaded with the core action and parameter requirements, plus a useful parenthetical example. Every sentence earns its place; no wasted words.

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 this is a read-only status check with annotations covering safety and no output schema, the description provides all needed context: what the tool does, required inputs and their origins, the no-sign-in behavior, and status interpretation. Nothing essential is missing for an agent 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 description coverage is 33%, so the description must compensate for the undocumented bookingCode and restaurantId parameters. It explains the booking code format and origin, and that the restaurantId must be the same as used to place the booking. The phone parameter is well-covered in the schema, and the description reinforces its usage, adding substantial meaning.

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 (check status) and resource (previously submitted booking or order) identified by code. It names the code example (WA-K4M2) and covers tables, stays, services, delivery, and pre-orders, clearly distinguishing it from siblings like book_reservation or track_order.

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 explains when to use this tool (checking status of a previously submitted booking/order by its code) and the necessary credentials (same restaurantId and phone number, no sign-in needed). It adds a helpful note on status 'pending' but does not explicitly name alternative tools or when-not-to-use conditions.

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. The description adds no behavioral context beyond restating the purpose—it does not describe what 'remaining capacity' means, how it is computed, or what the 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 front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity.

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 read-only check with rich annotations and no output schema, the description conveys the basic purpose but omits what the tool returns (e.g., remaining count) and lacks any usage context. Minimum viable, but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With one parameter (eventId) and 0% schema description coverage, the description must compensate. 'For a specific event' only echoes the parameter name and adds no format, constraints, or identifier expectations.

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 ('Check') and resource ('remaining capacity for a specific event'). The resource 'event' distinguishes it from siblings like check_room_availability and check_service_availability, but it does not explicitly name or contrast those alternatives.

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 no guidance on when to use this tool versus alternatives such as check_room_availability or list_events. The only implied usage is the literal purpose, with no context, prerequisites, or exclusions.

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 covered. The description's only added behavioral content is the 'real availability vs. type existence' distinction, which is useful but modest. No mention of permissions, rate limits, or result shape.

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; the availability distinction is front-loaded and the prerequisite call is the trailing actionable instruction.

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 carries some return-value burden — it does indicate the result is which physical rooms are actually free, which is the key semantic. It stops short of describing the result structure (e.g., per-room list vs. aggregate count), a minor gap for a 4-param read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, with restaurantId and roomFacilityTypeId undocumented in the schema. The description partially compensates by explaining where roomFacilityTypeId comes from (list_room_types), but adds nothing about restaurantId, and checkIn/checkOut semantics are fully covered by 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?

Specific verb (check) plus resource (physical rooms/facilities of a given catalog type) and an explicit scope qualifier: 'real availability, not just that the type exists.' This distinguishes it cleanly from the sibling list_room_types and from check_event_availability/check_service_availability.

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?

Explicitly states the prerequisite: 'Use list_room_types first to get roomFacilityTypeId.' The 'not just that the type exists' clause further clarifies the boundary with that sibling. It doesn't, however, say anything about when to book (book_room) versus just check, so the routing guidance is strong but not exhaustive.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds behavioral value by disclosing the query's temporal semantics — it is a point-in-time slot probe, not a range scan — which affects how the agent interprets the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: purpose and domain first, the key disambiguation second, the lookup prerequisite last. No filler and nothing important buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing what comes back — it never states whether the result is a boolean, a free slot, or a list of alternatives. The serviceTypeId workflow is covered and annotations handle safety, but the return-value gap leaves the definition merely adequate.

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 33%: only startIso is documented in the schema. The description compensates partially by defining serviceTypeId as a list_room_types entry with kind 'service' and pointing to list_room_types to obtain it. restaurantId is left entirely unexplained, so the compensation is incomplete.

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 verb and resource ('check whether a bookable SERVICE ... has a free slot at a specific start time') and explicitly disambiguates from the sibling check_room_availability by contrasting time-slot vs. date-range semantics. An agent can distinguish this from the room and event availability tools without opening any 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 a clear precondition-workflow ('Use list_room_types first to get the service's id') and an implicit routing cue ('not date-range like rooms'). It stops short of naming the alternative tools or stating when this tool should NOT be used, so it is strong but not fully 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?

Annotations already declare idempotentHint=true, readOnlyHint=false, destructiveHint=false, and the description reinforces idempotency with concrete detail ('the same draftId never creates a second order'). It also discloses downstream behavior beyond annotations: the venue must accept the order before delivery starts, and status is tracked via check_booking_status with the returned orderCode.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core action, then provenance, idempotency, and the tracking hand-off. No filler or restated title 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 single-parameter mutation with no output schema, the description covers the lifecycle (draft source, safe retry, venue acceptance, status tracking) and names the returned orderCode. It omits error/failure cases and any permission or charging prerequisites, which would matter for a write 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 coverage is 0% and the schema only types draftId as a string, so the description carries the burden by explaining the parameter's provenance (from place_delivery_order or draft_delivery_order) and its retry semantics. That adds real meaning beyond the bare schema, though it gives no format or validation detail.

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 ('Places a drafted delivery order exactly as drafted') and implicitly distinguishes itself from draft_delivery_order (creates the draft) and place_delivery_order (source of draftId). An agent can tell what this tool finalizes 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?

Explicitly routes the caller by naming the two tools that produce a draftId ('place_delivery_order ... or from draft_delivery_order') and adds a retry-safety note. It does not state when not to use this in favor of place_delivery_order directly, so it falls just short of full when/when-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 declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuine value beyond that by clarifying the side-effect boundary: orders already placed are not affected. It stops short of stating permission requirements or failure behavior for an unknown id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero padding; the destructive action and its scope are front-loaded, and the mitigating side-effect note follows immediately. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive tool with full schema coverage, no output schema, and annotations carrying the safety hints, the description covers purpose, id source, and blast radius. Only failure/error semantics (e.g., unknown or already-deleted id) are left unstated, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single `id` param is fully documented there, so baseline 3 applies. The description's 'use the id from list_saved_locations' largely restates the schema rather than adding format or constraint detail.

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 (Removes) and resource (saved delivery location) scoped to the connected person. It also implicitly distinguishes itself from the read-only sibling list_saved_locations and save_location, so an agent can tell them apart without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the agent where the `id` comes from (list_saved_locations), which is useful routing. However, it never states when deletion is appropriate versus alternatives, whether confirmation is needed, or what happens if the id is stale or invalid — usage is merely implied.

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

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

Annotations only declare the generic profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false). The description goes well beyond them by stating nothing is charged or placed, that a draftId is returned for later confirmation, the auth prerequisite, and the concrete failure modes (venue closed, no delivery coverage, address outside area).

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 core action and what is returned, then flows into prerequisites and parameter mechanics. It is dense but readable; the only real waste is the repeated non-placement clause ('without placing it' / 'WITHOUT placing anything'), which is redundant emphasis.

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 an 8-parameter mutation-style tool with no output schema, it covers auth, prerequisites, cross-tool id sourcing, side effects, failure modes, and even the shape of the return (draftId, items, fee, total, distance, ETA). Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 63%, and the description compensates by explaining the selectedOptions structure (group name + choice name, required groups must be chosen), that deliveryAddress should be the fullest address available, and that savedLocationId is used instead of it. It leaves restaurantId, guestName and guestPhone unglossed, so it falls short of fully covering the 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?

States a specific verb+resource ('Drafts a food/drink DELIVERY order without placing it') and enumerates exactly what the draft contains: priced items, delivery fee, total, distance and ETA. It explicitly names the two siblings that finish the job (confirm_delivery_order, place_delivery_order), so an agent can distinguish them without opening a 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?

Gives explicit routing rules: use confirm_delivery_order to place a draftId, or place_delivery_order for both steps, and notes the latter follows the connection's permission setting. It also states the prerequisite (WaitApp account connected), a validation step (verify venue city/countryCode via search_venues), a data source (list_menu_items for ids/optionGroups) and the required-option rule (required=true must be chosen).

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: it spells out the two permission modes (immediate vs return-for-agreement), that limits and remaining-today quota are reported, and that WaitApp connection status is included.

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 that moves from the core meaning (what the person allowed) to the mechanics (immediate vs confirm) to the extras (limits, remaining, WaitApp). It is dense and slightly run-on with stacked parentheticals, but no sentence 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 no output schema, the description carries the burden of describing the return values, and it does so adequately: permission mode, limits, remaining allowance today, and account connectivity. It stops short of specifying field names or structure, but an agent has enough to know what the call yields and when it is relevant.

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 schema coverage is complete by definition and no parameter explanation is required. Baseline 4 applies; the description adds nothing here but nothing is missing either.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as a read of the connection's authorization state — what the person allowed this connection to do, plus limits, remaining quota, and WaitApp account linkage. It is unmistakably distinct from the booking/ordering siblings since it performs no action itself. It never states a crisp verb+resource ('get permissions'), phrasing the purpose as content instead, which keeps it just below 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?

There is no explicit when-to-use statement or named alternative. The description implies the value of calling it (knowing whether orders go through immediately or need confirmation) which lets an agent infer it should be checked before placing or confirming orders, but this is left to inference 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results are limited to upcoming/published and include both ticketed and free events, which is useful context. It says nothing about pagination behavior despite a limit parameter, so there is a gap beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the resource and scope, with the conditional behavior attached cleanly. No filler or redundancy.

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 read-only list tool whose annotations already establish safety, the essentials are present, but there is no output schema and no mention of result ordering or how the limit interacts with pagination. An agent can call it, but not fully predict the result shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load. It explains restaurantId's omission semantics (all venues), which is real added value, but it never addresses limit — no mention of pagination, the default of 20, or the cap of 50. Partial compensation only.

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 (List) and resource (events), plus meaningful scope qualifiers: upcoming, published, ticketed or free. It does not, however, distinguish itself from close siblings like check_event_availability or buy_ticket, leaving some overlap for the agent to infer.

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 one concrete usage rule — omit restaurantId to search across all venues — which is genuinely helpful. But it offers no guidance on when to use this versus the event-availability or ticketing siblings, so it stops short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered; the description adds real value beyond that by disclosing the response shape (category names plus counts), the optionGroups structure for items with choices, the selectedOptions convention for ordering, and pagination behavior. It stops short of error handling or limits, so not 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 dense sentences with the purpose front-loaded and zero filler; the optionGroups sentence is information-heavy but each clause carries usable guidance. Slightly compressed, but nothing should be cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing returns and does so (category names and counts, optionGroups, selectedOptions), plus a recommended call sequence and pagination guidance. For a read-only listing tool whose safety profile is covered by annotations, this is complete enough to invoke 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 description coverage is only 40% (limit, offset, and restaurantId are undocumented in the schema), so the description must compensate. It explains the filtering role of category and query and says to paginate with limit and offset, but never states defaults (30/0), the 100-item cap, or what offset actually indexes into, leaving the numeric params partially opaque.

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 (List) and resource (a restaurant's menu items), which is unambiguous against siblings like list_room_types, list_events, or list_saved_locations. An agent can tell what this returns 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?

Gives an explicit two-step workflow: call with only restaurantId to see category names and counts, then narrow with category and/or query 'rather than reading the whole menu'. It also names the condition under which optionGroups/selectedOptions matter (items with choices) and the required=true constraint.

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, closed-world), and the description layers on real behavioral context: re-validation of prices and availability against the current menu, the non-obvious merging of kitchen and bar orders into one entry, delivery-only fields (address, fee, stage), and the strict personal-scope constraint. This is information an agent could not derive from the 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?

Front-loaded with the core purpose and scope, then progressively details return contents, repeat-ordering linkage, and filters. Dense but nearly every clause carries information; the return-shape enumeration is the longest stretch and could be trimmed slightly.

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 carries the full burden of describing the return shape, and it does so thoroughly (venue, code, status, total, type, timestamp, items with quantity/price/choices, delivery address/fee/stage). Combined with the pagination and scope notes, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 83%, documenting query, since, before, status and restaurantId, so the baseline is 3. The description restates the filter categories and maps 'text' to the query parameter, but adds little syntax or format detail the schema does not already carry.

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 ('List the connected person's own order history at WaitApp venues') plus ordering ('newest first') and a hard scope ('Only ever shows this person's own orders'). That scope immediately distinguishes it from sibling order tools like track_order and cancel_order.

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 filtering and pagination model ('Filter by venue, status, text ... or date, and page back with nextBefore') and connects the output to draft_delivery_order for repeat ordering, which is genuine routing guidance. It never states an explicit when-not or names an alternative to use instead, 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 declare readOnly, idempotent, non-destructive, and closed-world. The description adds the customer-visibility filter, which is useful extra context, but does not discuss pagination, ordering, or return shape.

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 dense sentences with zero filler; the visibility scope and the prerequisite both earn their place and are front-loaded.

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 single-param read-only list tool, the description covers purpose, scope, and prerequisite. Minor gaps in return-format expectations are acceptable given no output schema and safety already covered by annotations.

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% and the only param (restaurantId) is undocumented in the schema. The description partially compensates by telling the agent to obtain it via search_venues, but does not state format or constraints. Baseline 3 given one simple required param.

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 (List) and resource (bookable room/facility catalog), with a clear scope qualifier ('only entries visible to customers') that distinguishes it from availability-checking siblings like check_room_availability.

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?

Explicitly instructs to use search_venues first to obtain the restaurantId, providing a clear workflow precondition. It does not, however, name when-not-to-use or contrast with the book_* siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds meaningful non-annotation context: the privacy scoping ('Only ever shows this person's own') and the shape of the returned records, which matters because no output schema exists.

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 zero filler. The returned payload is front-loaded, the workflow hand-off follows, and the access-scope caveat closes it out.

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 parameters and no output schema, the description carries the return-value burden itself and does so by listing the fields. Access scope, purpose, and the downstream id hand-off are all present, leaving nothing an agent needs 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 there is nothing for the description to disambiguate; baseline is 4. The only identifier mentioned (savedLocationId) belongs to other tools, not this one's schema, so it does not add parameter meaning here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete resource (the connected person's saved delivery locations) and enumerates the returned fields (label, address, notes, default), so an agent knows exactly what comes back. It also names the downstream siblings (draft_delivery_order, place_delivery_order) that consume the ids, distinguishing this read tool from the save_location/delete_saved_location pair.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case: fetch an id here and pass it as savedLocationId to draft_delivery_order or place_delivery_order instead of typing an address. That is an explicit routing rule, though it never states when NOT to use this tool (e.g., free-text addresses are still valid).

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 it discloses the pricing/fee-quote sequence, the permission-dependent place-vs-draft behavior, spending limits, the required idempotencyKey retry protocol ('reuse the SAME value if you retry'), and the remaining venue-acceptance dependency. Notably it reconciles with idempotentHint=false by explaining that safety comes from the caller-supplied key, not from the tool itself.

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?

Dense and front-loaded: behavior first, then the draft path, then the idempotency rule, then tracking. It is longer than typical but nearly every clause carries operational weight; the 'Same rules and fields as draft_delivery_order' aside is the only mildly wasteful sentence, though it usefully avoids repetition.

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, yet the description names the key return values (draftId, orderCode) and the downstream calls that consume them, which is what an agent needs. Minor gaps remain around failure modes (payment decline, rejected venue) that would matter for a money-moving write.

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 schema coverage at only 44% across 9 params, the description compensates meaningfully: it explains the idempotencyKey contract, the allowed payment values, the selectedOptions shape for option groups, the connected-account requirement, and defers field details to draft_delivery_order. It does not, however, clarify the deliveryAddress vs savedLocationId tradeoff beyond what the schema already says.

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 first sentence states a specific verb and resource with scope: 'Orders food for delivery in one call.' It explicitly differentiates itself from draft_delivery_order ('same rules and fields') and confirm_delivery_order (which places the draft it returns), so an agent can route without opening sibling 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 explicit branching conditions: with full control it places immediately; if the person chose to confirm each decision it places nothing and returns a draft. It names the authoritative check (get_connection_permissions), the follow-up tool (confirm_delivery_order), and the tracking tool (check_booking_status).

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. Annotations declare a non-read-only, idempotent, non-destructive write; the description explains why it is idempotent (one rating per order, repeats return the existing one) and discloses the two-phase confirmation behavior where the first call returns scores but submits nothing. That is exactly the extra behavioral context a mutation tool needs.

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 its eligibility constraint, then the rating fields, then the idempotency and confirmation rules. 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 carries the return-behavior burden and does so for the confirmation case (first call returns the scores). For a 9-parameter mutation tool it is nearly complete, though the identifier parameters (orderId vs orderCode vs restaurantId) are left to the schema.

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 44%, and the description helpfully compensates for the undocumented fields: it defines food/deliverySpeed/packaging as 1-5 scores, comment as optional and short, riderRating as optional, and explains what confirmed: true does. It does not clarify the relationship between orderId, orderCode and restaurantId, which the schema partially handles.

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 (rate) and resource (an order), plus the qualifying constraints: it must be the connected person's own and must be DELIVERED. It also enumerates the rated dimensions, so an agent can distinguish this from sibling tools like track_order or confirm_delivery_order 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?

Gives clear operative context: one rating per order, a repeat returns the existing one, and the confirm-each-decision flow requires a follow-up call with confirmed: true. It does not name an alternative tool or an explicit when-not-to-use condition, but no sibling overlaps this action.

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 non-read-only, non-destructive, idempotent, and closed-world behavior, so the description needn't repeat safety. It adds valuable context beyond annotations: an upsert-by-label model, a cap of 10 locations, and notes for the rider. It omits what happens when the limit is reached and whether a new save can overwrite, which are minor but notable.

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 three sentences, front-loading the core action and then adding the update-by-label nuance, the 10-location limit, and the notes purpose. Each sentence adds information, though the order is slightly non-linear (limit after update). 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 four-parameter mutation with full schema coverage and annotations covering safety, the description covers upsert, quota, and notes meaning. It lacks explicit guidance on what happens at the 10-location cap and does not mention makeDefault, but overall it gives an agent enough to call 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 description coverage is 100%, so the schema already documents all four parameters. The description adds the meaning of notes and the label-as-identifier behavior, which complement the schema, but makeDefault is not mentioned in the description. Baseline 3 applies since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (saves) and resource (delivery location) and scopes it to the connected person's WaitApp account. The purpose is unmistakable and distinguishes the tool from siblings like delete_saved_location or place_delivery_order.

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 implies usage by saying saving a label updates an existing location and that later orders can use it, but it does not explicitly state when to use this tool versus alternatives or prerequisites such as an established connection. It offers no exclusions.

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 read-only/idempotent/closed-world, and the description adds substantial behavior beyond them: forgiving name matching (case, '&' vs 'and', typos) and a didYouMean fallback when nothing matches closely. It also discloses the payload contents (supported services, open-now status, weekly hours, city and countryCode).

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 sentences, front-loaded with the core action and filters, then matching behavior, then return contents. Slightly dense in the last two sentences but every sentence carries information an agent needs.

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, so the description carries the return-value burden and does so thoroughly (services, hours, open status, locality). Combined with zero required params and full annotation coverage, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75% and the description reinforces the fuzzy-match semantics of query and explains why countryCode matters (venue names repeat across countries). Only limit is left to the schema, so it adds real meaning above the field 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 a specific verb (Search) and resource (WaitApp venues: restaurants, hotels, lodges) with the filter axes (name, city, country). It also scopes the tool against siblings by noting it is the one that resolves venue identity before a venue id is used elsewhere.

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: empty query lists venues, and the tool is positioned as the identity-resolution step before other venue-id tools. It stops short of naming an alternative sibling to use when a venue id is already known.

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 idempotentHint=true and destructiveHint=true, and the description adds real context beyond them: the prompt goes to the guest's own phone, nothing is charged until the guest approves there, and repeated prompts are suppressed. It does not explain what makes the call destructive or what happens if the guest declines, so it adds value without fully illuminating the side-effect risk.

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 sentences, front-loaded with the action and its precondition, then the prompt destination and charge behavior, then the optional override. Every sentence carries distinct information, though the parenthetical about the order result is slightly wordy.

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-side burden and covers the key facts: the call triggers a prompt, not a charge, and it is not repeated. It omits failure modes (expired draftId, invalid number) that an agent would want before retrying, which keeps it below 5.

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 both parameters are already documented; the description only restates that mobileMoneyNumber overrides the number from the draft. It clarifies the override is exceptional ('Only to use a different...') but adds no format, normalization, or validation detail 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?

States a specific verb and resource ('sends the mobile money payment prompt for a delivery order') with the exact precondition that identifies the target state: order placed but unpaid, with payment required and a draftId from the order result. This cleanly separates it from siblings like place_delivery_order, confirm_delivery_order, and draft_delivery_order.

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 precise triggering condition ('order result says payment is required and gives its draftId') and a repeat-call rule ('a prompt already sent is not sent twice'). It does not explicitly name which sibling to use for the adjacent cases (e.g., confirming or canceling the order), so it falls just short of full when/when-not routing.

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

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

Annotations already declare this a read-only, idempotent, non-destructive call, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the privacy envelope (never rider phone or exact location), the reduced response for non-delivery orders, and the field set returned. It could say more about what happens when the order is unknown or cancelled, hence not 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 sentences, no filler: the return payload leads, then usage triggers, then the non-delivery carve-out and privacy limits. The only mild inefficiency is the colloquial opener 'How a delivery is going', which reads less like a tool contract than the rest.

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 it well by listing returned fields and the privacy boundary. Annotations cover the safety profile. The remaining gap is the required-input combination (orderId vs orderCode+restaurantId), which is soft in both the schema and the description.

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 each parameter (orderId, orderCode, restaurantId) is already documented, including when restaurantId is needed alongside orderCode. The description adds nothing about parameters, and notably does not clarify that despite zero required fields the caller must supply either orderId or the orderCode path. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete operation (retrieving live delivery progress for the connected person's own order) and enumerates exactly what comes back: stage, minutes remaining, rider distance in km, and rider first name. It also carves out the non-delivery case (status only), which sharpens the scope. It does not, however, explicitly distinguish itself from siblings like list_my_orders or check_booking_status, so an agent must infer 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?

It gives explicit trigger phrases ('where is my food', 'how far is it') and states the fallback behavior for non-delivery orders, which is actionable context. What is missing is any named alternative or exclusion — e.g. that the order must already exist and that list_my_orders is the way to obtain the identifier — so the when-not guidance is only implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it returns up to 3 images resized small, or a note that none exist, which sets expectations for the response. Not a full 5 since load/format behavior is only sketched, but it clearly earns credit over the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the OPTIONAL marker and the core action, then layers usage, alternatives, and return behavior in a compact block. 'so you can look at them and describe them to the guest' is slightly redundant with the preceding clause, but overall most sentences 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?

For a 3-param read-only tool with no output schema, the description covers purpose, when/when-not, the id source, and return shape (up to 3 small images or a none-note). The only real gap is maxPhotos semantics, which leaves the agent guessing whether to set it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. It does explain where the id comes from (the four list/search tools) and indirectly communicates the kind domain via 'menu item, room/facility type, event or venue,' but maxPhotos is never mentioned despite its 1-3 range and default of 2; 'up to 3 images' hints at the cap without tying it to the 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 (fetch) and resource (small version of the actual photo) and enumerates the four entity kinds it applies to. It also distinguishes itself from the passive imageUrl/photos/coverImageUrl links exposed by other tools, so an agent can tell why this tool exists separately from list_menu_items or search_venues.

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?

Explicitly states when to use it ('when the guest asks what something looks like') and when not to ('To just show a picture, the imageUrl / photos / coverImageUrl links in the other tools are enough'). It even marks itself OPTIONAL, and names the sibling tools (list_menu_items, list_room_types, list_events, search_venues) that supply the required id.

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