BEEP.rent — car rental in Poland

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

Beyond annotations (destructiveHint=true, idempotentHint=true, openWorldHint=true), the description discloses the crucial preview behavior: the first call cancels nothing, returns the refund and a confirmation_token, and cancellation is irreversible. This is exactly the kind of operational safety context an agent needs before invoking a destructive tool.

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

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

The description is front-loaded with the usage condition and workflow, then adds irreversibility and an example. Every sentence contributes operational value, and there is no redundant restatement of the tool name or 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?

Given a destructive, multi-step tool with five parameters and an output schema, the description covers the prerequisite chain, preview semantics, confirmation requirements, irreversibility, and input source for the non-obvious parameters. An agent has enough information to call it safely without needing to infer destructive behavior.

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

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

Schema description coverage is 60%, and the description adds meaningful semantics for the key parameters: confirm controls preview vs execution, management_id comes from verify_reservation_management, confirmation_token comes from the preview, and reservation_number is conditional on account connectivity. It does not explain the market parameter, which is the main gap.

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

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

The description states a specific verb and resource ('cancel' a reservation) and immediately distinguishes the supported invocation paths (management_id vs reservation_number) from sibling tools like verify_reservation_management. An agent can tell exactly what this tool does without opening the schema.

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

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

It gives explicit when-to-use conditions, prerequisites (verify_reservation_management or a connected BEEP.rent account), and a step-by-step flow: call without confirm, show the refund, obtain explicit yes, then call with confirm=true and the token. The alternative input paths are also clearly delineated.

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

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

Annotations already declare non-read-only, open-world, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely new context beyond the annotations: confirming does not finalize the booking because "the rental company may still have to accept it" — a behavioral nuance an agent would otherwise not know.

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 trigger, then the anti-hallucination rule, then the outcome caveat and a concrete example — each sentence carries a distinct payload. The JSON example is useful but borderline redundant with the schema's 25% coverage.

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 three required parameters, an opaque token, and an output schema that covers return values, the description is adequate on the outcome side. It is not adequate on the input side: the agent is never told that status_token is a prerequisite obtained from create_reservation or get_reservation_status, which is the main failure mode for this 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 25% — only `code` is documented — and the embedded example at least shows the shape of reservation_number and status_token. However, the description never explains what status_token is, where it comes from, or that market is optional, so the opaque 16-512 char token remains a 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 action (confirm a reservation) bound to a specific input (the 6-digit code the user received), which separates it from the sibling request_confirmation_code. It describes the trigger more than the effect, but an agent can identify the tool correctly from one read.

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

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

"Use when the user gives you the 6-digit code they received for a new reservation" gives an explicit trigger, and "Never guess or invent a code" adds a clear guardrail. It stops short of naming the upstream/downstream siblings (request_confirmation_code, get_reservation_status), so the agent must infer the surrounding flow.

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-readonly, idempotent and non-destructive, and the description stays consistent while adding genuinely new behavioral facts: what gets frozen, that nothing is booked, that checkout_id and a beep.rent link are returned, and the replay rule for options. That is context beyond the annotation set rather than a restatement of it.

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

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

Front-loaded with the trigger condition, then effects, then the caveat and the pre-call obligation, then a compact example. Content is dense but every sentence carries a distinct rule; the opening sentence is long and could be split for readability.

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

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

An output schema exists, so return values need not be detailed, and the description still names checkout_id and continue_url usefully. For a checkout-freezing tool the notable remaining gap is how long the frozen price/checkout_id stays valid and whether it must be re-created if it expires.

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% for a large nested options object, but the description compensates with the single most important rule: 'Resend every option you applied in get_offer.' The inline example also conveys parameter provenance (search_id from search, offer_ref from offer). The market parameter and the checkout's price-lock lifetime remain unexplained, so not a 5.

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 plus its exact semantic effect: it freezes price, deposit, options and policies and returns checkout_id and a continue_url. Crucially it distinguishes itself from the reservation-writing siblings by saying 'Does not book anything', so an agent can tell it apart from create_reservation or confirm_reservation_code.

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

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

