HotelsCasa

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond these: fare is set by the taxi company and shown before ordering, services grow city by city, and the crucial instruction to always provide the URL as a clickable link. This adds value without contradicting 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?

The description is longer than average but necessary to cover three distinct services. It is structured with quoted service names and a critical final instruction, front-loading the core purpose. Every sentence earns its place, though it could be slightly tightened without losing information.

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

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

Given the tool has 11 parameters and an output schema, the description explains the main flows and the crucial link-display rule. It doesn't detail every parameter, but the schema covers the rest. It provides enough context for an agent to invoke it correctly across the three services.

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 73%, so the description supplements it. It clarifies which parameters apply to which service (e.g., origin, destination, passengers, luggage, and when are taxi-specific; pickup_date and return_date are car rental; shipment_scope for shipments) and explains that taxi orders can be pre-filled with given details. This adds meaning beyond the schema's sparse descriptions.

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

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

The description explicitly names three services (taxi, shipment, car_rental) with specific verbs and resources, and clearly distinguishes them from sibling tools (e.g., find_flights) by focusing on ground transport. Each service has its own explanation, 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 provides clear context for when to use each service (e.g., taxi for ordering a taxi/transfer, shipment for sending parcels, car_rental for renting a car). However, it does not explicitly state when not to use this tool or name alternative tools, though the sibling names imply alternatives like find_flights for air travel.

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 read-only and idempotent, and the description adds substantial behavioral context: on_request objects return available:null as a normal path, instant vs on_request modes behave differently, hotels return a rooms[] array, price_total includes fees, booking links must not be altered, and loyalty_bonus is credit rather than a discount. No contradiction with annotations exists.

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

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

The description is long but well-organized into clear sections with uppercase headers and front-loaded core purpose. There is some redundancy, such as repeating that the owner replies personally and that on_request is not a failure, but most sentences carry a distinct behavioral rule. It earns its length given the complexity of the tool.

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 complexity of instant vs on_request properties, hotel room arrays, price breakdowns, loyalty bonuses, booking links, and language handling, the description is remarkably complete. The output schema exists, so return-value details do not need to be repeated. The only notable omissions are minor parameter details already present in the schema. The agent has enough context to invoke the tool correctly and present results appropriately.

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

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

With schema coverage at 50%, the description compensates by explaining that items are capped at 10, property_key comes from search_properties results, dates are the trigger for a real price, and missing dates make price_from only indicative. However, the guests parameter is not mentioned at all, and lang is only implied through the text-language guidance. It adds strong semantics for the most important parameters but leaves a couple 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 opens with a specific verb and object: 'Check availability and price for up to 10 properties on given dates.' It directly answers the traveler's question and explicitly distinguishes itself from search_properties, which 'never does' this. An agent can immediately tell what the tool does and how it differs from siblings.

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 when-to-use guidance: call it as soon as the traveler gives dates, never search the web instead, and use the property_key from search_properties results. It also states what to do when dates are missing — ask for dates and then call check_availability — and clarifies that on_request results are not failures. This strongly routes the agent to the correct workflow.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: null price_day is normal and common, total_eur:null with price_note is not a failure, instant:true vs owner-confirmed booking flow, and the golden link rule. It also discloses data limitations (no phone/address/licence plate, approximate coordinates). This is rich, non-obvious behavior that an agent must 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?

The description is longer than average but every section earns its place: the first sentence is a clear summary, then sections cover business logic (private owners), price semantics, the golden link rule, and data privacy limitations. It is front-loaded with the core purpose and then organized into labeled paragraphs. Slightly verbose in places (e.g., repeated emphasis on null being normal), but the repetition serves to prevent a costly misinterpretation.

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 complexity (business rules, null semantics, booking link requirement, privacy constraints) and the presence of an output schema, the description is complete. It covers what the agent needs to correctly interpret results and present them to the traveller. The output schema exists, so return values don't need to be re-explained in detail, but the description adds the crucial interpretation layer (null is normal, not a failure).

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

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

