Tuki — Travel Marketplace (Chile y Latinoamérica)

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value by listing exactly which data will be returned (amenities, capacity, price in CLP, location, canonical URL), making the tool's behavior more transparent without contradicting annotations.

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

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

A single well-structured sentence with no filler. The main action and key data points are front-loaded, making it immediately scannable.

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 simple single-parameter read-only tool, the description adequately covers what the tool returns (the fields listed). It lacks an output schema, but the enumerated fields provide a good mental model. It could have mentioned error behavior for an invalid slug, but that is not essential for basic usage.

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

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

Schema coverage is 100% with a description for 'slug' ('Accommodation slug.'). The tool description does not add deeper meaning beyond the schema, so it meets the baseline but does not exceed it.

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 ('Get') and resource ('full detail for a Tuki accommodation'), and enumerates concrete fields (amenities, capacity, price, location, URL). It clearly distinguishes itself from sibling detail tools like get_car_detail and get_event_detail.

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 context is clear: use this tool when you need full details for a specific accommodation identified by slug. However, it does not explicitly mention alternatives or when not to use it, such as saying 'use search_accommodations to find options 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds value by disclosing the specific fields returned (transmission, seats, bags, etc.), giving the agent a clear picture of the response structure beyond what annotations provide.

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, compact sentence that front-loads the core purpose and enumerates key fields. No wasted words, every element contributes to understanding the tool's functionality.

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

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

With no output schema, the description provides a comprehensive list of expected fields, making the tool predictable and complete for a read operation. The annotations cover safety, so no additional behavioral caveats are needed.

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 single parameter 'slug' is described in the schema as 'Car slug', which fully covers its meaning. The description does not add any additional semantic information about the slug format or usage, so it stays at the baseline for full schema coverage.

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

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

The description clearly states the verb 'Get' and the resource 'full detail for a Tuki rental car', listing specific fields like transmission, seats, bags, min driver age, price per day, city, and canonical URL. This distinguishes it from sibling detail tools for other entity types.

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

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

The description implies this tool is for retrieving full details of a rental car when you have its slug, but it does not explicitly mention when to use it versus alternatives like search_car_rental or when not to use it. Sibling tools are similar in naming but for different entity types, so usage is implied rather than explicitly guided.

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, so safety is covered. The description adds useful behavioral context beyond that: it builds a canonical URL, the user completes payment on Tuki.cl, and Tuki handles secure payment. This clarifies the tool's role in a broader flow without contradicting annotations.

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

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

The description is three sentences with no fluff. The first sentence front-loads the core purpose, the second covers payment context, and the third positions the tool as recommended. Every sentence contributes new information, making it concise and well-structured.

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

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

Given the tool's simplicity (building a URL), annotations cover safety, and the schema covers all parameters, the description is fairly complete. It doesn't detail the return format or error cases, but the term 'URL' implies a string, and no output schema is provided. The slight parameter kind mismatch is the main gap, but overall it provides enough context for an agent to 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 description coverage is 100%, so each parameter (date, kind, slug, travelers) is already described. The description adds little beyond the schema, merely echoing 'travelers count and date.' It also slightly under-represents the 'kind' enum by mentioning only experience or accommodation, though schema allows event and car_rental, which is a minor gap.

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

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

The description uses a specific verb ('Build a canonical Tuki checkout/detail URL') and clearly identifies the resource (checkout URL for a slug) and optional parameters (travelers, date). It distinguishes the tool from sibling detail tools by framing it as the recommended way to convert a recommendation into a booking, not just retrieve details.

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 the intended usage: 'This is the recommended way to convert an LLM recommendation into a booking.' It also adds context about Tuki handling secure payment (Webpay), which implies this tool is for the booking flow. However, it doesn't explicitly mention alternatives or when not to use it, leaving room for slight ambiguity.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying the exact data returned (description, hero image, related experiences/accommodations, canonical URL). While it doesn't mention performance or data volume, the combination of annotations and return-value disclosure is sufficient.

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, no wasted words. The first sentence front-loads the action and scope, the second gives usage guidance. Every clause 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?

