Ourway Camino de Santiago

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds meaningful behavioral context: no unit prices are returned, extras are meant to be passed to cotizar_paquete, and the 'preseleccionado' field indicates default recommendations based on nationality. This goes 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 concise, with two sentences that front-load the key fact (official catalog, no prices, only source of extras). Every sentence earns its place: the second adds integration details and the preseleccionado concept. 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?

This is a simple tool with one optional parameter, rich annotations, and an output schema present. The description covers the tool's authoritative scope, its relationship to cotizar_paquete, and the meaning of preseleccionado. With the output schema handling return value structure, the description is complete enough for an agent to know when and how to use it.

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 has one parameter (nacionalidad) with no description, and schema_description_coverage is 0%, so the description must compensate. It partially does by linking nacionalidad to the preseleccionado logic ('según nacionalidad'), implying it influences default recommendations. However, it does not explain allowed values or the effect of null, leaving some ambiguity.

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 provides the official pilgrim extras catalog, explicitly noting it is the ONLY list of extras that can be offered. It also distinguishes itself from pricing tools like cotizar_paquete by clarifying that it does not return prices and that extras are integrated via IDs, making the resource and 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?

The description gives a strong usage boundary: 'Es la ÚNICA lista de extras que se puede ofrecer al cliente: nada fuera de ella' (it's the only list of extras that can be offered, nothing outside it). It also explains the integration with cotizar_paquete via extras_ids, clarifying when to use this catalog versus the pricing tool. It doesn't explicitly list exclusions beyond 'no prices', but the guidance 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?

Discloses significant behavior beyond annotations: automatically selects best hotel, returns one total only, includes standard extras if omitted, requires presupuesto from client, and explicitly warns about 1-3 minute latency due to live availability checks. These details inform the agent of side effects and operational characteristics not captured by readOnlyHint or other 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 dense but well-organized, starting with the core purpose and then providing essential constraints and behavioral notes. Some redundancy exists due to bilingual repetition (English/Spanish), but every sentence adds value, and the structure is logical. It could be slightly more concise, but it's appropriately sized for the tool's complexity.

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 (8 parameters, nested objects, output schema), the description is quite complete, covering purpose, constraints, latency, and workflow integration. It doesn't explicitly explain how to construct etapas or habitaciones, but those are defined in the schema. With an output schema present, return values need not be described. Overall, it provides sufficient context for an agent to use 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?

With 0% schema description coverage, the description compensates well for key parameters: presupuesto is explained with required values and meaning, extras_ids are linked to catalogo_extras, and incluir_mochila behavior is clarified. However, some parameters (meal_plan, nacionalidad, categoria_alojamiento) remain unexplained, so it doesn't fully cover all semantics.

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: 'Quote the whole trip as ONE package price with live availability — the only valid source of Ourway pricing.' It also distinguishes itself from siblings by explicitly noting it never returns per-hotel, per-night, or per-extra prices, 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?

Provides strong usage guidance: it's identified as the 'only valid source' for package pricing, warns against using it for itemized prices ('NUNCA devuelve precios por hotel, noche o extra'), and references sibling tools for workflow (extras_ids from catalogo_extras, oferta_paquete_firmada for crear_propuesta). This clearly tells the agent when and how to use the 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 indicate readOnlyHint=false and openWorldHint=true, so the side-effecting nature is known. The description adds valuable context: the proposal link is valid for 7 days, the client can review the trip day-by-day and confirm, and the tool does not accept prices—only the signed offer. This enhances transparency 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 bilingual, repeating the same information in English and Spanish, which doubles its length without adding semantic value. It is front-loaded with the English summary, but the redundancy and the imperative conditions (all-caps SOLO) make it less concise than it could 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?

The description covers the main output (proposal link) and the key prerequisite (after explicit approval). However, with 7 parameters and no schema descriptions, it does not fully contextualize all inputs (e.g., what `formulario` expects beyond 'complete form') or potential failure modes. The output schema likely covers return values, but the description alone is only partially complete for using the tool confidently.

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 must compensate. It does clarify the key parameter `oferta_paquete_firmada` (from cotizar_paquete) and explains it must be a signed offer, not a price. However, other parameters like `idioma_codigo`, `camino_slug`, `poblacion_inicio_id`, and `poblacion_inicio_nombre` are left unexplained, relying on the agent to infer their meaning from names or nested schemas.

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: 'Create the Ourway booking request and return the customer's proposal link (valid 7 days).' This specific verb+resource combination distinguishes it from sibling tools like cotizar_paquete (quote) and estado_propuesta (status).

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

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

The description gives explicit when-to-use guidance: 'SOLO llamar tras la aprobación explícita del cliente del itinerario y el total, y con sus datos reales y el formulario completo.' It also specifies an input constraint ('No acepta precios: solo la oferta firmada') and references cotizar_paquete as the source of the signed offer, making the workflow 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 indicate a read-only, idempotent, non-destructive operation. The description adds concrete behavioral context by enumerating possible statuses (vigente, confirmada, caducada) and stating that a link is returned, giving the agent a better idea of what to expect from the response.

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 short sentences (one in English, one in Spanish) that immediately state the purpose and key details. It avoids redundant wording and is front-loaded with the verb and resource.

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, read-only status-checking tool with one parameter and an existing output schema, the description covers the core functionality, input format, and expected results (statuses and link). There are no major gaps given the tool's low complexity.

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

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

The schema has a single 'codigo' parameter with no description (0% coverage). The description compensates by specifying the expected code format '(codigo PET-XXX)', which tells the agent the syntax required. This adds essential meaning 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 clearly specifies the action ('Check the status') and the resource ('a proposal created via this channel'), and lists specific status values ('vigente / confirmada / caducada') along with a link. This distinguishes it from sibling tools like crear_propuesta or cotizar_paquete, making its purpose unambiguous.

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

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

The description provides context for when to use the tool: for proposals created via this channel, and it mentions the expected code format (PET-XXX). However, it does not explicitly name alternatives or specify when not to use it, so it is clear but not fully comprehensive.

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 the tool as readOnly, idempotent, and non-destructive. The description adds behavioral context by stating it 'recorre los campos conversacionalmente' (walks through fields conversationally) and sets guardrails on subsequent tool calls, which goes beyond what annotations alone convey.

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

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

The description is front-loaded with the core purpose, but repeats the same content in English and Spanish, creating redundancy. The Spanish sentences add only marginal detail (e.g., 'buscar' and the mirror form reference), so the description could be more concise.

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

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

For a tool with no parameters, strong annotations, and an output schema, the description is largely complete. It explains the form's role in the quoting workflow and highlights critical prerequisites. It doesn't enumerate all required fields, but that level of detail is not essential given the conversational nature and schema coverage.

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 0 parameters in the schema, the baseline is 4. The description adds meaning by naming key fields to collect (`presupuesto`, `datos de contacto`) and emphasizing that they are required before proceeding, even though these are not formal schema 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 identifies the tool as an 'intake form contract' for collecting customer fields before quoting, distinguishing it from downstream tools like cotizar_paquete and crear_propuesta. It explains the conversational walk-through of fields, though it lacks a crisp verb+resource construction like 'creates' or 'lists'.

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 the tool ('BEFORE quoting anything') and provides clear exclusions: 'do not call cotizar_paquete without presupuesto nor crear_propuesta without the contact data.' This gives strong contextual guidance, though it doesn't name an alternative tool for other use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a business rule that only these routes are bookable, which is valuable context beyond the annotations. No contradiction found.

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

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

The description is concise and front-loaded with the purpose. It includes a bilingual section, which is repetitive but intentional for the audience. The parameter explanation is integrated efficiently.

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 optional parameter and an output schema, the description covers purpose, parameter semantics, and usage context. The output fields are mentioned, and the bookability rule adds important context. Nothing essential 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 only defines the parameter as a string with a default, but the description fully compensates by listing allowed values (a_pie, en_bicicleta, a_caballo). This is essential information for correct invocation.

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 lists the Camino routes Ourway sells, specifying the output fields (slug, name, total km). It differentiates itself by noting that only these routes are bookable, which separates it from other catalog 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?

Provides explicit usage context: 'Úsalo antes de proponer rutas' and states that only these caminos are reservable. However, it does not mention alternatives or when not to use it.

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 and idempotent hints. The description adds meaningful context: results are in trail order with cumulative km from the origin, and it supports validation of overnight stays. This goes beyond the structured annotations without contradicting them.

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 short, front-loaded, and contains no filler. The bilingual repetition of the basic purpose is slightly redundant, but the second sentence adds essential usage guidance, so it earns its place.

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 one-parameter tool, strong annotations, and an output schema, the description provides enough context for selection and invocation, including use cases and ordering behavior. The lack of parameter guidance is a minor gap, so not a 5.

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 description provides no information about the camino_slug parameter, such as where to obtain it or its format. The tool name and schema title are the only hints, so the description fails to compensate for the missing schema detail.

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 exactly what the tool does: list towns along a route in trail order with id, name, and cumulative km. It clearly distinguishes itself from siblings like listar_caminos and proponer_itinerario by focusing on towns and referencing the start-point selection use case.

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: to choose the starting point (poblacion_inicio_id for proponer_itinerario) and to validate overnight stops. It gives clear context but does not mention exclusions or alternative tools, stopping short of a full 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?

Beyond the readOnly/idempotent annotations, the description discloses that optional params split/merge official stages and document the changes in avisos. It also clarifies that fecha_inicio is the first night, adding valuable 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 well-structured, starting with purpose and then usage rules. However, it unnecessarily repeats the first sentence in English and Spanish, adding slight redundancy but not harming clarity.

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

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

The description is complete for a proposal tool: it covers the main behavior, parameter effects, the confirmation workflow, and important date semantics. Since an output schema exists, return values are not needed. It sufficiently guides an agent for correct 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?

With 0% schema description coverage, the description compensates by explaining the nuanced optional params (num_noches, km_max_etapa) and the date format for fecha_inicio. Other params like camino_slug and the ID fields are left to their self-explanatory names, 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 clearly states it builds the itinerary following the official stages, with a specific verb and resource. It distinguishes itself from siblings by requiring confirmation before quoting, making the tool's role in the workflow explicit.

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 rules: do not pass num_noches or km_max_etapa unless the client asks, and explains the behavioral difference. Also instructs to present the itinerary and ask for confirmation before quoting, giving clear context and exclusions.

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