SzuruSzuru – rezerwacja czyszczenia tapicerki

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable non-obvious behavior: the quote is binding, valid for ~30 minutes, and quote_id is required downstream. It also tells the agent not to estimate or adjust prices and to ask the customer to add a service if below minimum order.

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 with no fluff. The main purpose is front-loaded, then the return value and validity are stated, and finally an important constraint on agent behavior. 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?

Given there is no output schema, the description covers the key return value (quote_id) and its validity period. It also includes the minimum-order handling rule, which is operationally important. It lacks explicit sibling routing, but for a quote-calculation tool with read-only annotations, the essential context is present.

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 33%, so the description needs to compensate. It explains the conceptual role of postal_code and items by mentioning travel fee, quantity discounts, unit prices, add-ons, and minimum order. It does not cover session_id or per-parameter syntax, but the schema already documents those adequately.

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: 'Calculates a binding quote for one or more services at a postal code'. Lists exactly what is computed (unit prices, quantity discounts, add-ons, travel fee, minimum order) and names a downstream consumer (check_availability), which distinguishes it from sibling tools.

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 provides clear workflow context: calculate_quote produces a quote_id required by check_availability, so the intended position in the booking flow is evident. It also gives an actionable instruction about minimum orders. However, it does not explicitly state when to prefer this tool over prepare_booking or other siblings, nor list 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 destructiveHint=true and idempotentHint=true, and the description adds critical context: the operation is irreversible and requires explicit customer confirmation before calling. It also discloses the auth requirement (customer_grant or signed-in customer). This goes 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?