Gives a clear triggering condition ('Use after get_offer when the user chose an offer') and a prerequisite ('Show the user the price, the deposit and the cancellation policy before calling'), plus the important exclusion that it does not book. It stops short of naming the follow-up sibling (create_reservation) explicitly, which keeps it from 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 establish the safety profile (not read-only, destructive, idempotent, open-world), and the description adds substantial context beyond that: the booking stays unconfirmed until code entry or payment, repeated calls with the same checkout return the same reservation, and consent questions must be asked individually. That directly supplements the idempotentHint and destructiveHint rather than repeating them.

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 content is dense but each sentence carries operational value: consent conditions, confirmation flow, idempotency, disclosure requirements and an example. The main drawback is front-loading: it opens with a long prepositional 'Use only after...' clause, so the actual purpose appears mid-sentence rather than first.

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, nested objects and an output schema, the description covers the critical preconditions, confirmation mechanics, idempotency and a worked example. The remaining gap is guidance on the optional invoice, market, comment and accept_changes parameters, which is only partially covered by the output 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?

With only 14% top-level schema description coverage, the description partially compensates by showing an example payload that maps the customer and consents fields. However, it says nothing about the optional parameters market, comment, invoice or accept_changes, so an agent must still infer their purpose from the schema alone.

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: 'creates the reservation from checkout_id with the driver's details.' It also distinguishes the tool from confirm_reservation_code by noting the booking is not confirmed until that step or payment, so an agent can place it in the flow 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 explicit when-to-use conditions: only after the user explicitly asked to book and, in a separate question, accepted terms/privacy and answered about marketing, with the precise clarification that a yes to booking is not a yes to terms. It also names the sibling alternative for confirmation (confirm_reservation_code) and requires showing price, deposit and cancellation policy beforehand.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower. The description still adds real value with "Reads the shared public snapshot" (hinting the data source may be a cached/shared dataset) and the warning that a pickup point is not a car-availability guarantee — a domain caveat not present in any annotation.

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 plus two compact JSON examples, with the primary purpose front-loaded and the caution placed before the examples. Nothing is redundant with the title or schema.

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

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

The output schema means returns need no explanation, and the shared-snapshot note covers provenance. But with 5 optional parameters, 40% schema coverage, and zero documentation anywhere for market, limit and radius_m semantics, an agent is left guessing on real knobs that affect results.

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 40%, and the description only implicitly covers city, near, limit and radius_m through two examples, which show format but not meaning (e.g. what radius_m measures from, what limit bounds). The market parameter is never mentioned in the description and has no schema description 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?

Opens with a specific verb+resource: "find physical pickup desks near a city or location," which is unambiguous about what the tool returns. It never names a sibling, but the other tools are clearly reservation/offer-oriented, so confusion is unlikely.

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

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

"Use to find..." gives the triggering condition and the examples show two valid call shapes (city vs. near), but there is no explicit "when not to use" or pointer to an alternative tool for cases like getting a full offer with a pickup point attached. The caveat about availability is interpretive guidance, not routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely new behavioral context: results are cached, dated snapshots rather than live availability, and must not be treated as a binding quote. It stops short of stating cache freshness or how stale the dates can be, which would have earned 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?

Four short sentences, front-loaded with the primary use case, then the critical caveat, then concrete examples. No filler or 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?

With an output schema present, return shapes need not be described, and the safety profile is covered by annotations. The one remaining gap is cache staleness/freshness guidance, which matters for a tool whose whole selling point is 'dated examples'.

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

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

Schema description coverage is 0%, so the description must compensate. The examples do add real signal: city appears to accept both a display form ('Kraków') and a slug form ('wroclaw-krzyki') that pairs with a market value. However, the meaning of 'market', its default behavior, and the relationship between the two fields are never explained.

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

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

The description opens with a specific verb-and-resource framing ('cached price examples') and immediately scopes it to the pre-booking phase. It is not a literal 'returns prices for a city' statement, but the resource and scope are unmistakable, and the 'not live availability' line separates it from get_offer/quote tooling.

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?

