HemmaBo Host Booking Engine

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 specific behavioral details: Verifies Ed25519 JWS against domain JWKS, is read-only, and provides post-call instructions. 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?

Four sentences, front-loaded with the most important information, no redundant text. Every sentence adds value.

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 (JWS verification, host domain interaction) and the presence of annotations and output schema, the description fully explains what the tool does, when to use it, and constraints.

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 good parameter descriptions. The description does not add new per-parameter semantics but provides context for the overall use of parameters (e.g., 'exact dates and guest count'). Baseline 3 is appropriate.

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

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

The description clearly states the action ('Fetch, verify, and render') and the resource ('live host-domain signed VRP stay offer'). It distinguishes from sibling tools like booking and search by emphasizing verification and read-only nature.

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 tells when to call ('after search returns a host domain, always before quoting final price or a booking link') and what not to do ('must not lock a quote, create a booking...'). Provides clear alternatives by directing to direct_booking_url.

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 as destructive and idempotent. The description adds: 'Destructive and idempotent: cancelling an already-cancelled booking returns the same status.' It also mentions authorization requirements and rate limiting. 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 four sentences, front-loaded with the main purpose, followed by usage, behavioral traits, and auth/rate limits. Every sentence provides value with 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?

Given the tool's complexity (2 parameters, output schema exists, rich annotations, many siblings), the description covers purpose, usage, behavioral traits, auth, and rate limits. It is complete and contextually adequate.

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 is 3. The description adds minimal extra meaning beyond the schema descriptions (e.g., tying 'reason' to human-readable for host). It does not significantly enhance parameter understanding.

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 'Cancel a confirmed booking and process the Stripe refund per host cancellation policy.' It specifies the verb (cancel), resource (confirmed booking), and action (process refund). It also distinguishes from siblings by explicitly stating not to use for pending/unpaid bookings.

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: 'Use when the guest explicitly requests cancellation.' and 'Do not use for pending/unpaid bookings — those expire automatically.' This provides clear when-to-use and when-not-to-use, with implied 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?

Discloses behavior beyond annotations: 'Creates a pending booking and Stripe session server-side; not idempotent — check hemmabo_booking_status before retrying. Rate-limited per token.' Annotations only indicate readOnlyHint=false and idempotentHint=false; description adds concrete details.

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

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

Four sentences, each adding unique value: purpose, when to use, authentication, behavioral traits. No redundancy. Front-loaded with the core action.

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 10 parameters, 6 required, and an output schema, the description covers the fallback flow, error avoidance (checking status), rate limits, and alternative routing. Complete for safe agent 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?

Schema description coverage is 100%, so baseline is 3. The description adds no extra parameter-level semantics beyond the schema's own descriptions. It does provide context for quoteId (from negotiate) but not sufficient to raise the score.

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 'Create a fallback non-VRP booking and return a host-configured Stripe checkout URL.' It specifies the verb (create, return) and resource (booking, checkout URL). It distinguishes from sibling tool get_verified_stay_offer by explicitly stating when to use each.

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 explicit usage context: 'Use only after explicit user confirmation when no signed VRP direct_booking_url is available. When get_verified_stay_offer returns a signed direct_booking_url, route the guest there instead.' Also mentions authentication and rate limits.

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?

Discloses that it writes a pending booking server-side, is not idempotent, and is rate-limited per token. These details go beyond annotations (readOnlyHint=false, idempotentHint=false) to provide actionable behavioral 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?

Five sentences front-loaded with the core purpose, followed by usage conditions, auth, and behavioral notes. No wasted words; every sentence adds value.

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

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

Covers purpose, usage, behavioral traits, auth requirements, retry advice, rate limiting, and links to sibling tools (search, status). Very complete for a complex tool with 7 parameters.

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. The description adds minimal parameter-level detail beyond referencing propertyId from search; a 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 clearly states the tool's purpose: 'Create a pending direct booking without online payment for configured non-VRP fallback deployments.' It specifies the action (create), resource (pending direct booking), and context (non-VRP fallback). It distinguishes from siblings by mentioning alternative routing for signed VRP offers.

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 explicit usage conditions: after user confirmation, with a propertyId from search, only when no signed VRP direct_booking_url is available. It also advises against using for signed VRP offers and recommends checking status before retrying on timeout.

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 discloses that it writes a short-lived quote snapshot server-side, is rate-limited per token, requires Bearer token authorization, and locks the price for 15 minutes. These details go beyond annotations (which only indicate non-readonly and non-destructive) and provide crucial behavioral 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 concise with three sentences covering purpose, usage conditions, and constraints. It is front-loaded with the main function and efficiently includes all critical information without 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 complexity of a binding quote with a timeout, the description covers authentication, rate limiting, alternative tool, and key constraints (15-minute lock, non-VRP scope). Annotations and output schema exist, and the description adequately rounds out the context needed for correct tool selection and 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?