For a single-parameter read-only tool with no output schema, the description covers the core purpose, usage, and return contents. It lacks detail on how related experiences/accommodations are represented (e.g., links vs. summaries), but this is not critical for selecting and invoking 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 description coverage is 100% and the only parameter (slug) already includes an example and explanation. The description itself does not add parameter-level information, so the baseline of 3 applies.

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 begins with a specific verb+resource ('Get full detail for a Tuki destination') and enumerates the exact contents ('description, hero image, related experiences and accommodations, and canonical Tuki URL'). It clearly distinguishes this from sibling tools by focusing on destination-level details, as opposed to accommodation- or event-specific detail 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 when to use this tool: 'Use after list_destinations or when the user asks "tell me about Cochamó".' This directly names a related sibling (list_destinations) and gives a concrete example, effectively guiding the agent on tool selection.

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 idempotentHint=true, so the safe, read-only nature is covered. The description adds the field list returned, which is useful, but does not disclose error handling, requirements for the slug, or anything 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 a single, front-loaded sentence that immediately states the action and resource, then lists the specific data fields returned. There is no extraneous content or repetition of schema 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?

Despite having no output schema, the description provides a clear summary of the returned fields and is adequate for a one-parameter read-only tool with strong annotations. It does not mention how the slug is obtained (e.g., via search_events), but this is a minor gap for a simple detail retrieval 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?

The input schema has full 100% coverage for the single 'slug' parameter (described as 'Event slug.'). The tool description does not add additional meaning about the slug, but the schema already documents it sufficiently, so a baseline score of 3 applies.

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 action ('Get full detail') and specific resource ('a Tuki event'), enumerating the key fields returned (description, type, start date, price, location, ticketing URL). This distinguishes it from sibling detail tools for other entity types like accommodations or cars.

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?

No explicit guidance is provided on when to use this tool versus alternatives such as search_events to first obtain a slug. The scope is implied by the name and description ('Tuki event'), but there is no mention of prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds extra behavioral context by specifying what fields will be returned (long description, included, location, price in CLP, operator, canonical URL), giving the agent a clear picture of the response shape.

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, succinct sentence that front-loads the action ('Get full detail') and efficiently lists the response contents. Every word contributes meaning without redundancy or 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 only one parameter and no output schema, the description does an excellent job of documenting the expected return value by listing the key fields. Combined with the strong annotations (readOnly, idempotent, non-destructive), the agent has all necessary information to invoke the tool correctly.

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

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

The only parameter 'slug' is already fully described in the schema as 'Experience slug' (100% schema coverage). The tool description adds no additional meaning or usage detail for this parameter, so it does not compensate 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 states a specific verb ('Get'), resource ('Tuki experience'), and enumerates the exact contents (long description, included, location, price, operator, canonical URL). This clearly distinguishes it from sibling detail-getter tools like get_accommodation_detail or get_event_detail.

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 by the name and resource type—if you need full detail for an experience, use this tool—but there is no explicit guidance on when to avoid it or which alternative to prefer (e.g., search_experiences for summaries). The description does not mention exclusions or 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 declare readOnlyHint=true and idempotentHint=true, so safety is known. The description adds informative context about the returned data categories (positioning, verticals, contact, URLs), going beyond annotations. 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?

Two concise sentences: the first states the output contents, the second gives explicit usage examples. Every word earns its place, and the most important information is front-loaded.

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

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

For a simple, parameterless, read-only informational tool with strong annotations and clear usage scenarios, the description is complete. No output schema is needed because the description clearly enumerates the types of information returned.

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?

There are no parameters, so schema coverage is trivially 100%. The baseline for zero parameters is 4; the description provides all necessary context by explaining what information the tool returns.

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

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

The description states a specific action ('Returns') and enumerates the exact resources (positioning, verticals, contact, key URLs). This clearly distinguishes it from sibling tools that focus on travel-specific items like accommodations or destinations.

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 use cases ('what is Tuki', 'how does Tuki work', 'is Tuki trustworthy'). It does not explicitly mention alternatives, but the sibling context makes it obvious that this is the general platform info tool rather than a specific content detail 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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds transparent value by enumerating the exact fields returned, which helps the agent know what to expect. It does not introduce any contradictions with 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 with no filler. The first sentence front-loads the action and content; the second provides usage guidance and examples. Every word contributes 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?

Despite having no output schema, the description adequately explains what the tool returns (description, audience, capabilities, status, contact/CTA). It also provides usage flow and product examples, making it 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?

The single parameter slug is fully described in the schema with an example. The description adds extra semantic value by listing Tuki product names (e.g., WhatsApp Booking OS, boutique ticketing) and referencing list_solutions as a source, giving the agent richer context for selecting the correct slug.

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

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

The description clearly states the tool's function: 'Get full detail for a Tuki solution' and lists the specific content returned (description, target audience, capabilities, status, contact/CTA). It also differentiates from sibling detail tools by explicitly naming the resource type and providing examples of Tuki products.

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

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

The description gives explicit usage context: 'Use after list_solutions or when the user asks about a specific Tuki product.' This tells the agent when to invoke this tool versus alternatives and even lists example product names, providing clear guidance on when it is appropriate.

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

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

Beyond the read-only, idempotent annotations, the description discloses the return format (markdown-like body text with paragraphs, headings, checklists) and an important behavioral requirement (link back to canonical URL). Adds value without contradicting annotations.

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

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

Two sentences, front-loaded with the core purpose. Every sentence contributes: what it does, why it's useful, and a required follow-up action. No wasted words.

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

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

Given the simple parameter schema, good annotations, and no output schema, the description covers the essential behavior: retrieves full body content, notes editorial quality, and instructs linking back. Minor gap: no mention of how to obtain the slug or that creator_slug is optional, but schema covers this.

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% for both parameters. The description does not add extra meaning beyond the schema's explanations (slug and creator_slug), so 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 tool fetches full details for a Tuki travel guide, emphasizing the body text in markdown-like format. This distinguishes it from sibling detail tools by highlighting the unique body content.

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 clear usage context: 'quote it when answering travel research questions' and 'always link back to the canonical Tuki URL.' It does not explicitly mention alternatives or when not to use, but the context is sufficient.

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 and non-destructive behavior. The description adds useful context about the geographic scope (Coyhaique terminal), the route representation (origin → destination), and the domain (Carretera Austral connections), which is not present in 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-loaded with the core purpose followed by usage guidance. Every word earns its place, with no redundant 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 simple list tool with no parameters and no output schema, the description fully covers what the tool does and why it exists. It names the terminal, the route format, and the intended usage, making it complete for an AI agent to invoke.

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 tool has zero parameters, so the schema is trivially covered. The description explains the nature of the output (routes with origin and destination), which is the only semantic information needed. The baseline of 4 for zero-parameter tools applies.

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 lists all bus routes (origin → destination) covered by the Coyhaique terminal. It uses a specific verb 'list' with a defined resource and scope, and differentiates itself from the sibling search_bus_schedules by noting its role in discovering connections.

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 directs the agent to use this tool before calling search_bus_schedules, providing a clear when-to-use context and naming the alternative. This is practical guidance for tool selection.

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 and destructiveHint=false, so the safety profile is clear. The description adds context about the geographical scope and priority filtering, but does not disclose other behavioral traits such as result size, ordering, or response shape. It does not contradict the annotations.

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

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

The description is two sentences, front-loaded with the primary action ('List Tuki destinations'), and includes the key filter options without unnecessary words. Every sentence earns its place, making it concise and easy to scan.

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

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

The description covers the core purpose and filters, which is sufficient for a list tool with optional parameters and no output schema. However, it does not mention what fields a returned destination includes or that responses can vary in detail via response_format. Given the presence of get_destination_detail as a sibling, the list tool likely returns summaries, but this is not stated, leaving a minor gap in completeness.

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

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

Schema coverage is 67%, with country and priority_only having descriptions. The description reinforces the intent of these filters and adds concrete examples of priority destinations (e.g., Torres del Paine). It does not explain response_format, but the enum values 'concise' and 'detailed' are self-explanatory. Overall, the description adds meaningful context beyond the bare 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 states a specific verb and resource: 'List Tuki destinations across Chile and Latin America.' It clearly distinguishes from sibling search tools by focusing on listing destinations with optional filters. The scope and filter options are included, making the tool's purpose unambiguous.

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

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

