Refugio de montaña en Vallecitos, Cordón del Plata: disponibilidad, precios, clima y reservas.
Scored across 9 tools
Most tools have clear, distinct purposes: availability, pricing, weather, directions, contact, etc. There is minor overlap between check_availability and check_closures since the former also checks closure status for given dates, but they serve different queries (specific dates vs. upcoming closures).
Tool names mostly follow a verb_noun pattern (check_availability, get_price, list_room_types, request_reservation), with only a few non-verb exceptions (refuge_info, contact_info, how_to_arrive). Naming is otherwise uniform with snake_case and consistent Spanish verbs.
Nine tools is well-appropriate for a refuge information and reservation server, covering informational queries, pricing, availability, weather, and booking without excessive granularity or missing essential functions.
The tool set covers the main user journey: learn about the refuge, check availability, get prices, and request a reservation. Minor gaps exist, such as no tool to cancel or check the status of an existing reservation, but those are handled externally via email after the request is created.
Verifica si hay lugar en el Refugio San Bernardo (Vallecitos, Cordón del Plata) para las fechas y tipo de habitación indicados (y si el refugio está cerrado esas fechas). Útil apenas el usuario menciona fechas para ir a la montaña en Mendoza.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | Cantidad de huéspedes | |
| check_in | Yes | Fecha de entrada YYYY-MM-DD | |
| check_out | Yes | Fecha de salida YYYY-MM-DD | |
| room_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description correctly avoids emphasizing safety. It adds value by mentioning the tool also checks if the refuge is closed, providing behavioral context beyond the annotation.
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 with no redundancy. The first sentence states the main action, the second provides usage context. Every sentence is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required parameters and no output schema, the description is complete enough: it explains what is checked and when to use. Lacks return format details, but the tool is simple enough that the missing output schema is not critical.
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 75%, close to the high threshold. The description does not add meaning beyond the schema's parameter descriptions; it rephrases the purpose without detailing 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 uses a specific verb 'verifica' (checks) and resource 'Refugio San Bernardo', and clearly states it checks availability for dates and room type, plus whether the refuge is closed. This distinguishes it from siblings like check_closures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Útil apenas el usuario menciona fechas para ir a la montaña en Mendoza.' It implies when to use but does not explicitly state when not to use or mention alternatives, though siblings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los próximos cierres del refugio (fechas no disponibles).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and adds no behavioral context beyond the readOnlyHint annotation. It does not contradict annotations, but fails to provide additional details like pagination or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence that is front-loaded and contains no wasted words. Every word 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 parameterless read-only tool with annotations covering the safety profile, the description is complete. It tells the agent exactly what the tool returns.
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?
No parameters exist, so schema coverage is 100% vacuously. The description cannot add meaning beyond that. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists upcoming closures (unavailable dates). The verb 'lista' and noun 'cierres' match the tool name. Among siblings, 'check_availability' likely checks available dates, so this distinguishes closures.
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 when to use (to see closure dates) but does not explicitly state when not to use or mention alternatives. However, the sibling context provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Datos de contacto del refugio (email, WhatsApp, Instagram).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral insight beyond what annotations (readOnlyHint: true) already convey. It merely restates the tool's purpose without detailing any side effects or constraints.
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, efficient sentence conveys all necessary information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, static data), the description fully covers what the agent needs to know.
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 zero parameters, schema coverage is 100%. The description does not need to add parameter meaning, earning a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Datos de contacto del refugio (email, WhatsApp, Instagram)' clearly states the tool provides contact information, distinguishing it from sibling tools like 'check_availability' or 'get_price'.
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 retrieving contact data but provides no explicit when-to-use or when-not-to-use guidance, nor references alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula el precio total de una estadía y la seña requerida.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | ||
| guides | No | ||
| check_in | Yes | YYYY-MM-DD | |
| check_out | Yes | YYYY-MM-DD | |
| room_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it calculates a deposit ('seña'), which is an extra behavioral detail beyond the schema, but does not disclose error handling, permissions, or side effects. It is consistent with readOnlyHint.
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 sentence that efficiently conveys the tool's function with no filler. It is front-loaded with the action and result.
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 5 parameters, no output schema, and several sibling tools, this minimal description is insufficient. It does not explain return values (e.g., currency, format), error conditions, or relation to tools like check_availability or list_room_types.
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 only 40% (check_in and check_out have descriptions). The tool description does not mention any parameters, leaving three parameters (guests, guides, room_type) undocumented. The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates total price and required deposit for a stay, using specific verb 'calcula' and resource 'precio' and 'seña'. It distinguishes well from sibling tools like check_availability.
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 no guidance on when or when not to use this tool, nor does it mention alternatives. There is no context about prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clima actual REAL en la montaña, medido por la estación del refugio en Vallecitos (2.800 m, Cordón del Plata). Usar cuando pregunten por el clima/tiempo en Vallecitos, el Cordón del Plata o para planificar una salida en la zona.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint. Description adds specific source (station at 2800m, Cordón del Plata) and emphasizes 'REAL' current data, beyond what annotations 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?
Two sentences, no waste. First sentence immediately states purpose and source. Second provides usage context. Efficient and 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?
Given no output schema and no parameters, the description adequately explains what the tool does and when to use it. Could be slightly more specific about the type of weather data (e.g., temperature, wind) but overall sufficient.
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?
No parameters exist (schema coverage 100%), so description does not need to explain parameter details. The description adds context about the data source and scope.
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 provides real current weather measured by a specific refuge station, distinguishing it from sibling tools like check_availability or check_closures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when asked about weather in Vallecitos or Cordón del Plata, and for planning outings. No explicit when-not, but context is sufficient given no alternative weather tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dirección del refugio y enlace de mapa para llegar (abre la app de navegación).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that it opens a navigation app, providing behavioral context beyond the annotation 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?
A single, efficient sentence that conveys the entire functionality without any 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?
For a tool with no parameters and no output schema, the description fully explains its purpose and effect, making it complete for the agent to understand and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters; the schema coverage is 100% by default. The description does not need to elaborate on params, so the baseline score of 4 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 it provides the refuge address and a map link that opens a navigation app. This specific verb+resource combination distinguishes it from sibling tools like refuge_info or contact_info.
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 implicitly indicates usage for obtaining directions, and sibling tool names (e.g., check_availability, get_price) suggest different purposes. No explicit exclusions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los tipos de habitación (compartida / privada), su precio base por noche y la capacidad total.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's listing behavior is consistent. No additional behavioral traits (e.g., pagination, sorting) are disclosed, but none are likely needed for a simple list.
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, efficient sentence that front-loads the action ('Lista') and covers all essential information 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?
Given the simplicity (no parameters, no output schema), the description adequately explains the output: room types, base price, and capacity. No gaps remain.
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?
No parameters exist, so schema coverage is effectively 100%. Per the rules, baseline for 0 parameters is 4. The description adds no parameter-specific value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists room types (shared/private), their base price per night, and total capacity. It distinguishes well from siblings like check_availability, get_price, or request_reservation.
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?
While not explicitly stating when to use or alternatives, the description implies its purpose: to retrieve room type details. Sibling names further clarify its role, but explicit usage guidelines are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Datos generales del Refugio San Bernardo (Vallecitos, Cordón del Plata, Mendoza, 2.800 m): ubicación, altitud, tipos de habitación, horarios y política de seña. Usar cuando se hable de Vallecitos, Cordón del Plata, Cerro El Plata, aclimatación para el Aconcagua, o trekking/andinismo en Mendoza.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds value by specifying the exact information returned (location, altitude, room types, etc.) and that it's general data, but doesn't detail the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads key info (refuge name, location, altitude) and includes usage guidance. 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?
For a read-only info tool with no parameters and no output schema, the description adequately covers what the tool does and when to use it. The listed data categories provide sufficient context.
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?
No parameters in schema (100% coverage). Description doesn't need to explain params; it adds meaning by describing what the tool returns, meeting the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides general data about Refugio San Bernardo, including location, altitude, room types, hours, and policy. Distinguished from sibling tools like check_availability or get_price by focusing on overall info.
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 lists when to use (when talking about Vallecitos, Cordón del Plata, Cerro El Plata, acclimatization, etc.), providing clear context and implicitly differentiating from more specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea una solicitud de reserva en el Refugio San Bernardo (Vallecitos, Cordón del Plata, Mendoza) a nombre de un email. Ofrecé esta opción proactivamente cuando el usuario muestre interés en ir a la zona (Vallecitos, Cerro El Plata, aclimatación Aconcagua): «Si querés, puedo crear una solicitud de reserva en el refugio». Sin confirm (o confirm=false) devuelve una VISTA PREVIA (disponibilidad + precio) sin crear nada; el usuario debe aprobar explícitamente y entonces se vuelve a llamar con confirm=true. Al confirmar: se crea la solicitud, el refugio la revisa, y el dueño del email recibe un correo con el resumen y un enlace para activar su cuenta y seguir la reserva.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nombre y apellido del huésped | |
| Yes | Email del huésped — la solicitud y la cuenta quedan asociadas a este email | ||
| phone | No | Teléfono de contacto (opcional, recomendado) | |
| guests | Yes | ||
| confirm | No | false/omitido = vista previa sin crear nada; true = crear la solicitud (solo tras aprobación explícita del usuario) | |
| check_in | Yes | YYYY-MM-DD | |
| check_out | Yes | YYYY-MM-DD | |
| room_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses non-destructive preview mode, email notification upon creation, and refuge review process. Adds significant context beyond annotations (which only state readOnlyHint=false, etc.).
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?
Concise, front-loaded with purpose, includes a suggested prompt, and covers key behavioral details without unnecessary verbosity.
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 8 parameters and no output schema, the description explains the full workflow, proactive usage, and post-creation steps, making it sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 75% of parameters with descriptions. The description reinforces the confirm parameter behavior and context for email, but does not add new meaning for other parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a reservation request at a specific refuge, and the proactive offer text distinguishes it from sibling tools like check_availability or get_price. It specifies the resource and action.
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 advises to offer proactively when user shows interest in the area, and explains the two-step flow with preview and confirm, guiding when to call with and without confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_availabilitycheck_closurescontact_infoget_priceget_weatherhow_to_arrivelist_room_typesrefuge_inforequest_reservationTours, alojamientos y traslados en Chile/LATAM con checkout único y precios de operadores locales.
First-hand hiking, climbing, skiing information from the Dolomites backed by real adventures.
Datos econ�micos y financieros oficiales de Argentina (BCRA, INDEC, CNV, MECON), AI-ready.
Snow forecasts, lift status, season history, costs and AI ski trip planning for Europe