Schema coverage is 67%: pickup_date and return_date are described as YYYY-MM-DD, but vehicle_ids has no description beyond type/maxItems. The description compensates by explaining the meaning of key outputs (available, days, price_day, total_eur, price_note) and the max 10 cars constraint, which maps to vehicle_ids maxItems. It doesn't add detail about the vehicle_ids format, but the schema already defines it as an array of integers. Slight gap: no explicit statement that vehicle_ids must come from a prior search, but the overall context is strong.

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: 'Check availability and total price of up to 10 cars for given pickup/return dates.' It clearly distinguishes this from siblings like search_vehicles (searching) and get_vehicle (single vehicle details) by focusing on availability and price for a date range. The scope (up to 10 cars) and key outputs are named.

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 context: checking availability and total price for given dates. It also provides strong usage guardrails: never call a car with price_day:null unavailable, always include booking_link verbatim, never invent phone/address/licence plate, and treat coordinates as approximate. These are clear behavioral instructions that an agent can follow without ambiguity.

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 description goes well beyond the annotations (readOnly, idempotent, non-destructive) by disclosing critical behavioral traits: it does not return live fares, returns a page URL plus IATA code, only covers 108 destinations in Europe and the Americas, and mandates that the URL must be given as an unchanged clickable link because it is the only way to book. These details are not present in the annotations and are essential for the agent to set traveller expectations and handle the response correctly.

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 appropriately sized for the tool's complexity. It front-loads the core purpose in the first sentence, then clarifies a key limitation (no live fares), explains the return behavior, and ends with actionable instructions for the agent. Every sentence earns its place and there is no redundant or filler content. The structure is logical and easy to parse.

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

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

The description is complete for an agent to call this tool correctly. It covers what the tool returns (flight page or general search page, plus IATA code), the scope (108 destinations), what it does NOT return (live fares), and how the agent should present results (tell traveller to enter origin/dates, give clickable URL). The output schema exists and would detail the response structure, so the description need not repeat that. No critical information is missing.

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

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

Schema description coverage is 100% – both 'lang' and 'destination' are fully described with types and examples (e.g., 'Rome, LIS, Buenos Aires'). The description adds minimal additional parameter meaning: it implies 'destination' determines which page is returned and that the page language may be controlled by 'lang', but these are already inferred from the schema. No new semantics beyond the schema are provided, so a baseline score of 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 clearly states the tool's function: 'Link to search and book flights on HotelsCasa.' It specifies that it returns a flight page URL (destination-specific or general) plus the IATA code, and explicitly distinguishes itself from live-fare tools by stating it does NOT return live fares. This sets it apart from sibling search tools for other categories (hotels, activities, vehicles). The verb 'find' and resource 'flights' are specific and unambiguous.

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

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

The description provides clear context on when to use this tool (to obtain a flight search page) and a key limitation ('does NOT return live fares'), which serves as a when-not. It also instructs the agent to tell the traveller to enter origin and dates on the page and to always provide the URL as a clickable link. However, it does not explicitly name alternative tools for other categories or state conditions for choosing this over siblings, though the sibling list makes that implicit.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the bar. The description adds real behavioral value by requiring the agent to always return the page URL as an unchanged clickable link and explaining it is the only way to book or buy. 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?

Two compact sentences with no fill. The first sentence front-loads the tool's purpose and the full list of returned fields, while the second delivers the critical link-handling rule. Every clause 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 read-only, two-parameter lookup with an output schema, the description is complete. It specifies what data the traveller receives and the essential delivery requirement about the URL. The schema plus output schema cover the remaining details, so nothing needed to call the tool correctly is missing.

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

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

Schema description coverage is 100%, so lang and activity_key are already fully documented in the schema. The description only reinforces that activity_key selects a single activity, adding marginal semantic value beyond the schema. 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?