The description implies usage for listing destinations with optional filters, providing context about the geographic scope and priority filter. However, it does not explicitly state when to use this tool over alternatives (e.g., search_unified or list_solutions) or mention any exclusions, so the guidance remains implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by specifying the return fields ('Returns name, tagline, status, category') and the audience filter semantics. 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 concise and information-dense: it states purpose, gives use cases, explains filtering, and lists return fields in just four sentences. No wasted words or 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?

For a simple list operation with one optional parameter and an output schema, the description covers all necessary aspects: what it lists, when to use it, how to filter, and what fields are returned. An AI agent has enough context to invoke it 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 schema fully describes the audience parameter with enum values and meanings (100% coverage). The description repeats the same filter explanations ('b2b' (operator software), 'b2c' (travelers), 'creator' (influencers/monetization)) without adding new semantic depth. 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 tool's purpose: 'List Tuki solutions and product lines beyond the travel marketplace.' This distinguishes it from travel-focused siblings and specifies the resource type. It also enumerates the solution categories (software, creator monetization), making the scope 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?

Provides explicit use cases: 'Use when a user asks what Tuki offers; about software for tour operators / hotels / events... OR about making money / monetizing a community.' This gives strong when-to-use guidance. However, it does not explicitly mention when not to use it or name alternatives like get_solution_detail, so it falls short of 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?

The description adds behavioral context beyond annotations by specifying the output type ('metadata + canonical URLs') and explicitly excluding full body content. It also notes the 'published' filter, which is not declared in annotations. This is valuable for an AI agent deciding whether to use this tool.

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 primary action, and no wasted words. Every element adds value: what it does, when to use, what it returns, and what it doesn't.

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 simple list tool with one parameter and comprehensive annotations, the description fully covers usage context, return type, and exclusions. It also points to the relevant sibling for follow-up, making it complete 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?

The schema already provides a description for destination_slug with an example. The tool description adds example destination names in the usage clause but does not provide additional parameter semantics beyond what the schema states, so 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 states a specific verb ('List') and resource ('published Tuki travel guides') with a clear scope ('linked to a specific destination'). It distinguishes from sibling tools like search_travel_guides and get_travel_guide_detail by explicitly noting this is for listing guides for a destination and not for full bodies.

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

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

It explicitly states when to use this tool: 'Use when a user asks "what travel guides do you have for..."' and provides an alternative ('get_travel_guide_detail') for when full body is needed. This is clear guidance with no ambiguity.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds valuable behavioral context: reservation_centers only appear on stay intent, and it explicitly disambiguates 'vacation-rental centrals (NOT ski gear rental)' to prevent misinterpretation. This goes beyond annotations and provides useful edge-case disclosure.

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: it starts with a concise purpose, gives example queries, lists return types, notes the reservation_centers caveat, mentions price support, and ends with a routing rule. Every sentence earns its place with no filler.

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 there is no output schema, the description adequately covers the return value types (destinations, experiences, accommodations, reservation_centers), the stay-intent conditional, price filter support, and usage boundaries via the routing rule. This is complete enough 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 description coverage is 100%, so the baseline is 3. The description adds extra guidance by instructing to 'pass the user query verbatim' and reinforcing that price_min/price_max are in CLP. This value-add justifies one point 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 clearly states the tool's purpose as natural-language recommendation with specific verb and resource. It provides concrete example queries and lists return categories (destinations, experiences, accommodations, reservation_centers). It also distinguishes itself from sibling tools via an explicit routing rule.

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?

Contains an explicit routing rule: use THIS tool for trip planning, itineraries, and open-ended intent; use search_experiences/search_accommodations for a concrete product; use search_unified for one location across verticals. This gives clear when-to-use and when-not-to-use guidance with named 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 convey safety (readOnly, idempotent, non-destructive). The description adds useful context about remote inventory coverage and return fields, but it does not disclose pagination behavior, query match semantics, or default sorting, which are relevant for a search tool.

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 three sentences, front-loaded with purpose, and each sentence adds distinct value: what it does, unique coverage, and output summary. No fluff or 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?

