HemmaBo Host Booking Engine

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

Discloses cryptographic verification (Ed25519 JWS against JWKS), explains that night count drives price and date changes re-price, and reinforces read-only nature beyond annotations, without 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 concise (~150 words) with all sentences adding value, front-loaded with purpose and usage, then parameter details, no fluff.

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 high complexity, full schema coverage, and an output schema, the description fully covers workflow position, parameter behavior, safety constraints, and routing instructions, making it complete 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?

Despite 100% schema coverage, the description adds critical behavioral context: parameters must match search, checkIn must be before checkOut, night count (not dates) drives pricing, and language does not affect price or availability. This clarifies schema constraints and usage.

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 fetches, verifies, and renders a signed stay offer, distinguishing it from sibling tools like hemmabo_booking_quote or verify_vacation_rental_node by specifying it is for host-domain signed offers after search and before quoting/booking.

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

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

Explicitly states when to call (after search returns a host domain, before quoting or booking), what not to do (must not lock quote, create booking, etc.), and how to route bookings (to signed direct_booking_url), providing clear usage boundaries.

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 significant context beyond annotations: it confirms destructiveness, idempotency (cancelling already-cancelled returns same status), rate limiting, and authorization requirements. No contradictions with annotations (readOnlyHint false, idempotentHint true, destructiveHint true).

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 concise (4-5 sentences), front-loaded with the main purpose, followed by usage guidelines and parameter details. Every sentence adds value with no redundancy.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers purpose, usage, behavioral traits, parameter semantics, authorization, and rate limits, making it fully complete for an AI agent to select and 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 100%, so baseline is 3. The description adds value by clarifying that reservationId must be a booking UUID from specific tools and is not a propertyId, and that reason is optional free text forwarded to the host. This exceeds the schema 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 clearly states the verb 'Cancel', the resource 'confirmed booking', and the action 'process the Stripe refund per host cancellation policy'. It distinguishes from siblings by specifying not to use for pending/unpaid bookings, which sets it apart from related tools like hemmabo_booking_create or hemmabo_booking_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?

Explicit guidance is provided: 'Use when the guest explicitly requests cancellation. Do not use for pending/unpaid bookings.' It indicates when to use and when not, but does not explicitly name alternative sibling tools like hemmabo_booking_reschedule for adjustments, which would make it 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?

Adds important behavioral details beyond annotations: non-idempotent, rate-limited, creates server-side pending booking and Stripe session. No contradiction with annotations (readOnlyHint=false, idempotentHint=false).

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?

Single paragraph packs a lot of information but remains readable. Could be slightly more structured with bullet points, but it's not overly verbose. All sentences contribute meaning.

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 (10 parameters, 6 required, output schema present), the description covers purpose, usage, behavior, parameter semantics, and distinguishes from siblings. No 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?

Despite 100% schema coverage, the description adds value by explaining when to use quoteId (honor locked price) vs omit, how paymentMode and channel affect the flow, and defaults for optional parameters.

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

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

Clearly states it creates a fallback non-VRP booking and returns a Stripe checkout URL. Distinguishes from get_verified_stay_offer which provides a direct_booking_url. The verb 'Create' and resource 'non-VRP booking' are specific.

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 instructs to use only after explicit user confirmation when no signed direct_booking_url is available, and to route to get_verified_stay_offer otherwise. Also advises checking hemmabo_booking_status before retrying due to non-idempotence.

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?

Adds context beyond annotations: non-idempotent, rate-limited, pending booking creation, and booking identification criteria. No contradictions with annotations.

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

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

Well-structured with focused sentences, but slightly longer than minimal. Front-loaded core purpose.

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 complexity, schema coverage, and presence of output schema, the description sufficiently covers usage context, parameter roles, and behavioral notes.

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% with detailed descriptions. Description adds value by explaining how parameters collectively identify the booking and their roles in host confirmation and coordination.

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

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

Description clearly states it creates a pending direct booking without online payment for non-VRP fallback deployments, distinguishing it from sibling tools like hemmabo_booking_quote and hemmabo_booking_checkout.

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

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