States a specific verb and resource: 'Details of one activity by activity_key' and enumerates the exact content returned (description, inclusions, duration, cancellation, dates/prices, photos, page url). This makes the tool's role immediately clear and distinguishable from search_activities and sibling get_* 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 schema notes that activity_key comes from search_activities, which implies this tool is for retrieving details after a search. However, the description itself never explicitly says when to use this tool vs search_activities or other siblings, nor does it state exclusions. Usage is implied rather than clearly instructed.

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 clear. The description adds meaningful behavioral context: the instruction to always present the page URL as a clickable link, unchanged, and the warning that it is the only way to book or buy. This goes beyond the annotations by informing the agent of a critical output-handling requirement, justifying a score above the baseline.

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 with zero redundancy. The first sentence concisely enumerates the content and origin, and the second sentence delivers an essential, action-focused instruction about URL handling. Key information is front-loaded, making it easy to scan.

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 fully covers what an agent needs to invoke the tool correctly: it states the source of the key, the list of returned details, and the critical URL requirement. Since an output schema exists, the return format is already documented, and the read-only annotations cover side-effect concerns. No gaps are apparent for a simple hotel-details lookup.

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 80% (only 'adults' lacks a description). The description does not elaborate on any parameters beyond what the schema already provides. It mentions hotel_key and its origin, which matches the schema description. Since the schema does most of the work and the description adds no extra detail for parameters, the baseline of 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 states a specific verb ('get') and resource ('hotel details'), enumerates the exact fields returned (address, description, amenities, photos, check-in/out times, places nearby, guest opinion summary, page URL), and explicitly ties the tool to 'search_hotels' via hotel_key. This clearly distinguishes it from sibling tools like get_property or get_vehicle, which serve different entity types.

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 the correct usage path by specifying that the hotel_key comes from search_hotels, indicating the caller must first perform a search. It does not explicitly name alternatives or state when not to use this tool, but the context (a detailed hotel lookup) is clear enough for an agent to route correctly. Slight deduction for lack of explicit exclusionary 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?

The description goes far beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by detailing the two property types, the obligation to present on_request as available, the golden booking_link rule, the loyalty bonus mechanics, price field semantics, and the need to translate text. It also includes negative instructions (e.g., never compute totals, never strip link parameters). This is rich, transparent behavior disclosure with no contradictions.

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 long but well-structured with clear headings (PRICE FIELDS, LOYALTY BONUS, GOLDEN LINK RULE, TEXT LANGUAGE) and front-loaded purpose. While some repetition exists (e.g., 'never describe them as unavailable' appears twice), every section conveys essential operational rules. It is arguably longer than ideal but remains organized and relevant.

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 complexity, the description covers return content, pricing behavior, booking links, language handling, and edge cases (no dates, on_request). It explains the difference between indicative and confirmed prices, and it references an output schema. No critical operational detail is missing for an agent to correctly present property information.

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 80%, with descriptions for lang, check_in, check_out, and property_key; guests lacks a description. The description adds meaning by explaining that check_in/check_out enable price_breakdown or availability_note, and that without dates price_from is only indicative. It also clarifies property_key's origin. This adds value beyond the schema, though it doesn't elaborate on the guests parameter's purpose.

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 ('get') and resource ('property'), and clearly defines the output: full details for one property by property_key, including description, amenities, photos, house rules, cancellation, reviews, and pricing. It also distinguishes itself from search_properties (which returns search results) and check_availability (which is for availability checks), and it even addresses hotels within its scope. The purpose is unambiguous and differentiates well from siblings.

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 usage context: it is to be used after search_properties, and it instructs to call check_availability when dates are needed. It also explains how to handle on_request vs instant properties. However, it does not explicitly mention when to use get_hotel instead of get_property, despite hotels being covered here; this leaves a small ambiguity in sibling differentiation.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description goes well beyond them with rich behavioral context: the private-owner confirmation model, that price_day:null is normal rather than a data gap, that coordinates are deliberately approximate, and the hard privacy rule about phone/address/licence plate. These are actionable constraints an agent must follow when presenting results, and none contradict 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?