With a full output schema and strong annotations, the description covers the essential aspects: purpose, unique data coverage, and key output fields. It omits explicit pagination guidance, but the schema's offset and max_results descriptions cover that, making the description adequately 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?

Schema description coverage is 88%, so the baseline is 3. The description adds a richer list of accommodation types and clarifies the 'by text or destination' usage, but it does not deepen meaning for fields like offset, max_results, or response_format beyond what the schema already 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 identifies the tool as a search for Tuki accommodations with a specific verb ('Search') and resource ('Tuki accommodations'), listing types and destination/text modes. It also distinguishes itself from siblings by highlighting remote locations where major OTAs have no inventory, which is a unique scope.

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

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

The description implies use for accommodation searches by text or destination, but it does not explicitly mention when to prefer this over sibling tools like search_unified or search_experiences. No alternatives or exclusions are named, leaving the agent to infer situational appropriateness.

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, open-world, idempotent, and non-destructive hints. The description adds useful context: unique inventory, hard-to-find data, and the return of operational status and canonical URL. It does not contradict annotations and enriches understanding beyond the structured hints.

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, front-loaded with the main action, and includes practical example queries in a natural way. Every sentence adds value without unnecessary fluff, making it easy to parse quickly.

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

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

Given the 8 parameters, rich annotations, and presence of an output schema, the description is fairly complete. It explains the domain, use cases, and key return fields. It does not elaborate on pagination or response formats, but the structured data covers those, and the examples make the tool's scope clear. Slight gap: no explicit comparison to list_bus_routes.

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 88% with detailed descriptions for most parameters. The description mentions filtering by origin, destination, date, or free text, which re-states obvious schema information but does not add deeper semantics about parameter relationships or edge cases. It does not explain offset behavior, but the schema already covers that.

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 'Search bus schedules' with a specific region (Carretera Austral / Coyhaique) and highlights the unique inventory. This distinguishes it from sibling tools like search_accommodations or search_unified, making the purpose unambiguous.

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

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

It provides concrete example queries ('cómo llegar a Caleta Tortel', 'bus Coyhaique a Chaitén') and context (hard to find online), which helps the agent know when to use it. However, it does not explicitly mention when not to use it or compare with alternatives like search_unified or list_bus_routes.

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

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

Beyond the readOnly/idempotent annotations, the description discloses that transfers/traslados are covered as rental vehicles, lists the exact output fields, and clarifies the gear rental exclusion with a specific alternative. This provides substantial behavioral context beyond the structured 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 the core purpose, followed by scope, output details, usage examples, and a clearly separated NOTE for the exclusion. Every sentence adds value with no redundancy or 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 an output schema and readOnly annotations, the description adequately covers purpose, scope, output details, usage examples, and an important alternative for gear rental. It is complete for a search tool, given the structured metadata available.

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

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

Schema description coverage is 80%, so the schema already documents most parameters. The description mentions filtering by free text or transmission, which aligns with query and transmission parameters, but does not add new meaning for offset, max_results, or response_format. It does not compensate beyond what schema already 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 it searches Tuki rental cars and includes transfers/traslados. It distinguishes from sibling search tools by specifying the resource type and provides concrete usage examples. The verb 'Search' is specific and the scope is 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 guidance is given with example queries ('arrendar auto en San Pedro', 'rent a car Atacama', 'traslado/transfer'). It also explicitly states when NOT to use this tool (ski/snowboard gear rental) and directs users to the 'recommend' tool as an alternative, which is clear and actionable.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive. The description adds meaningful context by stating the return fields (including CLP price, canonical purchase URL) and the default upcoming-only scoping. This enriches the annotation's safety profile with practical behavioral details, 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?

Three sentences heavily front-loaded with the core purpose. Each sentence adds value: purpose, platform context, return fields, and scope. The phrase 'Tuki is also a boutique ticketing platform' is slightly extra but useful for domain grounding. No redundancy with 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?