Explicitly states when to use (after user confirmation, with propertyId from search, no signed VRP URL) and when not to use (VRP offers should route to host-domain URL), with clear prerequisites.

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 important behavioral details beyond the annotations: it writes a short-lived quote snapshot server-side, is rate-limited per token, locks the price for the exact stay range and guests, and the returned quoteId encodes that combination and is honored until validUntil. The annotations only provide readOnlyHint=false and destructiveHint=false, so the description provides necessary context.

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

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

The description is a single paragraph with no wasted words, but it is relatively dense. It could be slightly improved with better structure (e.g., bullet points for usage guidelines), but it is still clear and efficient.

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

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

Given the tool's complexity, the description covers authorization, rate limits, lock duration, usage conditions, exclusions, and relationships to sibling tools. An output schema exists, so return values are not needed. The description is complete for an AI agent to select and 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 already provides descriptions for all 4 parameters (100% coverage). The description does not add significant new meaning beyond what is in the schema; it repeats some details like guest tier and date ranges but does not provide additional constraints or clarifications.

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 creates a binding price quote that locks the price for 15 minutes for specific non-VRP fallback checkout deployments. It distinguishes from the sibling tool get_verified_stay_offer by specifying that this tool is for locking prices when no signed direct_booking_url is available.

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 explicitly states when to use this tool (when no signed direct_booking_url is available and user explicitly asks to lock a price) and when not to use it (for search, availability, VRP offers, rendering a stay-offer widget, or verified-offer display). It also provides the alternative tool name: get_verified_stay_offer.

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 readOnly and idempotent. The description adds behavioral details: returns per-night breakdown, currency type (integer in local currency), and that changing parameters re-quotes. 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 a single paragraph of 5 sentences, front-loaded with the purpose. It is concise with no wasted words, though could be slightly more structured (e.g., bullet points) for clarity.

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 (4 required parameters, no enums, output schema present), the description adequately covers return values (total, breakdown, package context) and usage order. It is complete enough for an agent to use correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds general context (e.g., 'pricing tier' based on night count and party size) but does not significantly enhance individual parameter meanings beyond what schema provides.

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, effectively distinguishing it from sibling tools like search_availability or booking_create.

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

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

Explicitly states when to use ('after confirming availability') and when not to ('Do NOT use before checking availability — the quote may be invalid if dates are unavailable'). Provides clear usage context and 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?

Annotations indicate destructiveHint=true. The description adds valuable context: Stripe charges/refunds, requires Authorization token, rate-limiting, and that it is a destructive write. 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 comprehensive yet front-loaded with core action. Every sentence adds meaningful information, though slightly verbose. Could be trimmed without loss, but still efficient.

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

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

Given the presence of an output schema, the description covers prerequisites (check status), side effects (repricing, Stripe), parameter relationships, and authorization needs. For a mutation tool with annotations, it is fully 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?

Input schema has 100% coverage and detailed descriptions. The description reinforces constraints (e.g., newCheckIn strictly before newCheckOut, date formats) and explains reservationId source, adding extra value 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 uses a specific verb ('Reschedule') and resource ('confirmed or pending booking'), clearly distinguishing from siblings like hemmabo_booking_cancel or hemmabo_booking_create. It explicitly states the date change with automatic repricing and Stripe actions.

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 states when to use (guest wants to change dates on existing booking) and explicitly advises against use if cancelled/completed, recommending checking status first. It does not name specific alternative sibling tools but implies a pre-check step.

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 (readOnlyHint, idempotentHint, destructiveHint), the description discloses important behavioral traits: requires Authorization: Bearer token, returns guest PII (name, email), is rate-limited per token, and clarifies the input is specifically the reservationId from checkout/create. These additions provide critical context not present 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 4 sentences, each concise and purposeful. The first sentence states the core functionality. Subsequent sentences add use cases, auth, data sensitivity, rate limiting, and input origin. No redundant or unnecessary 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 a single parameter and an existing output schema, the description provides all necessary context: input requirements (reservationId format and source), auth requirements, data sensitivity warning, rate limits, and use cases. It does not need to explain return values because the output schema handles that. Complete for the tool's complexity.

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 the uuid format and purpose of reservationId. The description adds semantic value by specifying that the ID must come from hemmabo_booking_checkout or hemmabo_booking_create (not a propertyId), which is a constraint not obvious from the schema alone. Since schema coverage is 100% and description enriches it further, score is above baseline.

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 'Retrieve current status and full details of an existing booking by reservationId', specifying a clear verb ('Retrieve'), resource ('booking'), and input key ('reservationId'). It distinguishes the tool from siblings by stating the input must come from hemmabo_booking_checkout or hemmabo_booking_create, not from propertyId, clearly differentiating it from search and other booking tools.

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

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