Explicit when-to-use ('before travel dates are chosen'), explicit when-not-to-use ('Do not use for a binding quote'), plus two worked call examples. An agent knows exactly which condition selects this tool over the quote/offer 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 readOnly/idempotent/no-destructive, and the description adds genuinely non-obvious behavior: supplied options layer on top of search selections, omitted options inherit search values, and prior-call options are NOT remembered so every changed option must be resent. It also explains that 'detail' modes shape response size ('full' adds every photo, 'policies' keeps policies concise). This is exactly the statefulness/overwrite context annotations cannot 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?

Front-loaded with the primary purpose, then usage constraints, then behavioral caveats, ending with a concrete example — a sensible ordering with little waste. The prose is dense and a couple of clauses (e.g. the photo/policies detail note) could be tightened, but every sentence carries information.

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

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

An output schema exists, so return values need not be described, and the description covers the statelessness caveat, detail-level tradeoffs, and the book-vs-read boundary that matter for correct invocation. Gaps remain around 'market' and 'response_format', which an agent must infer from the enum/default alone.

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

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

Schema description coverage is 0%, so the description must carry the load, and it partially does: it explains the options merge/inheritance rule and the semantics of the 'detail' enum values, which are the most error-prone inputs. However, 'market', 'response_format', and the identity params 'search_id'/'offer_ref' get no explanation beyond a bare example, and the ~18 nested option fields are undocumented in 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 and resource ('read current pricing, deposit, extras and rental policies') and anchors it to the sibling it follows ('after search_offers'). An agent can distinguish this from search_offers and the reservation 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?

Explicit precondition ('Use after search_offers') plus an explicit exclusion ('Do not use to book or confirm a reservation'), with booking siblings clearly the alternative for that intent. Nothing is left to inference about when to select this tool.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds important domain behavior by enumerating status outcomes and explicitly warning not to say a reservation is confirmed unless the returned status is confirmed.

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 core use case and every sentence contributes useful invocation or safety information. It is dense and somewhat run-on, but the examples and confirmation warning earn their space.

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

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

An output schema exists, so return structure need not be described, and annotations already cover the safety profile. The description is complete enough for correct invocation, with the main minor gap being the unexplained market parameter.

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 low at 20%, so the description carries meaningful burden. It explains status_token, email, management_id, and reservation_number usage, with examples combining them; however, it does not explain the market parameter and does not explicitly clarify that reservation_number remains required in all examples.

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: checking a reservation's status, including the concrete states it distinguishes (confirmed, awaiting code/payment, awaiting rental company). This clearly separates it from siblings like cancel_reservation, confirm_reservation_code, and list_my_reservations.

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

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

It gives clear usage context and explains multiple valid identification paths: status_token, booking e-mail, management_id, or reservation number alone when the account is connected. It lacks an explicit statement of when not to use this tool versus adjacent siblings, which keeps it below a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds genuine context: sort order (next pickup first, or newest first with include_past), the 365-day lookback, and the returned fields. Pagination behavior and the 20-item cap are not disclosed.

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?

Opens with the trigger condition, then the identity source, then ordering, then returned fields, then an example — strictly front-loaded with no filler sentences. Each sentence carries distinct information.

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

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

With an output schema present, return values needn't be restated, yet the description still summarizes them helpfully; identity, ordering, and past-window semantics are all covered. The one gap is pagination/offset behavior for a tool whose limit can be lower than the result set is not addressed.

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?

Goes beyond the 75% coverage schema by explaining the semantics of include_past (last 365 days, reversed ordering) and where management_id comes from, plus a concrete call example. However, offset is never explained and the description credits start_reservation_management for the id while the schema says verify_reservation_management, a small source ambiguity.

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 (lists) and resource (reservations) scoped precisely to the user's own BEEP.rent bookings, which distinguishes it from siblings like search_offers or get_reservation_status. The added detail about whose bookings (verified e-mail vs connected account) removes ambiguity about 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?

"Use when the user asks about their own BEEP.rent bookings" gives a clear triggering condition and the prerequisite identity flow (verify via start_reservation_management). It does not name alternatives such as get_reservation_status for a single booking or cancel_reservation, so routing against siblings is left partly to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false; the description reinforces this with "Changes nothing" and adds a business precondition (rental must be in progress) that annotations cannot express. It does not explain openWorldHint behavior, failure modes, or what happens with a stale management_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?

