HemmaBo Direct Booking

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

The annotations already indicate destructiveHint=true (mutation) and idempotentHint=true (safe to retry), but the description adds valuable context beyond this: it specifies that refunds are processed via Stripe, refund amounts depend on the host's cancellation policy, and it returns cancellation confirmation with refund details. This enriches the behavioral understanding without contradicting annotations.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by usage guidelines and behavioral details. Each sentence earns its place by providing critical information without redundancy, making it highly efficient and well-structured.

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 a cancellation tool with financial implications, the description is quite complete: it covers purpose, usage, behavioral traits (refunds, policy dependency), and output details. However, there's no output schema, so the description must explain return values, which it does adequately but could be more explicit about error cases or confirmation format.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any additional semantic details about the parameters beyond what's in the schema (e.g., it doesn't explain format or constraints for reason or reservationId). Thus, it meets the baseline of 3 without compensating further.

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

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

The description clearly states the specific action ('Cancel a confirmed booking and process the Stripe refund') and distinguishes it from siblings by specifying it's for confirmed bookings only, not pending/unpaid ones. It explicitly mentions the resource (booking) and the financial consequence (Stripe refund), making the 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?

The description provides explicit guidance on when to use ('when the guest explicitly requests cancellation') and when not to use ('Do NOT use for pending/unpaid bookings — those expire automatically'). It also implies alternatives by referencing sibling tools like hemmabo_booking_checkout and hemmabo_booking_create for obtaining the reservationId, though it doesn't name specific alternatives for other scenarios.

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 adds valuable behavioral context beyond the annotations. While annotations indicate this is not read-only, idempotent, or destructive, the description warns against double charges, specifies that it creates a booking record and generates a Stripe payment page, and mentions optional quoteId usage to lock prices. However, it doesn't detail error handling or rate limits, leaving some behavioral aspects uncovered.

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 and front-loaded, starting with the core purpose. Each sentence adds critical information—usage timing, warnings, optional parameters, and return values—with zero waste. The structure is logical and efficient, making it easy to parse quickly.

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

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

Given the complexity of a payment and booking tool with no output schema, the description is largely complete. It covers purpose, usage, warnings, optional parameters, and return values (reservationId, paymentUrl, pricing details). However, it lacks details on error cases or what happens if payment fails, which would enhance completeness for this critical operation.

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

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

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal parameter semantics, only mentioning quoteId from hemmabo_booking_negotiate and implying price locking. It doesn't provide additional meaning beyond the schema, so it meets the baseline but doesn't enhance parameter understanding significantly.

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 purpose with specific verbs ('Create a booking with Stripe payment and return a checkout URL') and resources (booking record, Stripe payment page). It explicitly distinguishes this from sibling tools by mentioning when to use it versus alternatives like hemmabo_booking_status and hemmabo_booking_negotiate, making the purpose highly specific and differentiated.

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

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

The description provides explicit usage guidelines: 'Use this tool when the user is ready to pay' and 'Do NOT call twice for the same booking — check hemmabo_booking_status first to avoid double charges.' It also mentions an alternative tool (hemmabo_booking_negotiate) for optional quoteId usage, clearly defining when and how to use this tool versus others.

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 adds valuable behavioral context beyond the annotations: it specifies that bookings are created with status 'pending' and require host approval, and it warns about duplicate booking risks on timeout. The annotations (readOnlyHint: false, destructiveHint: false) indicate it's a non-destructive write operation, which the description's 'Create' action aligns with, so there's no contradiction.

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

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

The description is efficiently structured in three sentences: the first states the purpose and key behavioral traits, the second provides usage guidelines and alternatives, and the third covers retry caution and return values. Each sentence adds essential information with zero waste, making it front-loaded and appropriately sized.

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 (a write operation with behavioral nuances) and the absence of an output schema, the description effectively compensates by explaining the return values ('bookingId, final price, and confirmation details'), behavioral outcomes, and usage constraints. It provides a complete picture for an agent to invoke the tool 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?

The input schema has 100% description coverage, providing detailed parameter documentation (e.g., formats, constraints). The description does not add any parameter-specific information beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for gaps.

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 specific action ('Create a direct booking without online payment') and distinguishes it from the sibling tool hemmabo_booking_checkout for paid bookings. It specifies the legacy flow and the resulting booking status ('pending'), making the purpose unambiguous and differentiated.

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 guidance on when to use this tool ('when the user wants to book without Stripe payment') and when not to ('Do NOT use for paid bookings — use hemmabo_booking_checkout instead'). It also includes a specific caution about retry behavior ('Do NOT retry on timeout without calling hemmabo_booking_status first'), offering clear alternatives and 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 destructiveHint=false, indicating this is a safe read operation. The description adds valuable behavioral context beyond annotations: it specifies the price lock duration (15 minutes), explains that the quote is binding, and clarifies the relationship with checkout. However, it doesn't mention rate limits, authentication requirements, or error conditions.

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 efficiently structured with three sentences that each serve a distinct purpose: stating the tool's function, providing usage guidance, and describing the return values. There's no wasted language, and the most critical information (creating a binding quote) appears 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 tool with good annotations (readOnlyHint, destructiveHint) and full schema coverage, the description provides excellent context about the tool's purpose, usage, and output. It explains the return values in detail despite no output schema. The only minor gap is lack of information about error conditions or rate limits, but overall it's quite complete for this complexity level.

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

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

Schema description coverage is 100%, so the input schema already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

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

The description clearly states the specific action ('Create a binding price quote that locks the price for 15 minutes') and the resource involved (booking price). It distinguishes this tool from its sibling 'hemmabo_booking_checkout' by explaining that this tool provides price certainty while checkout calculates fresh prices without a quoteId.

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 guidance on when to use this tool ('before hemmabo_booking_checkout to guarantee the quoted price during payment') and when not to skip it ('Do NOT skip this step if the user wants price certainty'). It names the alternative ('checkout calculates a fresh price') and explains the consequence of skipping ('without a quoteId, checkout calculates a fresh price that may differ').

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 indicate read-only, non-destructive, and idempotent behavior, which the description doesn't repeat. The description adds valuable context beyond annotations: it specifies that prices are integers in local currency (e.g., SEK), describes the return structure (publicTotal, federationTotal, etc.), and warns about quote invalidity if dates are unavailable. However, it doesn't mention rate limits or authentication needs, leaving some behavioral aspects uncovered.

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 purpose and usage guidelines, followed by return details. Every sentence earns its place: the first states the purpose, the second provides usage rules, and the third explains the return values and currency. There is no wasted text, and it's structured for quick comprehension.

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 (pricing calculations), rich annotations (read-only, idempotent), and 100% schema coverage, the description is mostly complete. It explains the return structure in detail, which compensates for the lack of an output schema. However, it doesn't cover edge cases like error handling or how gap-night discounts are determined, leaving minor 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 description coverage is 100%, with each parameter well-documented in the input schema (e.g., guests determine price tiers, checkIn must be today or later). The description adds minimal parameter semantics beyond the schema, only implying that propertyId comes from hemmabo_search_properties. Since the schema does the heavy lifting, the 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 purpose: 'Get a detailed pricing quote for a specific property, dates, and guest count.' It specifies the verb ('Get'), resource ('pricing quote'), and scope ('detailed'), and distinguishes it from siblings like hemmabo_search_availability (which checks availability) and hemmabo_booking_create (which creates a booking).

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

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

The description provides explicit usage guidance: 'Use this tool after confirming availability to show the user exact pricing before booking. Do NOT use before checking availability — the quote may be invalid if dates are unavailable.' It names when to use (after availability check) and when not to use (before availability check), with a clear alternative implied (hemmabo_search_availability).

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

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

Annotations already indicate this is a destructive, non-idempotent write operation (readOnlyHint: false, destructiveHint: true). The description adds valuable behavioral context beyond annotations: it explains automatic price recalculation, Stripe charge/refund handling, and what information is returned. No contradictions with annotations exist.

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 efficiently structured with three sentences: first states purpose, second provides usage guidelines, third explains behavioral outcomes. Every sentence adds value without redundancy, and key information is front-loaded.

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

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

For a destructive mutation tool with no output schema, the description does well by explaining what the tool returns (previous dates, new dates, price delta, Stripe details). It covers behavioral aspects like price recalculation and payment handling. The main gap is lack of explicit error scenarios or rate limit information, but overall it's quite 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 100%, with all parameters well-documented in the schema. The description doesn't add significant parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It mentions 'reason' is optional/recommended, but this is already covered in 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 clearly states the specific action ('reschedule'), target resource ('confirmed or pending booking'), and scope ('to new dates'). It distinguishes this tool from siblings like cancel, create, and status tools by focusing on date changes for existing bookings rather than creating new ones or checking status.

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 guidance on when to use ('when the guest wants to change travel dates on an existing booking') and when NOT to use ('Do NOT use if the booking is cancelled or completed'), plus a specific alternative action ('check hemmabo_booking_status first'). This gives clear context for tool selection versus 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 indicate read-only, non-destructive, and idempotent behavior, but the description adds useful context by specifying the return content (e.g., 'booking dates, guests, price, status, property info, and cancellation policy'), which helps the agent understand the output format. No contradictions with annotations are present.

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 purpose, followed by usage guidelines and return details in three concise sentences. Every sentence adds value without redundancy, making it efficient and well-structured.

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 low complexity (one parameter, no output schema), the description is largely complete, covering purpose, usage, and return details. However, it could slightly improve by mentioning error cases or limitations, but annotations provide safety context, so it's still strong.

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

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

Schema description coverage is 100%, so the input schema fully documents the single required parameter (reservationId). The description does not add any parameter-specific information beyond what the schema provides, making a baseline score of 3 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 verb ('retrieve') and resource ('current status and full details of an existing booking'), distinguishing it from siblings like hemmabo_booking_cancel or hemmabo_booking_create by focusing on status retrieval rather than modification or creation.

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 explicit guidance on when to use this tool (e.g., 'check payment status', 'confirm a booking went through', 'look up details before rescheduling or cancelling') and references a specific sibling tool ('Use after hemmabo_booking_checkout if unsure whether the booking succeeded'), clearly differentiating it from alternatives.

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 adds valuable behavioral context beyond annotations: it specifies the return format ('one entry per propertyId'), sorting order ('sorted by federation price (cheapest first), with unavailable properties last'), and constraints ('2–10 specific properties'). Annotations cover read-only, non-destructive, and idempotent aspects, but the description enriches this with output behavior and scope details, though it doesn't mention rate limits or auth needs.

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

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

The description is front-loaded with the core purpose, followed by usage guidelines and behavioral details. Every sentence earns its place: the first defines the tool, the second provides usage context, and the third specifies output behavior. It's efficiently structured without wasted words.

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

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

Given the tool's complexity (comparison with multiple properties), rich annotations (read-only, idempotent, etc.), and 100% schema coverage, the description is complete. It covers purpose, usage, and output behavior adequately. Since there's no output schema, the description's details on return format and sorting are particularly valuable, ensuring the agent understands what to expect.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal semantic context by implying the parameters are used for comparison on 'the same dates,' but it doesn't provide additional meaning beyond what the schema specifies. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Compare availability and pricing'), the resource ('2–10 specific properties'), and scope ('on the same dates'). It distinguishes from sibling tools by explicitly contrasting with 'hemmabo_search_properties' for discovery, making the purpose unambiguous and differentiated.

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 guidance: 'Use this tool when the user is deciding between multiple properties and wants to see price and availability side by side.' It also gives a clear exclusion: 'Do NOT use for discovery — use hemmabo_search_properties first.' This directly addresses when to use this tool versus alternatives, including a named sibling 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations by specifying the return format ('Returns available=true/false with conflict details') and listing types of conflicts ('blocked dates, existing bookings, active locks'), which helps the agent understand output behavior. 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 efficiently structured in three sentences: first states the purpose, second provides usage guidelines with explicit alternatives, third describes return behavior. Every sentence adds critical value with zero wasted words, and it is front-loaded with the core functionality.

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 moderate complexity (3 required parameters), rich annotations covering safety and idempotency, and 100% schema coverage, the description is complete. It adds necessary context on usage timing, sibling tool differentiation, and output format details, compensating for the lack of an output schema. No gaps remain for effective agent use.

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%, with each parameter (propertyId, checkIn, checkOut) fully documented in the input schema. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints. Baseline score of 3 is appropriate when the schema carries the full parameter documentation burden.

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 specific action ('Check whether a specific property is available') and resource ('property') with precise scope ('for the requested dates'). It explicitly distinguishes from sibling tools by naming 'hemmabo_search_properties' as the alternative for general browsing, avoiding tautology and providing clear 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?

The description provides explicit guidance on when to use this tool ('after the user has selected a property from hemmabo_search_properties and wants to confirm availability before getting a quote') and when not to use it ('Do NOT use for general browsing — use hemmabo_search_properties instead'). It names the specific alternative tool and defines the exact context for usage.

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

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

The annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed-world scope. The description adds useful context about it being the 'entry point for all booking flows' and that it returns 'live pricing (public and federation rates)' and 'capacity info needed for subsequent tools', which provides behavioral insights beyond the annotations. However, it doesn't detail rate limits, authentication needs, or error conditions.

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 efficiently structured in three sentences: first states the core functionality, second provides usage guidelines with explicit do/don't instructions, third describes the return value. Every sentence adds value with zero wasted words, making it easy to parse and understand quickly.

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

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

Given the tool's moderate complexity (5 parameters, search operation), the description provides good context about when to use it, what it returns, and how it fits into the broader workflow. While there's no output schema, the description adequately explains the return format. The main gap is lack of error handling or performance characteristics, but overall it's quite complete for a search 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?

With 100% schema description coverage, the input schema already fully documents all 5 parameters. The description mentions 'location and travel dates' which aligns with the schema parameters but doesn't add significant semantic value beyond what's already in the structured fields. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('search available vacation rental properties') and resources ('properties'), and explicitly distinguishes it from sibling tools by specifying it's the entry point for booking flows. It mentions what it returns (list of properties with specific details), making the purpose unambiguous and distinct.

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 guidance on when to use this tool ('when the user wants to find or browse properties') and when not to use it ('Do NOT use if the user already has a specific propertyId'), naming specific alternatives (hemmabo_search_availability or hemmabo_booking_quote). This gives clear context for tool selection among siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond this: it specifies that results exclude the source property, include live pricing, and are based on availability on specific dates. However, it doesn't mention rate limits or authentication needs, which could be relevant for an agent.

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 purpose in the first sentence, followed by usage guidelines and exclusions. Every sentence earns its place by providing critical context without redundancy. It's appropriately sized for the tool's complexity, with no wasted words.

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

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

Given the tool's moderate complexity (5 parameters, no output schema), the description is largely complete. It clarifies the tool's role in the workflow, behavioral traits like exclusions and live pricing, and usage constraints. However, without an output schema, it doesn't detail the return format (e.g., list structure, fields), leaving a minor gap for an agent.

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%, with each parameter well-documented in the input schema (e.g., propertyId as UUID, checkIn/checkOut as ISO dates with constraints). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'guests' defaults to the source property's max_guests, which is already in the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action ('Find vacation rental properties similar to a given property') and resource ('properties'), distinguishing it from siblings like hemmabo_search_properties (initial search) and hemmabo_compare_properties (comparison). It explicitly mentions the context of 'after the user has selected a property' and criteria like 'same region, same property type, same or larger capacity.'

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 guidance on when to use this tool ('after the user has selected a property via hemmabo_search_properties and wants to see alternatives') and when not to use it ('Do NOT use for the initial search; use hemmabo_search_properties instead'). It also implies alternatives by naming hemmabo_search_properties and hemmabo_compare_properties in context.

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