The description explicitly states 'Use to confirm checkout/create succeeded or before cancel/reschedule', providing concrete when-to-use scenarios. It implies alternatives (cancel, reschedule tools) and explains read-only nature, giving agents clear guidance on appropriate invocation context.

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. The description adds behavioral details: returns one entry per propertyId, sorted by cheapest direct host-source total first with unavailable last, and warns against presenting discounts in guest-facing copy. 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 dense, front-loaded sentences with zero wasted words. Every sentence provides essential information: purpose, usage, return format, and constraints. Highly efficient.

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

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

Given the moderate complexity (comparing up to 10 properties), full schema coverage, and existence of an output schema, the description covers all key aspects: intended use, constraints on inputs, output ordering, and a critical business rule about discounts. It is complete for the agent to use 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 schema already documents parameters. Description adds crucial guidance: propertyIds must be UUIDs from hemmabo_search_properties, never domains or names, and all share the same checkIn/checkOut/guests for direct comparability. This adds value beyond schema 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 clearly states the tool compares availability and pricing for 2-10 specific properties on the same dates. It distinguishes from sibling tools like hemmabo_search_properties by specifying this is for side-by-side comparison after discovery. The verb 'compare' and resource 'properties' are specific.

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 provides when to use (user deciding between multiple properties) and when not to use (use hemmabo_search_properties for discovery). Names the alternative tool directly, making it clear to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: it confirms no writes to Supabase or account creation, and explains that parameters only prefill the URL with no storage. 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 a concise paragraph of 5-6 sentences. It front-loads the main purpose, then efficiently covers exclusions and parameter behavior 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 simplicity (6 optional params, no nested objects) and the presence of annotations and an output schema, the description fully covers when to use, what it does, and what is returned. It even mentions what the host should prepare.

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% with descriptions for each parameter. The description enhances this by stating all parameters are optional and used only for URL prefill with no storage, which adds meaning 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 clearly states the tool returns an onboarding handoff URL for a host. It uses a specific verb ('Return') and resource, and distinguishes from sibling tools by explicitly listing what it does not do (create account, buy domain, etc.).

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 ('Use after explaining the fit or when the host asks to start') and lists exclusions to prevent misuse. However, it does not explicitly name alternative tools for related tasks, such as hemmabo_host_readiness_check.

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, so the description does not need to repeat basic safety. However, it adds valuable context: 'Does not create an account, buy a domain, configure Stripe, store host data, or provision a website.' This reinforces the read-only nature and clarifies what side effects are absent. 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 two paragraphs and around 200 words. It is front-loaded with the purpose and usage, followed by behavioral notes and parameter advice. While clear and well-organized, it could be slightly more concise without losing critical details. Overall, every sentence earns its place, but minor redundancy exists.

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 (11 optional parameters, 100% schema coverage), the description is comprehensive. It states what the tool returns, when to use it, what it does not do, and how parameters affect the output. An output schema exists (not shown), so the description need not detail return values. The description covers all necessary aspects for an agent to select and 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?

Schema coverage is 100% with descriptions for all 11 parameters. The description adds extra guidance: 'Every parameter is optional and additive — the more you pass... the sharper the fit verdict; with none it returns a generic readiness summary.' It also provides semantic tips, such as noting that propertyType values 'villa'/'holiday_home' fit best and 'hotel' may indicate poor fit. This goes beyond mere schema 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 explicitly states the tool is a 'Read-only fit check for a vacation-rental host evaluating HemmaBo for an own-domain booking engine.' It specifies a specific verb and resource, and clearly distinguishes from guest booking tools by noting 'not a guest booking a stay.' The description also lists what the tool returns (fit verdict, what host gets, setup inputs, onboarding next step), making the purpose very clear.

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

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