The description is long (~240 words) but organized into scannable labeled sections (CARS ON HOTELSCASA, PRICE, GOLDEN LINK RULE) and front-loaded with the core purpose. Every sentence carries a consequential operational rule rather than filler; it is only held back from 5 by some broader platform business context that is useful but not strictly required for invoking the tool.

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 complexity—output schema present, non-trivial interpretation pitfalls (null prices, approximate coordinates, busy_ranges semantics)—the description covers everything an agent needs: what the tool returns, how to interpret ambiguous values, the mandatory booking_link behavior, and privacy boundaries. The only minor omission is explicit sibling routing, but the output schema and annotations carry the structural weight, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline of 3 applies: lang, vehicle_id, pickup_date, and return_date are all already documented in the schema. The description adds only marginal input-parameter meaning by tying dates to total_eur ('the rental for the whole period'); its main parameter-related content concerns output fields like price_day and booking_link, which belong to the output schema's domain.

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 opening sentence specifies a concrete verb and resource: 'Full details of ONE rental car' followed by an explicit inventory (photos, specs, rental conditions, busy_ranges). The singular 'ONE' and the enumerated contents distinguish it from search_vehicles (a listing tool) and check_vehicle_availability (a focused availability check).

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 operational guidance: use busy_ranges to propose alternative dates, use booking_link to let travellers ask about unrated cars, and never call a price_day:null car unavailable. However, it never names the sibling tools as alternatives (e.g., 'to find cars, use search_vehicles'), so the when-to-use versus alternatives routing 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 convey readOnlyHint, idempotentHint, and destructveHint false. The description adds that the tool only returns offers and sign-up pages rather than performing registration, and includes an important output instruction about giving URLs as unchanged clickable links. 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 informative but verbose: the long list of partner categories is relevant, yet phrasing like 'HotelsCasa invites and is actively looking for' adds padding. The final traveller URL instruction is useful but the overall structure is less crisp than it could be.

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

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

For a read-only reference tool with an output schema and annotations covering safety, the description provides the essential selection context: audience, triggering queries, result content, and URL presentation behavior. Minor confusion from the word 'traveller' in the output instruction does not create a major gap.

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

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

The schema describes lang and provides a profile enum, but the description adds human-readable meaning by enumerating the partner categories and explaining that a selected profile or 'all' controls the returned offers. This compensates for the 50% schema_description_cverage and helps an agent map user intent to profile values.

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

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

The description clearly identifies the tool as being for businesses and professionals who want to work with HotelsCasa, not for travellers, and states it returns what HotelsCasa offers plus the sign-up page for a chosen profile. This differentiates it from traveller-facing sibling tools like search_hotels and book_ground_transport.

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 says to use the tool whenever someone asks how to join, list, register a fleet, or get orders, and explicitly excludes travellers. It does not name alternative sibling tools for traveller bookings, but the when/when-not guidance is clear enough.

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 annotations (read-only, idempotent), it discloses pricing (per person EUR 'from'), that tickets are purchased on the activity page, and the mandatory URL presentation. This adds valuable behavioral context not captured in 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 compact and front-loaded with the core purpose, followed by behavioral notes and a crucial user-facing instruction. No redundant phrasing.

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 return format is covered elsewhere. The description covers essential invocation details, search dimensions, and the unique URL requirement, making it complete for correct usage.

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

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

Schema coverage is 57%, and the description clarifies the purpose of city, country, and query, plus the no-argument behavior. It does not explain 'page' or 'sort', though these are relatively self-explanatory. Partially compensates for the coverage 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 clearly states the tool searches tickets, tours, and attractions, and specifies the search dimensions (city, country, text). It distinguishes itself from sibling 'get_activity' by emphasizing the search nature and partner context.

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 concrete usage patterns: search by city, country, or text; behavior with no arguments; and a critical instruction about presenting URLs as clickable links for booking. Lacks explicit exclusions for when to use alternatives, but the guidance is actionable.

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 readOnly and idempotent annotations, the description discloses important behavior: items without a price are real hotels with no published rate and must not be called unavailable; price_from_eur_per_night is only a starting price; the URL is the only way to book/buy. This adds substantial context beyond the annotations and schema.

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 dense but every sentence carries useful operational guidance: price display formatting, no-price handling, and URL requirements. It is a single large paragraph and the opening catalogue/geography sentence is somewhat broad, but it remains focused enough for a 17-parameter tool.

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, the description appropriately does not need to re-explain return shapes, yet it still covers key output semantics and the no-price edge case. It does not mention partial-hotel-name search via query or explicitly require one of city/lat/lng, but the schema covers those details, so the description is sufficient for normal 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?