Schema description coverage is 100%, so the schema already documents each parameter thoroughly. The description adds minimal extra information about parameters (e.g., propertyId source). While useful, it does not significantly enhance understanding beyond the schema, warranting a baseline score of 3.

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, specifically for non-VRP fallback checkout deployments. It distinguishes itself from get_verified_stay_offer, making the purpose 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?

Explicit usage conditions are provided: 'Use only when no signed direct_booking_url is available and the user explicitly asks to lock a price.' It also lists what not to use it for and points to the alternative tool get_verified_stay_offer, giving clear guidance.

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

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

Annotations already provide readOnlyHint and idempotentHint; description adds useful context about return structure (host-source total, per-night breakdown, package pricing) and currency format (integers, local currency). 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?

Four sentences front-load purpose, then usage, then return contents, then currency. Each sentence earns its place 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 output schema exists and all parameters are documented, description covers usage context, return summary, and currency. No gaps identified; it fully supports agent decision-making.

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. Description does not add parameter-specific details beyond schema; the general context about availability is indirectly related but not directly about parameter meaning.

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 verb 'Get' and resource 'detailed pricing quote' with explicit scope: specific property, dates, guest count. Distinguishes from siblings like hemmabo_search_availability by positioning it after availability confirmation.

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') with rationale that quote may be invalid. Implicitly contrasts with 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?

Disclosure beyond annotations includes 'automatic repricing and Stripe charge/refund', 'Destructive write', 'Requires Authorization: Bearer token', and 'Rate-limited per token'. 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?

Four sentences, front-loaded with action, each sentence adds distinct value: purpose, usage, auth, and behavioral traits. 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 4 parameters (3 required, 1 optional), full usage guidelines, behavioral traits, and auth requirements, and an existing output schema, the description is complete for agent understanding.

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. Description does not add significant new meaning beyond the schema; it mentions 'reason' is optional with example, but the schema already provides adequate 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 reschedules confirmed or pending bookings to new dates with automatic repricing and Stripe charge/refund. It distinguishes from siblings like hemmabo_booking_cancel by specifying it's for date changes on existing bookings.

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 'Use when the guest wants to change dates on an existing booking' and 'Do not use if cancelled or if a protocol compatibility client reports completed' with instruction to check hemmabo_booking_status first.

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 behavioral context beyond annotations: authorization requirements (Bearer token), read-only nature with PII return, and rate limits. Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false; description complements them with actionable details.

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

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

Three concise sentences: first defines purpose, second usage, third behavioral details. No redundant words. Front-loaded with core action.

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 one required parameter, annotations, and output schema existence, the description covers purpose, usage, auth, read-only, PII, and rate limits. No gaps apparent. Complete for a read-only lookup 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%, so baseline is 3. The description adds value by specifying the UUID format, linking to other tools (checkout, create), and clarifying it's required for lookup/cancel/reschedule, which is richer than the schema alone.

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

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

The description clearly states 'Retrieve current status and full details of an existing booking by reservationId,' with a specific verb (retrieve) and resource. It distinguishes from sibling tools like create, cancel, reschedule.

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 recommends use 'to confirm checkout/create succeeded or before cancel/reschedule,' providing clear context for when to invoke the tool. Does not explicitly state when not to use, but the purpose is well-defined.

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. Description adds context: returns one entry per propertyId, sorted by cheapest first with unavailable last, and warns against presenting discounts. No contradiction; good supplementation.

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

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

Two sentences plus a terse note on ordering and presentation. Every sentence serves a purpose; no redundancy. Front-loaded with core purpose and usage restriction.

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 output schema present, description does not need to detail return values. It covers ordering, unavailable items, and presentation guidance. Sufficient for an agent to understand capabilities and constraints.

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 has 100% coverage so baseline is 3. Description adds value by specifying that propertyIds must come from hemmabo_search_properties and not be host domains, etc., which is not in schema. For dates, it reinforces 'same dates' concept. Good extra guidance.

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 'Compare availability and pricing for 2-10 specific properties on the same dates', using a specific verb and resource. It explicitly distinguishes from siblings by advising 'Do NOT use for discovery - use hemmabo_search_properties first'.

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 explicit when-to-use ('when the user is deciding between multiple properties'), when-not-to-use ('Do NOT use for discovery'), and an alternative (hemmabo_search_properties). Also details output ordering and a warning about guest-facing copy.

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. The description reinforces this with a specific list of actions it does not perform and details what it returns, adding valuable context beyond 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 two sentences, front-loading the purpose and usage, then listing exclusions and return value in the second sentence. Every sentence adds value without 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 covers inputs, behavior, and outputs sufficiently. It addresses the tool's scope, limits, and usage context, making it self-contained for an AI 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?

All six parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description does not add additional meaning to the parameters, but it provides overall context that indirectly aids understanding.

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 specifies a clear action ('Return a safe HemmaBo onboarding handoff URL') and target audience ('vacation-rental host who wants an own-domain booking engine'), distinguishing it from sibling tools that handle bookings, searches, or other 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 explicitly states when to use the tool ('Use after explaining the fit or when the host asks to start') and what it does not do (e.g., does not create accounts, buy domains), preventing misuse.

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?