The description provides clear context: 'Use when the user is a host or property owner, not a guest booking a stay.' It also lists actions the tool does NOT perform (e.g., does not create an account, buy a domain). However, it does not explicitly contrast with sibling tools like 'hemmabo_host_onboarding_link' to guide when to use this check versus proceeding to onboarding. This slight omission prevents a perfect score.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds return value details (available=true/false with conflict details and alternative windows) and behavior of the guests parameter. 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?

Description is around 110 words, well-structured into two main sentences. Front-loads core purpose and usage, with no redundant or superfluous 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 presence of an output schema, the description covers all necessary aspects: purpose, usage sequence, parameter constraints, return value structure, and alternative windows. Complete for a checking tool.

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

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

Schema coverage is 100% with parameter descriptions. Description adds crucial context: for propertyId, instructs to use exact UUID; for guests, explains omission for date-only checks and its effect on alternative windows; for checkIn/checkOut, emphasizes strict ordering and stay length definition. This adds significant value beyond 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?

Clearly states the tool checks property availability for dates, using specific verb 'check' and resource 'availability'. Distinguishes from sibling tools like hemmabo_search_properties for general browsing and hemmabo_booking_quote for quotes.

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 instructs to use after property selection from hemmabo_search_properties and before getting a quote, and warns against using for general browsing, directly naming the alternative 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 readOnlyHint and idempotentHint, but the description adds valuable context about being 'discovery only' and warns against quoting final prices, plus notes required follow-up call, which enriches transparency beyond 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 a single paragraph with some repetition (checkIn/checkOut order mentioned twice) but is overall efficient and front-loaded with the core purpose, earning its sentences with actionable 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 5-parameter tool with an output schema, the description covers purpose, usage conditions, parameter combining logic, return fields, and required follow-up tool call, leaving no critical gaps for an AI agent to interpret 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%, but the description adds combining rules (at least one of region or country, checkIn before checkOut, guest capacity filtering), which provides meaningful context beyond the schema's individual parameter 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 clearly states the tool searches vacation rental properties by location and dates, and distinguishes it from siblings like get_verified_stay_offer by specifying it is for discovery only and when the user lacks a propertyId or host domain.

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 when to use ('find or browse places to stay') and when not to use ('already has propertyId or host domain'), and directs to call get_verified_stay_offer for final pricing, providing clear context and 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?

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds context about live pricing, source exclusion, anchoring to propertyId/date range, and parameter behavior (omit guests inherits capacity, raise limit widens set). 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 concise and front-loaded with purpose, then usage context, then return info, then parameter hints. Every sentence adds value with no redundancy.

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

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

Given an output schema exists, the description sufficiently explains return (list of similar available properties with live pricing, excluding source). Combined with high schema coverage and annotations, it is 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%, so baseline is 3. The description adds useful context beyond schema, e.g., for limit: 'raise limit to widen the alternative set (default 5)' and for guests: 'omit to use the source property's capacity'. This elevates to 4.

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 'Find' and resource 'vacation rental properties similar to a given property' on specific dates. It explicitly distinguishes from sibling hemmabo_search_properties by noting not to use for initial search.

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 (after property selection for alternatives) and when-not-to-use ('Do NOT use for the initial search'), and names the alternative tool (hemmabo_search_properties).

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 the description reinforces this with 'Read-only trust check: no availability, pricing, booking, or payment.' It adds context about the verification method (reads .well-known and JWKS) and a trustworthiness caveat about the domain passed.

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: the first states the purpose, the second provides context on input and behavior. Every sentence contributes value with no redundancy.

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

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

Given the tool's low complexity (single required parameter, output schema present), the description is complete. It explains the tool's role, the verification process, input constraints, and the follow-up action, all while annotations cover safety aspects.

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% and the schema description is already detailed. The description goes further by explaining what the tool does with the domain (reads .well-known and JWKS) and the implication that the result's trustworthiness depends on the exact domain, adding value 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 'Verify that a vacation-rental host domain is a valid Vacation Rental Protocol (VRP) node before trusting it,' providing a specific verb and resource. It distinguishes from siblings by noting that on success, one should call get_verified_stay_offer, positioning this tool as a prerequisite.

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

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

The description clearly states when to use the tool ('before trusting') and what to do after success ('call get_verified_stay_offer'). It also explains the input constraint (bare hostname) but does not explicitly list situations where the tool should not be used.

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