The description adds meaning not in the schema: city can be English or local, country disambiguates, lat/lng should be combined with radius_km, and adults/check_in/check_out should be passed so URLs open with dates. Some parameters without schema descriptions, such as page, sort, and stars_min, receive no elaboration, so it is not fully exhaustive.

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: 'Search hotels on HotelsCasa' and clarifies the catalogue scope, search modes, and item fields. It does not explicitly contrast with search_properties or other search siblings, so sibling differentiation is left partly to inference, though the hotel-specific fields make the purpose clear.

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

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

It gives clear context for when to use city vs. lat/lng, when to add country to disambiguate, and that country alone returns its main cities. It also instructs to pass check_in/check_out/adults so links open with dates, but it does not name alternative tools or say when not to use 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 declare readOnly=true, idempotent=true, and destructive=false, and the description adds substantial behavioral context beyond that: the tool never checks availability, on_request properties legitimately have no live prices, price_total includes fees and taxes, and booking_links must never be altered. This directly prevents common agent mistakes such as claiming a home is unavailable based on this search alone.

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 long and dense, but it is front-loaded with the most critical distinction and the availability warning comes early. There is some repetition of the 'do not call this unavailable' rule, and the price and booking-mode guidance could be tightened slightly, but the length is largely justified by the number of failure modes it precludes.

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 search tool with an output schema, this description is remarkably complete: it covers scope, date-handling, availability handoff, booking modes, price fields, link integrity, language translation, and loyalty_bonus presentation. Nothing an agent needs in order to invoke the tool correctly and interpret its results 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?

With 72% schema coverage, the schema documents most parameters, and the description adds further meaning: lat/lng + radius_km is the mechanism for 'near X' queries, and price_min does not filter on_request objects. It does not walk through all 18 parameters, but the most safety-critical and output-affecting semantics are explained clearly.

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: it searches the host-listed holiday homes, villas, rural houses and small hotels on HotelsCasa. It also explicitly sets this apart from the world hotel catalogue of search_hotels, so an agent can tell the two sibling tools apart without opening either schema.

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

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

The description gives explicit routing rules: call check_availability immediately when dates are provided, use get_property for details of a single home, and never search the web for these homes. It also names search_hotels as the alternative for world hotel inventory, making the when-to-use decision unambiguous.

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 readOnly/idempotent annotations, the description discloses critical behavioral facts: cars are privately owned, payment flows to the owner, instant confirmation differs from owner confirmation, price_day:null is normal, booking_link must be preserved verbatim, and phone/address/licence plate must never be invented. This is exactly the kind of 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?

Though long, the description is sectioned, front-loaded with purpose, and every paragraph carries a distinct operational rule. The bold section labels and explicit warnings make the density navigable. Nothing feels padded or redundant.

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 16-parameter tool with no required fields, this description covers usage scope, data model, pricing semantics, mandatory link handling, privacy constraints, and coordinate precision. With an output schema present, return-value details are not needed. An agent has everything required to invoke the tool safely and 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 high (88%), so the baseline is 3, but the description adds real semantic value: it explains the meaning of price_day:null, that price_min keeps cars without a published rate, that coordinates are approximate for radius searches, and how pickup/return dates frame total_eur. It doesn't enumerate every parameter, but it compensates meaningfully beyond the schema.

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

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

The description opens with a specific verb and resource: 'Search RENTAL CARS on HotelsCasa by city, country or geographic radius,' and enumerates the key filter dimensions. It explicitly distinguishes cars from properties, so the agent can separate this from property-search siblings. This is a model of purpose clarity.

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 usage context: 'use this tool only when the traveller asks about a car, never to answer an accommodation question.' It also explains the inventory model, which helps the agent decide when this tool is appropriate. It does not name sibling tools like get_vehicle or check_vehicle_availability, so some selection nuance is left to inference.

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