Everything present is useful, but the core purpose ("prices the extra days") is buried mid-way through a long run-on sentence whose conditional clauses are hard to parse. The example earns its place; the structure could be front-loaded with the verb first.

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

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

An output schema exists, so return values need no explanation. Combined with the sequencing rule, the in-progress precondition, identifier-selection guidance, and a concrete call example, an agent has what it needs to invoke this correctly; the only omission is the optional market parameter.

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

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

With only 50% schema description coverage, the description compensates well: it explains where management_id comes from and the conditional rules for choosing management_id plus reservation_number versus reservation_number alone. It demonstrates the ISO-8601 offset format for new_return_at via the example, but never mentions the market parameter, leaving one of four params undocumented in both places.

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

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

The description states a specific action ("prices the extra days") and resource (a rental extension), and "Changes nothing" signals it is a read-only quote rather than the actual mutation. It stops short of explicitly contrasting with the sibling request_extension, which is the tool an agent could most easily confuse it with.

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 an explicit trigger ("user wants to return the car later"), a sequencing prerequisite ("after verify_reservation_management"), and conditional routing for the two identifier paths depending on whether the code went to the user's e-mail or the account is connected. The precondition "Only a rental in progress can be extended" tells the agent when not to call 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 mutation (readOnlyHint=false), non-idempotence (idempotentHint=false), open-world behavior, and non-destructiveness. The description adds that a new code is sent to the contact given at booking, which is useful side-effect context, but it does not explain whether previous codes are invalidated, rate limits, or delivery channel details beyond annotations. With annotations covering the safety profile, this is adequate but not rich.

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 plus a compact example, front-loaded with the usage condition and caution. Every element serves a purpose with no wasted wording.

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 that an output schema exists and annotations cover the safety profile, the description is mostly complete for invocation. However, with 0% schema parameter coverage, the missing definitions for status_token and market leave a meaningful gap for an agent that must supply those values 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 0%, so the description must compensate for undocumented parameters. It provides only a bare example with reservation_number and status_token, but does not define what status_token is, how it is obtained, or what the optional market parameter does. The example gives minimal orientation but falls well short of explaining the three parameters.

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 ('Sends a new code') and resource ('confirmation code'), and scopes it to the case where the user did not receive the code or it expired. It does not explicitly name a sibling tool (e.g., confirm_reservation_code) for contrast, so it stops short of full sibling differentiation.

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 clear when-to-use ('user did not receive the 6-digit code... or it expired') and when-not-to-use ('do not call it unprompted'). It does not name alternative tools or explain what to do instead if the code is already valid, so alternatives are 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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the bar is lower, but the description adds the crucial preview/confirm gate and the fact that a confirmation_token is returned and must be echoed back with unchanged parameters. It does not explain what happens to the underlying reservation if the company declines or what a failed confirmation costs the user, leaving the destructive profile partly unqualified.

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 prerequisite and two-phase contract are front-loaded in the first two sentences, with the example placed last where it belongs. The inline JSON example is slightly dense but earns its space by showing which fields travel together on the confirm call.

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

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

With an output schema present, the description need not explain return values, yet it still flags confirmation_token and the 'decision' field. For a destructive, open-world mutation with 6 params, the main remaining gap is the absence of any statement about denial handling or what market/reservation_number are for.

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

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