Disclosures align with annotations (readOnlyHint: true, destructiveHint: false) and detail that it does not create accounts, configure Stripe, write to Supabase, collect PII, or provision websites, adding significant behavioral context beyond 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 well-structured and front-loaded with purpose. It is somewhat verbose but every sentence adds value, explaining scope, outcomes, and exclusions without repetition.

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

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

Given the high parameter count (11, all optional), 100% schema coverage, and existence of an output schema, the description fully explains the tool's purpose, what it returns, and non-behaviors, making it complete for a readiness-check 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 description coverage is 100%, so the schema already documents all 11 parameters well. The description adds minor context (e.g., domain validation, use of city for prefill) but does not significantly surpass the schema's inherent clarity, justifying a baseline of 3.

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 is a 'Read-only fit check for vacation-rental hosts' evaluating HemmaBo for own-domain booking, using specific verbs and distinguishing it from guest-facing tools. It explicitly differentiates from siblings like booking or search 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?

Explicitly tells when to use ('when the user is a host/property owner evaluating HemmaBo, not when a guest wants to book a stay') and lists what it does and does not do, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that returns available=true/false with conflict details and same-month alternative date windows, providing behavioral context 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?

Three sentences, front-loaded with purpose, then usage guidance, then return information. No redundant or unnecessary 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 straightforward nature of an availability check, the description is complete: it explains what it does, when to use it, what it returns, and parameter behavior. Output schema exists to document return values.

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. Description adds meaning beyond schema by explaining that when 'guests' is provided, alternative date windows include live host-source totals for that guest count.

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 the tool checks property availability for specific dates, with a specific verb ('Check') and resource ('availability of a property'). It distinguishes from sibling tools like hemmabo_search_properties (general browsing) and others.

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 selecting a property from hemmabo_search_properties and before getting a quote. Also states when not to use (general browsing) and directs to the alternative (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, destructiveHint=false, and idempotentHint=true. The description adds complementary behavioral detail: it is 'Discovery only' and warns against quoting final prices from search results alone. No contradiction; the description adds value beyond the annotated safety profile.

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

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

Three sentences, no filler. Front-loaded with purpose, then usage guidelines, then exclusions and return information. Every sentence earns its place. Efficient and clear.

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 5 parameters, an output schema, and many siblings, the description covers all necessary aspects: what it does, when to use (and not), what it returns, and the next required action. The presence of an output schema means return values need not be detailed further. No gaps identified.

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 has 100% description coverage, so baseline is 3. The description adds meaning by stating the tool returns 'live availability, host-source pricing, and capacity,' which aligns with how guests, checkIn, and checkOut parameters are used for filtering and pricing. This helps the agent understand the purpose of those parameters beyond their schema definitions.

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?

Starts with a clear verb+resource: 'Search available vacation rental properties by location and travel dates.' Distinguishes from siblings by explicitly calling out 'Discovery only' and instructing to call get_verified_stay_offer next. Also states when NOT to use ('Do NOT use when the user already has a propertyId or host domain'). Highly precise.

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 explicit usage context: 'Use when the user wants to find or browse places to stay.' Includes a clear exclusion rule and a required follow-up action ('call get_verified_stay_offer...'). No ambiguity about when to select this tool over 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns a list of similar available properties with live pricing, but does not reveal additional behavioral traits beyond what is implied by 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 sentences, front-loaded with purpose and usage, and every sentence contributes essential information without unnecessary detail.

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, annotations, and a well-described input schema, the description covers when to use, what it does, and key constraints (excludes source property). No gaps are apparent.

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 schema already provides detailed parameter information. The description adds minimal extra meaning (e.g., 'omit to use server default 5'), but does not significantly enhance understanding 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 finds similar vacation rental properties to a given property on specific dates, and explicitly distinguishes from the sibling tool hemmabo_search_properties by stating 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?

Provides explicit when-to-use (after user selects a property and wants alternatives) and when-not-to-use (initial search, use hemmabo_search_properties), and describes the output (list of similar available properties with live pricing, excluding source).

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds specific actions (reads .well-known and JWKS) and clarifies the read-only nature with explicit exclusions. 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?

Three sentences, front-loaded with purpose, no redundant words. Each sentence adds essential 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?

Covers purpose, actions, constraints, and follow-up. Output schema exists, so return values are covered elsewhere. Complete for a verification tool with strong annotations.

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

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

Schema coverage is 100% with a good description for the domain parameter. The tool description adds high-level context but no new parameter semantics 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?

Clearly states the action (verify), resource (vacation-rental host domain), and scope (trust check). Distinguishes from siblings by noting it reads .well-known and JWKS, and explicitly says it does not handle booking/pricing.

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 'before trusting it' and 'no availability, pricing, booking, or payment', and advises to call get_verified_stay_offer on success. Provides both context for use and a direct alternative/follow-up.

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