For a search tool with six parameters, rich annotations, and an output schema, the description covers purpose, scope, platform, and return values. It explains the default upcoming-only behavior and the key output fields. The existence of an output schema means return structure need not be detailed here, making this 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?

Schema description coverage is 83%, so the schema does the heavy lifting. The description adds minimal parameter context (e.g., 'free text' hints at query, and it repeats include_past behavior). It does not compensate for the small uncovered portion, but the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Search') with a resource ('Tuki events and ticketed experiences') and enumerates concrete categories (concerts, festivals, parties, etc.). It clearly differentiates from siblings like search_experiences by specifying the Tuki ticketing platform and the exact output fields (title, type, start date, 'from' price, location, URL).

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 establishes the tool's purpose and scope (searching Tuki events by text or type, upcoming only unless include_past). It does not explicitly name alternative tools or state when not to use it, but the context is unambiguous enough for an agent to select it appropriately.

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 safety profile; the description adds return fields (title, price in CLP, location, canonical URL) and result limit (up to 50). It doesn't mention pagination behavior, but that is partially covered by the offset parameter's schema description.

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 bit long but well-structured: it opens with the action and scope, then outputs, then use cases, then routing rule. Every sentence earns its place, though it could be tightened slightly without losing 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 rich output schema and high schema coverage, the description is complete: it explains purpose, outputs, example queries, and sibling differentiation. There are no major gaps in context for an agent to invoke this 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 description coverage is high (88%), so the baseline is 3. The description mentions filtering by text query, destination, or type, but does not add meaning beyond what the schema already provides for these 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?

The description clearly states it searches Tuki experiences and tours with specific categories (treks, day tours, multi-day, workshops, adventure activities), and explicitly distinguishes itself from sibling tools via the routing rule. The scope is concrete 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?

Provides explicit routing guidance: 'use THIS tool for a concrete single-vertical product search; use search_unified for open multi-vertical queries; use recommend for trip planning / open-ended intent.' Also supplies concrete example queries, making when-to-use very 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, openWorld, idempotent, and non-destructive behavior, so the description need not repeat those. It adds meaningful context about return contents (curated articles, itineraries, excerpts, canonical URLs) and the citable nature of the content, going beyond the structured 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 three sentences with no fluff, front-loads the main action, and packs relevant details (content type, use cases, return shape) into a compact space. Every sentence contributes useful 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 there is no output schema, the description does a good job explaining that results include excerpts and canonical URLs. However, it does not address the relationship to the sibling tool list_travel_guides_for_destination or mention filtering options like max_results/only_editorial, leaving a small completeness gap for a search tool with 4 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?

The input schema covers 75% of parameters with descriptions, so the baseline is 3. The description reinforces the semantics of query and destination ('by free text or destination') but adds no additional meaning for max_results or only_editorial beyond what the schema already 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 uses a specific verb and resource ('Search Tuki travel guides') and clearly specifies the content types (editorial blog + creator stories). It also distinguishes from siblings by emphasizing free-text/destination search and citable editorial content, differentiating it from list and detail 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 when to use the tool with concrete example queries ('what to do in X', 'how to plan a trip to X', 'best activities in X'). It does not mention when not to use it or name alternative sibling tools, but the use-case guidance is clear and actionable.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: returns up to 5 results per vertical with canonical URLs, and notes that depth/pagination require the per-vertical tools. This goes beyond the annotation baseline.

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

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

Every sentence serves a purpose: scope, use case, return behavior, and routing rule. It is concise yet dense, with no redundant filler.

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 simple one-parameter tool with no output schema, the description covers all essential context: what it does, when to use it, return limits, and how it relates to sibling tools. No critical information is missing.

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

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

The schema fully covers the only parameter ('query' as 'Search text.'). The description does not add additional format or semantics for the parameter, but with 100% coverage the schema already carries the meaning, so 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 tool performs a search across all verticals (experiences, accommodations, events, car rental) in one call. It explicitly distinguishes itself from per-vertical search tools, making its unique resource scope 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?

Provides explicit when-to-use guidance: use for open or multi-vertical queries, and names alternatives (search_* for concrete products, recommend for planning). The routing rule is concrete and actionable, leaving no ambiguity.

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