At 50% schema coverage the description must compensate, and it does for the highest-risk fields: confirm is framed as preview-vs-execute, confirmation_token is tied to the preview step, and new_return_at must be identical between calls. market and reservation_number are never mentioned, and management_id is only covered indirectly ('from_verify' in the example vs. the schema's verify_reservation_management), so the coverage is good but 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 positions the tool relative to quote_extension ('Use after quote_extension when the user asked to extend') and makes clear it submits an extension request that 'the rental company decides', which cleanly separates it from the quoting sibling. The specific action verb is implied by the sequencing rather than stated outright, keeping it just short of a 5.

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

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

It names the prerequisite sibling (quote_extension) and the triggering condition ('when the user asked to extend'), then prescribes an explicit two-step protocol: preview first without confirm, then re-call with confirm=true plus token and identical new_return_at after 'the user's explicit yes'. This is exactly the when/when-not guidance 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?

Beyond the annotations, it discloses the default return shape (use_web_form and continue_url) and the privacy constraint of not collecting contact details by default, then describes the conditional branch that requires privacy-policy and marketing consent before submitting. It also states the downstream effect ('the office then contacts the person') so the agent understands this is an inquiry, not a confirmed reservation.

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

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

Front-loaded with the trigger, then the default path, then the conditional path, then the clarifying caveat. The trailing example is long but earns its place by demonstrating the nested customer and consents payload that the prose only describes abstractly.

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 annotations covering the safety profile and an output schema present, the description need only explain behavior and branch conditions, which it does thoroughly. The unexplained market parameter and the lack of any note on idempotency behavior (despite idempotentHint=true) are the only minor omissions.

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

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

Schema coverage is 57%, so the description has to carry weight, and it does: it explains exactly when customer and consents are required (direct submission only, never for a web handoff) and the worked example pins down rent_length, mileage_limit and customer_type usage. The market parameter is never mentioned in either the description or the schema, which is the one remaining gap.

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

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

The description states the trigger precisely ('use when the person wants one long-term package') and frames the action as submitting an inquiry that the office follows up on, plus explicitly rules out a booking, which separates it from create_reservation. It never names the action verb outright (submit an inquiry) and only references search_long_term_offers indirectly via the schema, so it stops just short of a 5.

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

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

It gives a clear when-to-use trigger and a when-not ('this is not a booking'), and it spells out the two operating modes: default web-form handoff versus direct submission when direct inquiries are enabled. It does not name sibling tools as alternatives, leaving the agent to infer that search_long_term_offers must run first from the schema alone.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the description's burden is lighter. It still adds real behavior: the returned offer is priced with the options the link advertised, which explains why the result may not match a fresh search. It says nothing about auth requirements or what happens with expired or malformed links.

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 invocation trigger, then the return contract, then an example. Nothing is redundant with the schema or annotations, and no sentence could be cut without losing routing 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?

Even though an output schema exists, the description correctly summarizes the key return values and their purpose (chaining into get_offer). Combined with the annotation safety profile and full schema coverage for the single URL parameter, an agent has everything needed to call this 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 one parameter at 100% schema description coverage, the baseline is 3, and the description earns a bump by supplying a concrete example URL showing the query-string shape (offer_car, pickup_parking, pickup_at) that the schema only describes abstractly. The example is truncated, so it illustrates format rather than fully documenting 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?

The description names a specific trigger and resource: a beep.rent link to a single offer, including the forms it arrives in (e-mail, campaign, short beep.rent/r/ link). It also distinguishes itself from the downstream sibling by stating it returns search_id and offer_ref for get_offer, so an agent knows this is a link-decoding step, not a search or booking step.

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 an explicit trigger ('Use when the user pastes a beep.rent link') and names the follow-on tool (get_offer), which routes the agent correctly. It stops short of stating when not to use it, e.g. that pasted non-beep.rent URLs or plain offer searches belong to search_offers instead.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful domain context: prices are monthly in PLN per mileage package, VAT differs for business versus individual customers, and each package includes an inquiry link. It does not discuss pagination or rate behavior, but with annotations covering safety this is a strong addition.

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

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

The description is compact and front-loaded, opening with the core use case before giving exclusions and examples. Every sentence carries useful routing or filtering information, and the examples are efficiently placed at the end.

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 14 optional parameters and an output schema, the description is largely sufficient: it explains the main scope, the key VAT and facet semantics, and gives examples. The remaining gap is that it does not fully explain all filter parameters or clarify where facet values come from, but the output schema and enum constraints reduce the burden.

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 50% across 14 parameters, so the description must compensate. It adds key semantics for facets-based filters, customer_type VAT treatment, rent_length values, and examples, but many parameters such as market, ordering, transmission, production-year bounds, limit, and offset are not meaningfully explained beyond their names or enums.

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

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

The description states a specific resource and scope: a car rented for months or years, from 1 month renewed monthly up to 3 years, with monthly PLN prices, VAT treatment, and inquiry links per package. It clearly distinguishes this from dated trip search by naming search_offers as the wrong tool for date-based trips.

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 an explicit when-to-use condition and a when-not-to-use condition, directing date-based trips to search_offers. It also explains that filters take facet values, which tells the agent how to populate the filter parameters.

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, open-world behavior, but the description adds the non-obvious stateful semantics: omitted options reset, filters/sort are not remembered across pages, and search_id is required for paging. These are the behaviors an agent would most likely get wrong.

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 use case and exclusion, then the reset/paging rules, then two compact JSON examples. Every sentence earns its place and there is no filler.

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

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

For a 15-parameter nested search tool, the description covers the highest-risk decisions: when to call it, how to page, and when state resets. An output schema exists so return values need not be described; remaining gaps are secondary parameter semantics already partly covered in 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 description coverage is only 20% across 15 parameters, so the description must carry weight. It explains the core composite requirement (pickup + pickup_at + return_at together), the search_id paging path, and the sort usage via a concrete example, though it does not clarify limit/offset interaction with search_id, market, card_type, driver_age, or response_format.

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 gives a specific verb and resource (search offers for available cars with full prices) plus a market scope (Poland), and explicitly excludes reservation-related siblings. It does not distinguish itself from search_long_term_offers, which is the one remaining ambiguity.

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

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

It states when to use it, when not to use it ('Do not use for an existing reservation'), and how to page versus how to start a new search. The 'supply the whole trip when changing criteria' rule and the 'repeat filters and sort on every page' rule are explicit operating instructions.

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 write/side-effecting, open-world, non-idempotent behavior, but the description adds the crucial concrete disclosure that an email is actually sent to the customer's address — a real external side effect an agent must anticipate. It stops short of saying whether repeated calls send repeated emails or whether the code expires.

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 trigger clause is front-loaded, the mechanism follows in one compact sentence, and the two example payloads efficiently convey the optional-parameter shape. No filler sentences.

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

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

An output schema exists, so the description needn't explain return values, and it correctly focuses on the flow it initiates. The only material gaps are the unexplained market parameter and the absence of a pointer to the verification step that consumes management_id.

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 must carry the load: it explains that email is the booking's address the code goes to, and that reservation_number is optional and narrows the unlock scope to one reservation versus every reservation on that email. The market parameter is not mentioned at all, leaving one of three parameters undocumented in both schema and prose.

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 action (starts reservation management) and the concrete mechanism: it emails a 6-digit code to the booking's email address and returns a management_id. This clearly distinguishes it from siblings like cancel_reservation or list_my_reservations, which operate on an already-established session.

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

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

"Use when the user wants to see, cancel or extend their reservations" gives an explicit trigger condition, and the description explains the two modes (with vs. without reservation_number). It does not name the follow-up tool (verify_reservation_management / confirm_reservation_code) or any alternative entry point, so it stops short of full routing guidance.

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

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

Annotations already declare this is a non-readOnly, idempotent, non-destructive call, so the safety profile is covered. The description adds genuinely useful context the annotations lack: the unlock scope and the 2-hour, conversation-scoped session lifetime. It does not explain what happens on repeated wrong codes, which is exactly why 'Never guess' matters.

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 and free of filler, and the embedded example is useful. However, the central sentence is a convoluted run-on ('or, for a code sent for an e-mail alone, that e-mail's reservations') that is hard to parse on first read and buries the two distinct outcomes.

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

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

With an output schema present, return values need no explanation, and the description still covers the key post-call contract (use the returned management_id) plus session scope. The remaining gap is failure behavior for an invalid or expired code on a stateful verification 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 33%: code is documented in the schema as the 6-digit value, and market has no description anywhere. The description does add real meaning for management_id by implying it is the token returned by the preceding start/verify step, but market remains completely unexplained in both places.

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

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

The description states a concrete verb and resource (verify the 6-digit management code) and spells out the effect: unlocking the reservation summary, cancellation and extension options, or an e-mail's reservation list. It implicitly separates itself from the confirmation-code siblings by tying the code to the 'management e-mail', but it never names start_reservation_management or confirm_reservation_code as the alternative paths.

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?

Clear conditions are given — use the 6-digit code from the management e-mail, then continue with the returned management_id, and 'Never guess a code' as an explicit prohibition. What's absent is how to obtain the management_id in the first place and what to do when the code is rejected or expired.

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