Bota — car rental availability and bookings

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this is a state-changing, non-read operation. The description adds useful specifics beyond that: Bota answers in the customer's language using approved info, and the conversation can actually complete a booking for booking_via_agents=true companies, explaining what the mutation consists of.

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

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

Three tight sentences with zero filler, front-loaded with the core action and followed by behavior and the booking edge case. Efficient and well-ordered, though the parenthetical example list is slightly loose.

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

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

With no output schema, the description reasonably covers behavior: language handling, source of answers, and the conditional booking case. It stops short of describing the response shape (e.g., that an answer/message is returned and a session_id should be carried forward), which would help an agent chain calls.

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 75%, with the schema already documenting language (BCP-47), company_id, and session_id in detail. The description only implicitly reinforces the session concept ('within a session') and the language behavior, adding little beyond the structured fields; the 2000-char message limit is left entirely to the schema.

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

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

The description gives a specific verb and resource: 'send a free-text message to the company's Bota agent within a session', plus the domain (conditions, insurance, extras, changes). This clearly separates it from the action-specific siblings like search_availability and select_offer, though it does not name any sibling explicitly.

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

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

It provides clear context for when to use the tool (open questions about conditions, insurance, extras, changes) and a notable secondary case for booking_via_agents=true companies. However, it offers no exclusions or explicit guidance on when to prefer the specialized siblings (e.g., select_extras, provide_customer_details) over free-text chat.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is partly covered. The description adds genuinely new context: the reservation is created in the company's reservation system, a confirmation code is returned, and a payment link appears when prepayment is required. It does not warn about duplicate-confirm behavior, which matters given idempotentHint=false, so it falls short of a 5.

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

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

Two sentences, zero filler, and the sequencing instruction is front-loaded before the side-effect description. Every clause carries a distinct piece of 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 no output schema in the structured data, the description compensates by naming the return values (confirmation code, conditional payment link). It also covers the token precondition and the reservation side effect, so 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?

Schema coverage is 100%, so 3 is the baseline. The description goes beyond it by explaining what confirmation_token actually represents — proof that the customer saw that exact summary — which clarifies why it must be echoed verbatim rather than regenerated. Other parameters are left to the schema.

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

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

