chucho — Book Direct

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds only the ambiguity-trigger context and nothing about return format or rate limits, which the output schema partly handles anyway.

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 short sentences with no waste; the positive use case is front-loaded and the exclusion follows. It earns its length, though the opening phrase is fuzzier than it needs to be.

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

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

For a single-parameter read-only discovery tool with an output schema and covering annotations, the description is roughly adequate. However, 'coverage' and 'supported exact place/area keys' are left ambiguous, so an agent still has to guess what it actually gets back.

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 0% and the single 'locale' parameter is never mentioned in the description. The enum values (en/es) are somewhat self-explanatory, but the description does nothing to compensate for the missing 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 conveys that this returns filter/coverage data and supported place/area keys, but 'Discover current coverage' is vague about what is actually being covered or returned. A specific verb+resource is only loosely present, so an agent gets the gist but not a crisp statement of purpose.

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

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

It gives an explicit trigger ('when the destination is ambiguous') and an explicit when-not ('Not needed for searches with city, region or country text'). It stops short of naming an alternative sibling tool to use instead, but the selection condition is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is covered. The description adds genuine domain context beyond that: only approved listings are visible, missing/withdrawn homes return nothing, and the payload excludes private guides, live prices, and any booking authority.

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, front-loaded with the core action and followed by compact scope exclusions. No filler, though the exclusion list is dense enough to warrant a slightly tighter phrasing.

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

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

An output schema exists, so return shape need not be described, and annotations carry the safety profile. The description covers data-scope limitations well; the remaining gap is the undocumented id format and locale behavior, which leaves an agent guessing about identifier semantics.

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 0% and neither parameter is documented in the schema beyond type and constraints. The phrase 'a specific home' only loosely implies id is a home identifier, and locale (with its en/es enum and default) is never explained in the description, so the coverage gap is largely uncompensated.

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

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

States a specific verb (Read) and resource (current approved details for a specific home), which distinguishes a single-entity lookup from siblings like search_properties and render_properties. It stops short of explicitly naming the sibling it competes with, so differentiation is inferred rather than stated.

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?

Usage is implied: you call this when you need details for one already-known home. The negative condition ('Missing or withdrawn homes are unavailable') gives useful scope, but there is no explicit when-to-use-this-vs-search_properties routing and no prerequisites mentioned.

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 the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely new semantics: the returned areas 'are public locality centers, never property coordinates', which tells the agent what the data actually represents and prevents misuse as coordinates.

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

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

Three tight sentences, front-loaded with purpose, then the usage mechanic, then the semantic caveat and fallback. No filler and every clause carries 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 an output schema present, the description needn't explain return values, and annotations cover safety. It covers purpose, routing to alternatives, and the nature of the returned data; the only gap is the undocumented locale parameter.

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 50% – the q parameter is fully documented in the schema while locale has no description anywhere. The description reinforces q's semantics (town, region or country search) and the empty-list behavior, but adds nothing about locale, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Find named public areas with published chucho homes') and distinguishes itself from siblings: it handles unmapped homes via search_properties and feeds 'nearby search' via the returned area key. An agent can tell it apart from search_properties and search_nearby_properties without opening the schema.

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

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