Two sentences, front-loaded with the core action and irreversibility warning. Every sentence earns its place; 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, irreversible mutation with no output schema, the description covers the critical behavioral context (irreversibility, confirmation requirement, auth prerequisites). It doesn't describe the return value, but the absence of an output schema lowers the bar. Minor gap: no mention of what happens to related resources (e.g., payments), but the core is covered.

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 20%, so the description must compensate. It mentions idempotency_key and customer_grant in the context of requirements, but doesn't explain booking_reference, reason, or session_id beyond their schema names. The description adds some meaning but leaves most parameters to be inferred from names.

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 ('Cancels') and resource ('the verified customer's booking'), and the title 'Anuluj rezerwację' (Polish for 'Cancel booking') reinforces it. It clearly distinguishes from siblings like reschedule_booking and create_booking.

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: cancels the verified customer's booking. It also gives clear prerequisites: requires customer_grant or a signed-in customer and an idempotency_key. It doesn't name alternatives, but the context is clear enough for an agent to know when to invoke it.

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, so the read-only nature is covered. The description adds valuable behavioral context: slots expire after ~15 minutes and are the only valid source of slot_id, which is critical for correct usage. It also warns against assuming availability, which is a caution 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?

Two sentences with no wasted words. The first sentence front-loads the core purpose and conditions, and the second provides filter options and a critical expiration warning. It is concise and immediately scannable.

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?

While the description gives a good overview, it leaves gaps: it doesn't explicitly state that either quote_id or booking_reference is required, and session_id is completely unexplained. With no output schema, it also doesn't describe the return structure beyond mentioning slot_id and expiration. These are important for an agent 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 only 20% (only customer_grant has a description), so the description must compensate. It explains quote_id and booking_reference usage, and the 'wanted' filter types (asap, date, range, preferred) with optional part_of_day. However, it omits session_id and the date/time fields (from, to, preferred_time), relying on schema patterns 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?

Description clearly states the tool returns 'real, currently bookable appointment slots' and differentiates between new bookings (quote_id) and rescheduling (booking_reference). It also emphasizes it's the 'only valid source of slot_id', making its role unmistakable among siblings like create_booking and reschedule_booking.

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?

Specifies when to use it: for a new booking with a quote_id, or for rescheduling with a booking_reference and customer_grant. It also strongly advises 'Never assume availability without calling this tool', which implies it should be called before any booking action. However, it doesn't explicitly name alternative tools or state when not to use it.

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. The description adds value beyond these by clarifying that the tool returns only availability and town name, and by reinforcing that it is non-mutating and privacy-limited. No contradictions with annotations.

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

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

The description is three tightly scoped sentences with no redundant phrasing. The main purpose is front-loaded, followed by output scope and then explicit non-behaviors, making it easy for an agent to parse quickly.

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

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

For a simple one-parameter, read-only lookup with no output schema, the description is complete: it explains the input format, what the response will contain (availability and town name), and what it will not do. Combined with the annotations, an agent has everything needed 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?

With 0% schema description coverage, the description carries the burden for explaining the postal_code parameter. It specifies the format (NN-NNN, e.g. 83-300), which is essential, though it doesn't mention that the hyphen is optional as the schema allows. This is a minor gap but still provides meaningful guidance beyond the raw pattern.

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 starts with a specific verb ('Checks whether SzuruSzuru serves a Polish postal code') and a precise resource (postal code), and distinguishes itself from booking/scheduling siblings by explicitly stating it does not reserve anything and does not reveal staff or schedules. This makes the tool's unique role immediately 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 description clearly implies when to use the tool: to verify service coverage for a postal code before booking. It provides exclusions ('Does not reserve anything and does not reveal staff or schedules') that prevent misuse, though it does not explicitly name an alternative sibling such as check_availability.

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 include idempotentHint=truecher, and the description elaborates meaningfully: retries with the same key will never create a second booking, and the backend re-validates price, slot, schedule, and identity before confirming. This adds context beyond the structured hints.

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 four tight sentences with no filler. It front-loads the main purpose, then delivers retry semantics, backend validation, and return values, with each sentence earning 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?

The description covers workflow timing, retry behavior, validation, and returns booking_reference, time, and total, which is important since there is no output schema. The omission of session_id and lack of explicit alternative tool comparisons are the main gaps in an otherwise complete 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 0%, so the description must carry parameter meaning. It effectively explains confirmation_id, sms_code, and idempotency_key, but it never mentions session_id, an optional parameter that remains ambiguous despite its regex pattern. This is a clear gap but not a complete failure.

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 starts with a strong verb ('Creates') and a precise resource ('confirmed SzuruSzuru booking'), conditioned on a prepared confirmation_id and an SMS code. This clearly distinguishes the tool from siblings like prepare_booking and verify_phone_code, so an agent can tell them apart.

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 sets a clear usage context: call after the customer provides the 6-digit SMS codeaging, and for a previously prepared confirmation_id. It also gives explicit retry guidance with idempotency_key, though it does not explicitly name when not to use this tool or which sibling to fall back to.

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 the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: the 90-day time window, the authentication prerequisites, the privacy guarantee ('Never shows other customers' data'), and the specific fields returned. These details go beyond what the annotations convey and provide a richer picture of the tool's behavior without any contradiction.

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 two sentences, front-loaded with the core purpose and scope. It includes essential details (time window, fields, authentication, privacy) without any extraneous content. Every sentence earns its place, and the structure is clean and efficient.

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

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

Given there is no output schema, the description appropriately lists the returned fields and the time window. It also covers authentication and privacy. It omits mentioning that booking_reference can retrieve a single booking, but that is covered in the schema, so the agent can discover it. Overall, it provides sufficient context for an agent to call the tool correctly, though it could mention pagination or ordering, which are not critical for a simple listing.

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 33% (only booking_reference has a schema description). The tool description clarifies the auth parameters by stating 'Requires customer_grant or a signed-in customer,' which implies session_id is for signed-in customers and customer_grant is for granted access. However, it does not mention the optional booking_reference parameter at all, though the schema does provide its purpose. The description adds some semantic value for the auth parameters but does not fully compensate for the low schema coverage.

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 ('Lists'), a clear resource ('the verified customer's bookings'), a scope ('from the last 90 days'), and enumerates the returned fields (reference, services, time, price, status, reschedule/cancel availability). It also distinguishes itself from siblings by emphasizing that it never shows other customers' data, which sets it apart from any general listing or mutation tools like cancel_booking or reschedule_booking.

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 for retrieving the current customer's bookings and notes the authentication requirement (customer_grant or signed-in customer), but it does not explicitly contrast with alternatives such as cancel_booking or reschedule_booking, nor does it state when not to use this tool. The context is clear but the guidance is implied rather than 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description reinforces this by adding 'Read-only' and elaborates on the returned content, which is useful context. However, it does not describe any behavioral nuances like error handling, rate limits, or the exact structure of the response. Given that annotations cover the core safety aspects, the description adds some value but not rich behavioral detail.

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 exceptionally concise: two sentences that front-load the core purpose and then add the usage context. There is zero redundancy or fluff. Every word 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?

Given the tool's simplicity (one parameter, read-only, no output schema), the description covers the essential aspects: what it returns (list of quoting details), when to use it (ambiguous requests), and its read-only nature. It does not mention potential error conditions (e.g., invalid service id) or response format details, but for an informational tool this is acceptable. The absence of an output schema makes the description's enumeration of return items important, and it fulfills that need.

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 schema already provides 100% coverage for the single parameter, including a description ('Service id from list_upholstery_services'). The tool description does not add any additional semantics about the parameter beyond implying it identifies a service. Since schema coverage is complete, the baseline is 3, and the description does not elevate it further.

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

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

The description clearly states the tool's function: 'Returns everything needed to quote one service' and enumerates the specific data types (unit, quantity limits, variants, optional add-ons, factual description). It also differentiates itself from siblings by focusing on quoting prerequisites rather than actual calculation (compare calculate_quote) or listing services (list_upholstery_services). This is a specific verb+resource with clear scope.

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 provides explicit usage context: 'Use it when the customer's request is ambiguous' with concrete examples (corner sofa size, carpet area). It does not explicitly name alternative tools or state when not to use it, but the context implies that for other cases (e.g., calculating a final price) a different tool would be appropriate. This is clear enough but lacks explicit 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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: it retrieves live catalog data, includes no coverage/availability checking, and warns against price estimation. No contradiction with annotations.

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

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

The description is front-loaded with the primary action and scope, followed by exclusions and a pricing rule. Each sentence contributes, though 'Read-only.' is redundant with the annotations.

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 list tool with one optional parameter and rich annotations, the description conveys what the response contains (prices, units, add-ons, required parameters), scope, and the source of truth. No need to document return structure beyond this.

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 only parameter (category) has full schema documentation with an enum and a clarifying description, so the schema already carries the semantic burden. The description does not need to add parameter syntax or format details.

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

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

The description uses a specific verb ('Lists') with a clear resource ('SzuruSzuru's upholstery, carpet, rug and mattress cleaning services') and geographic scope, making the tool's purpose unambiguous. It also explicitly states what it does not do, which helps distinguish it from siblings like check_service_area and check_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?

The description gives explicit when-not-to-use guidance: it does not check coverage or availability, and directs the agent to check_service_area and check_availability for that. It also instructs the agent never to estimate prices, instructing reliance on the live catalog.

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 provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but no further detail. The description adds valuable behavioral context: it holds the slot for 10 minutes, sends an SMS confirmation, and returns a summary that must be shown verbatim. It also clarifies the terms_accepted requirement. No contradiction with annotations. It stops short of describing what happens if the slot expires, but overall it transparently discloses the core side effects.

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

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

The description is a single well-structured paragraph that front-loads the core action and immediately clarifies the critical distinction (does not create the booking). It packs in the 10-minute hold, SMS, summary requirement, and terms acceptance without rambling. Slightly longer than necessary but 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 complex tool with 7 parameters and nested objects, and no output schema, the description provides the essential return values (confirmation_id and summary) and clarifies the follow-up create_booking call. It explains the main behavioral flow and constraints. However, it omits any guidance on session_id and invoice_data, which are not self-explanatory from the schema alone. Still, an agent can likely proceed correctly for the common case.

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%, so the description must compensate for under-documented parameters. It mentions quote and slot (implying quote_id and slot_id), customer details (customer object), and terms_accepted, but it does not explain session_id or invoice_data at all. The description adds context beyond the sparse schema but does not fully compensate for the low coverage, especially for optional parameters that could affect the call.

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 (Prepares) and resource (a booking for a chosen slot) and enumerates concrete actions: validates quote and slot, holds the slot for 10 minutes, records customer details and terms acceptance, sends SMS. It also explicitly distinguishes itself from create_booking by stating 'Does NOT create the booking', so an agent can tell them apart without inspecting 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?

The description gives explicit when-to-use and when-not-to-use guidance: it states that after this call, the customer must read the SMS code and the agent must call create_booking. It also requires explicit customer agreement and terms_accepted=true, leaving no ambiguity about the follow-up flow. This is more than enough to route the agent correctly.

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 non-read-only, destructive, and idempotent; the description adds that it does not alter price or services, requires explicit customer confirmation, and needs auth via customer_grant or a signed-in customer. It could say more about what happens to the original slot, but it substantially supplements the annotation 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?

Three short sentences with no filler; the purpose, constraints, confirmation step, and auth requirement are packed in without repetition. The most important operation is 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?

The essentials for a safe call are present: prerequisites, auth requirements, idempotency, and a confirmation gate before mutation. With no output schema, a sentence about the response or returned booking would round it out, but this is not critical for selection and invocation.

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 0% schema description coverage, the description carries the burden: it explains where slot_id comes from, that booking_reference drives the availability query, why idempotency_key is needed, and the customer_grant/session auth alternative. It does not explicitly name session_id or describe grant format, but the core semantics are present.

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?

Description names a specific operation: moving a verified customer's booking to a new slot_id, and it anchors slot_id to check_availability(booking_reference). It also draws a boundary against price/service changes, making the scope distinguishable from create_booking and cancel_booking.

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 concrete precondition: obtain slot_id from check_availability before calling, and an interaction rule: confirm the new time with the customer first. It also excludes price/service changes, so an agent knows this tool is not for those requests.

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

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

The annotations only set readOnlyHint, idempotentHint, and destructiveHint to false; the description adds meaningful behavior: rate limits (one per minute, three per 30 minutes per phone) and the requirement that the booking be 'prepared'. This is exactly the kind of context annotations don't convey.

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

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

Two sentences, zero filler; the action is first, followed by the rate limit and the usage condition. Every sentence carries necessary 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 tool with no output schema, the description covers purpose, prerequisites ('prepared booking'), and critical rate-limit constraints. It does not describe the success/error response or provide fallback behavior on rate-limit hit, but that is a minor gap given the schema and 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 description coverage is 0% and the description never mentions confirmation_id or session_id, so it adds no meaning beyond the raw schema. While the parameter names are fairly self-explanatory, the description doesn't clarify which ID comes from prepare_booking or how the optional session_id should be used.

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

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

The description uses a specific verb ('Re-sends') and resource ('SMS confirmation code for a prepared booking'), clearly distinguishing it from sibling verification and booking tools. The phrase 'for a prepared booking' ties it to prepare_booking without needing to inspect 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?

The instruction 'Use only when the customer says the SMS did not arrive' is an explicit trigger condition for calling this tool. It gives clear context but does not name alternatives like start_phone_verification or specify when to choose them, so it falls 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?

Beyond the annotations, the description reveals an important behavioral trait: the response is identical whether or not the number is known, preventing user enumeration. It also makes the SMS side effect explicit. It could add more about response shape or session handling, but it provides meaningful behavioral context beyond 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?

Three efficient sentences with no filler. The main action is front-loaded, the anti-enumeration behavior is stated compactly, and the exception for prepare_booking is included without 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?

There is no output schema, so the description should explain what the caller receives; it only says the response is the same but not what it contains. It also does not cover session_id or the obvious follow-up step verify_phone_code. The description is adequate for high-level selection but not complete for invocation.

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 0% schema description coverage, the description needed to explain both parameters. It adds some context for phone ('Polish mobile number') but entirely omits session_id, its role, or whether it is needed to link the verification to a booking. This leaves a required-by-workflow parameter 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?

The description states a specific verb and resource: it 'sends an SMS code to a Polish mobile number' to prove customer control. It also clearly distinguishes itself from prepare_booking and implicitly from verify_phone_code by describing the start-of-verification responsibility.

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 clearly frames when to use the tool: for accessing, rescheduling, or cancelling existing bookings, and explicitly says it is not needed for new bookings because prepare_booking sends its own code. It does not explicitly route the agent to verify_phone_code as the follow-up, which would have made the guidance complete.

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 are all false, so the description carries the burden. It discloses that the grant is short-lived (60 minutes) and scoped to the customer's own bookings, which are important behavioral traits. It does not mention code consumption, rate limits, or error conditions, but the given details are substantive. This is a solid disclosure, earning a 4.

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 with no fluff. The first sentence states the core exchange and the grant's properties; the second gives actionable follow-up steps. Every word earns its place, and the key information is 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 tool with no output schema, the description tells the agent what the tool returns (a customer_grant) and how to use it. However, it omits the session_id parameter and provides no error or edge-case guidance. Given the moderate complexity, it is adequate but has clear gaps, warranting a 3.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It implicitly covers 'code' (the SMS code) and 'verification_id' (the ID from start_phone_verification), but it never mentions 'session_id' at all. With three parameters and two required, omitting one is a significant gap. The description adds meaning for the main flow but does not fully compensate for the schema's lack of documentation.

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

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

The description clearly states the verb 'Exchanges' with a specific resource (SMS code) and the outcome (customer_grant). It distinguishes itself from start_phone_verification by describing the follow-up step, and it scopes the grant to the customer's own bookings, making the tool's purpose 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?

It explicitly states that the tool exchanges the code from start_phone_verification and directs the agent to pass the resulting customer_grant to four sibling tools. This gives clear when-to-use context. However, it does not explicitly state when not to use it or mention any alternative flows, so it stops short of a perfect 5.

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