States a specific verb+resource ('Confirm the booking') and then names the actual side effect ('Creates the reservation in the company's reservation system'), plus the return payload. An agent can distinguish it from siblings like select_offer or provide_customer_details without opening any schema.

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

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

The precondition is explicit: pass the confirmation_token returned by the previous call, which proves the customer saw that exact summary. That establishes the correct point in the flow. It stops short of naming an alternative tool or stating when not to use it (e.g. if the customer wants to change the offer first), so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: it discloses the payload contents (name, city, address, hours, timezone, coordinates), which matters because there is no output schema. It stops short of noting pagination, scoping, or any auth constraints.

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

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

Two tight sentences with no filler, front-loaded with the resource and its returned fields, then closing with the cross-tool instruction. The field enumeration is dense but each item carries information the agent cannot get elsewhere since there is no output schema.

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

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

For a simple read-only lookup with 100% schema coverage, the description supplies the missing return-shape information and names the downstream consumer of the office name. With annotations covering the safety profile and no output schema to lean on, this is close to complete, though it omits any indication of result volume or filtering.

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

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

Schema description coverage is 100%: language and company_id are both fully documented, including where company_id comes from (list_rental_companies). The description adds no further parameter meaning, so the baseline 3 is appropriate.

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

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

The description names the resource precisely ('rental offices / pickup-return locations of a company') and enumerates the fields returned, so an agent knows exactly what this tool produces. It is clearly distinct from sibling getters like list_rental_companies or search_availability, though the listing verb itself is only implied by the field enumeration.

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 sentence 'Use the office NAME in search_availability' gives a concrete downstream usage rule and implicitly routes the agent through the office-list to availability search. However, it never states when NOT to use this tool or contrasts it directly with alternative office-related siblings, so 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 and openWorldHint, so safety is covered. With no output schema present, the description carries the return-shape burden and does so by naming id, name, website, active channels, booking_via_agents, and the demo flag — a meaningful disclosure the structured fields do not provide. Permissions and pagination behavior remain unstated.

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

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

Three short sentences, front-loaded with the action, then the return shape, then the usage cue. No filler or restated title, and each sentence adds 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?

For a zero-parameter, read-only discovery tool with no output schema, the description supplies everything needed: what comes back, what the boolean fields mean, and where it sits in the flow. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.

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

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

States a specific verb and resource ('List the car-rental companies that sell through Bota'), scoped tightly enough that an agent can distinguish it from list_offices and the booking-flow siblings without opening any schema. The enumeration of returned fields reinforces exactly what entity is being listed.

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?

'Start here' gives an explicit entry-point cue, telling the agent this is the first call in the flow rather than a mid-flow lookup. It stops short of naming alternatives or stating when-not to call it, so it falls short of a 5.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description adds meaningful context: it must follow explicit terms acceptance, and the call triggers a summary confirmation step ('Bota then shows the summary'). This sequencing/side-effect information goes beyond the annotations. It doesn't cover error behavior or what happens to previously supplied details.

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

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

Three short sentences, front-loaded with the core action and then the precondition and result. Every sentence carries information; there is no padding or restatement of the name.

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

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

There is no output schema, so the description must carry return/next-step context; it partially does by noting the summary confirmation. However, for a 10-parameter write tool with 6 required fields it omits session reuse, validation expectations, and failure behavior, leaving material gaps.

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

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

Schema coverage is only 30%, with six params (first_name, last_name, email, phone, flight_number, notes) carrying no schema description. The phrase 'driver's details' loosely frames the identity/contact fields and the description adds real meaning for terms_accepted, but session_id continuity, notes, and flight_number are never addressed, so it only partially compensates.

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

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

States a specific verb+resource: 'Submit the driver's details for the booking in progress.' An agent can distinguish it from siblings like confirm_booking or select_offer by the customer-data-collection role. It stops short of naming which sibling follows, so it misses the explicit differentiation a 5 requires.

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 precondition: 'Only call it after the customer has explicitly accepted the company's terms (terms_accepted must be true).' This is genuine when-to-use guidance with a hard gate. No alternative tool is named for the other cases, so it isn't a full when/when-not/alternatives statement.

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

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

Beyond the annotations (readOnlyHint/openWorldHint), the description discloses meaningful behavior: prices match the company web chat with mandatory charges and one-way/time rules baked in, and it returns numbered offers. The session_id continuity requirement is useful operational context the annotations do not cover; only the return shape details remain unstated.

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 core action, then pricing fidelity, then return/session behavior. Each sentence carries distinct information with no padding; slightly more routing detail could have been added without bloat.

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

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

With no output schema, the description usefully notes it "Returns numbered offers," closing the biggest gap for an 11-parameter tool. It stops short of naming the follow-up tools (select_offer/select_extras/confirm_booking), but for a read-only search step it is largely complete.

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

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

Schema description coverage is 82%, so the schema already documents nearly all 11 parameters (language, dates, session_id, offices). The description adds only the high-level notion that company/office/dates and session_id matter, which the schema already conveys; baseline 3 applies.

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

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

States a specific verb ("Search") and resource ("available vehicles") plus the scope it operates over (company, office, dates). An agent can tell this is the offer-listing step of the booking flow, but the description does not explicitly contrast itself with siblings like select_offer or list_offices.

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 phrase "keep the session_id to select one" implies this is the first step and that selection follows, but there is no explicit when-to-use, prerequisites, or named alternative. The workflow position is only implied, leaving the agent to infer the sequence from the sibling list.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries most of the burden; it adds a real precondition (booking_via_agents=true) and the ordering relative to select_offer. It doesn't disclose what happens on invalid/duplicate ids or whether extras can be replaced later.

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

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

One dense sentence covering action, examples, sourcing of ids, empty-list escape hatch, and the gating flag — 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?

Covers what the tool does, its input source, the no-op path, and the access precondition. Without an output schema or annotations detailing state changes, it could say more about how extras interact with the booking state, but it is sufficient to invoke correctly.

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

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

Schema coverage is already 100% and each param has a rich description (extras, language, company_id, session_id). The description adds the semantics of the empty list, but that is already stated in the schema's extras description, so added value is marginal.

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 (add) plus resource (extras) and enumerates examples (child seat, additional driver, coverage). It distinguishes itself from siblings by naming the upstream select_offer whose ids feed this call.

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 says to use ids returned after select_offer, and explicitly covers the alternative path — pass an empty list to continue without extras. Also states the precondition booking_via_agents=true.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent knows this mutates state, and the description adds the booking_via_agents=true precondition and the hand-off to extras/driver steps. It does not disclose the core behavioral trait of selecting an offer — whether it holds/reserves the offer, for how long, or whether it can be undone.

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

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

Three short sentences, front-loaded with the action and its source, then prerequisites. No redundancy, though 'Bota then asks for extras or driver details as needed' is flow narration rather than definitional content.

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 state-mutating, session-dependent tool with no output schema, the description covers preconditions and downstream steps but omits what the selection produces and its lifecycle (hold duration, expiry, reversibility). An agent can call it, but not fully predict consequences.

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

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

Schema coverage is 75% and company_id, session_id, language already carry documentation. The description adds real meaning for offer_number by tying it to the numbered results of search_availability in the same session, but adds nothing for the remaining parameters. Baseline 3 fits.

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

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

Specific verb and resource: 'Choose one of the numbered offers returned by search_availability'. It anchors the tool to its sibling search_availability and to the session flow, so an agent can tell it apart from confirm_booking and select_extras. It stops short of explicitly naming what it is not.

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 ordering context ('returned by search_availability, same session') and a hard prerequisite ('Requires booking_via_agents=true'), plus what follows next (extras or driver details). No explicit when-not-to-use guidance, but the sequencing is clear enough to route correctly.

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