Gives clear context ('Search a destination's town, region or country') and names the alternative with its selecting condition ('unmapped homes remain searchable with search_properties'). It also says to reuse the returned area key for nearby search. No explicit when-not-to-use beyond those conditions, so not quite a 5.

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

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

Annotations only declare the generic mutation profile (readOnly=false, destructive=false, openWorld=false, idempotent=false). The description adds material behavior the annotations cannot convey: strict data-minimization rules ('Never send conversation text, contacts or URLs'), the accepted input envelope, and a non-booking disclaimer that bounds the side effect.

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

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

Three tight sentences with zero filler. The scope restriction is front-loaded, and the two trailing sentences each carry a distinct safety constraint (allowed payload vs. forbidden content).

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

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

An output schema exists, so return values need no explanation, and the description covers all four required parameters plus the privacy guardrails. The only gap is retry/idempotency behavior, which matters because annotations mark the call non-idempotent, but this is minor.

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 0%, so the description carries the burden, and it does map all four required fields to meaning: a 'public property ID', a 'temporary random session UUID', 'event type' and 'language'. It adds the session-UUID randomness expectation that the schema's format alone does not explain, though it does not restate the enum values (which the schema does supply).

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

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

States a specific verb+resource ('record a property view or successful outbound host-link action') and narrows it to 'the property-card UI only'. This cleanly separates it from the read-only siblings (get_property, search_properties, render_properties), which an agent can distinguish without opening any schema.

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

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

Gives a clear context gate ('For the property-card UI only') and an explicit exclusion ('This does not book a stay'), which prevents misuse as a booking or general-analytics call. It does not, however, name any alternative tool or state what to do when the event is not a card view/host-link click.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld. The description adds genuine behavioral context beyond them: it 'rechecks publication' and warns that prices and availability live on the host website, so the agent won't expect pricing here.

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?

Front-loaded with the use case, then mechanics, then a constraint. Four tight sentences, though the 'do not repeat in prose' instruction reads as prompt guidance rather than tool semantics.

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

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

With an output schema present, return values needn't be described, and the description covers when-to-use, what renders, and the publication recheck. The undocumented locale parameter is the only notable gap.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains ids as 'one to six matching IDs' from search_properties, matching the 1-6 bounds, but adds nothing about the locale enum (en/es). Partial compensation only.

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

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

States a specific verb (show/render) and resource (homes/IDs already found by search_properties) as cards with Details and host booking links. An agent can distinguish this from search_properties (which finds them) and get_property (singular) without opening any schema.

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

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

Explicit trigger: 'Use this when the traveler wants photos or a comparison of homes already found by search_properties,' which names the upstream sibling and the condition selecting this tool. It also adds a constraint ('Do not repeat the full cards in prose'), but gives no explicit when-not or alternative to get_property.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: distances are approximate straight-line between public locality centers rather than home locations or driving times, only published homes are returned, and there are no live rates or availability.

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 short sentences, each load-bearing: the core purpose first, then the distance caveat, then the area-key discipline, then the data-availability limit, then the display instruction. No filler or restated schema.

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

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

An output schema exists so return values need no explanation, and the description still adds the render-as-cards instruction and the two most likely failure modes (invented keys, misread distances). Nothing material is missing for a 10-param 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 only 50% schema description coverage, the description must carry weight, and it does for the most error-prone inputs: the nearArea key must be exact and never invented, and the distance semantics for radiusKm are spelled out. It does not address page, locale, minBathrooms, or how the feature enum relates to amenities, so the compensation is partial.

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

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

States a specific verb (find), resource (published homes), and a precise scoping mechanism (near an exact get_stay_areas key), plus the filter dimensions. This near-area framing implicitly distinguishes it from the sibling search_properties, which is not anchored to a stay-area key.

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

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

Gives clear procedural guidance: derive the area from destination evidence or ask the traveler, and never invent a key; also tells the agent to render results as cards. It stops short of explicitly naming search_properties as the alternative when an area key is unavailable, so the when-not is only implied.

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

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

Annotations already cover read-only/idempotent/non-destructive safety, and the description adds scope behavior beyond that: it auto-shows photos and booking buttons, returns only approved facts, and excludes rates/availability. It does not discuss pagination despite a page param, so it stops short of full behavioral coverage.

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?

Purpose and the get_filters alternative are front-loaded, and every sentence carries usable content. The semicolon-chained run-ons and triple synonym opener add some density without waste.

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?

An output schema exists, so return-value detail is not needed, and the description still bounds the result set (approved facts, no rates). For a 13-param tool it leaves several filters undocumented, but the search dimensions and usage envelope an agent needs are present.

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

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

Schema coverage is only 38% across 13 params. The description conceptually covers q/city/region/country/guests/pool/amenities and hints at place keys, but leaves page, locale, feature, minBedrooms and minBathrooms unexplained in either place, so it only partially compensates for the gap.

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

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

States a concrete verb and resource ('Find vacation rentals, holiday homes and places to stay') and explicitly names the sibling it is not (get_filters). The synonym stack broadens keyword recall but makes the resource description slightly generic rather than sharply 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?

Gives explicit routing ('use get_filters only for ambiguous destinations or exact place/area keys') and a hard negative constraint ('Never ask for check-in/check-out dates... ignore offered dates/budget'). An agent knows both when to call this and when not to.

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