Skip to main content
Glama

Campings en ruta

campings_en_ruta
Read-onlyIdempotent

Lista los campings que quedan cerca de un trayecto por carretera, en el sentido del viaje, con el km de la ruta en el que caen, el desvío, el estado de temporada en la fecha y la URL de su ficha. Para "qué campings hay entre A y B" sin planificar horarios.

Input Schema

NameRequiredDescriptionDefault
fechaNoFecha del viaje YYYY-MM-DD (por defecto hoy). Decide el estado de temporada de cada camping.
perroNoSolo campings que admiten perros.
origenYesNombre de la población o provincia (p. ej. "Burgos", "Asturias"); se reconocen provincias y poblaciones con campings en la guía. Si no se reconoce, coordenadas "lat,lng" del lugar.
destinoYesNombre de la población o provincia (p. ej. "Burgos", "Asturias"); se reconocen provincias y poblaciones con campings en la guía. Si no se reconoce, coordenadas "lat,lng" del lugar.
radio_kmNoDesvío máximo en línea recta desde la carretera, por defecto 25.
vehiculoNocoche = turismo; camper, autocaravana o caravana = perfil de vehículo grande.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / destino / description
      Previous value: -"Coordenadas \"lat,lng\" (recomendado) o nombre de una población o provincia con campings."New value: +"Nombre de la población o provincia (p. ej. \"Burgos\", \"Asturias\"); se reconocen provincias y poblaciones con campings en la guía. Si no se reconoce, coordenadas \"lat,lng\" del lugar."
    • changedInput schema / properties / origen / description
      Previous value: -"Coordenadas \"lat,lng\" (recomendado) o nombre de una población o provincia con campings."New value: +"Nombre de la población o provincia (p. ej. \"Burgos\", \"Asturias\"); se reconocen provincias y poblaciones con campings en la guía. Si no se reconoce, coordenadas \"lat,lng\" del lugar."
    • addedInput schema / properties / perro
      Added value: +{
      +  "description": "Solo campings que admiten perros.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behavioral value by explaining that results follow the 'sentido del viaje' and include the route-km, detour, season status, and profile URL, which is useful context 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.

Conciseness5/5

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

Two sentences with zero filler, and the primary purpose plus returned fields are front-loaded before the usage cue. Every clause carries information relevant to selecting or invoking the tool.

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

Completeness4/5

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

With six parameters and no output schema, the description compensates by naming the key return fields (km, desvío, season state, URL). It omits some parameter-level defaults like radio_km, but those are fully covered by the schema, so the definition is nearly complete for this tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so all six parameters are fully documented in the schema. The description only loosely reinforces that 'fecha' drives season status and that results follow the trip direction; it does not add syntax or constraints beyond what the schema already states.

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

Purpose5/5

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

The description gives a specific verb ('Lista') and resource ('campings... cerca de un trayecto por carretera'), and enumerates the returned fields (km de la ruta, desvío, estado de temporada, URL). It separates itself from the sibling planificar_ruta by scoping the use case to 'qué campings hay entre A y B' without schedule planning.

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

Usage Guidelines4/5

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

It provides an explicit when-to-use phrase ('Para "qué campings hay entre A y B" sin planificar horarios'), which implicitly routes schedule-planning requests to planificar_ruta. It does not name the sibling by name or state when not to use this tool, 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources