Skip to main content
Glama

Buscador de VamosAlicante (punto de entrada)

search_alicante
Read-onlyIdempotent

BUSCADOR: úsalo PRIMERO ante cualquier consulta sobre Alicante en lenguaje natural (transporte, autobús, TRAM, tren, aeropuerto, parkings, playas, tiempo, comer, dormir, ocio, comercio, salud, combustible). Devuelve una lista compacta de URLs canónicas con type y, cuando existe, entityId para pedir el estado en get_current_state, o resolveWith para resolve_entity. Sirve para DECIDIR qué 1–3 URLs pedir después: no devuelve el inventario completo ni admite paginación profunda.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNúmero máximo de resultados (1–10). Por defecto 10.
queryYesConsulta libre, p. ej. «parking cerca del teatro».

TDQS

A4.5/5.0
Behavior5/5

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

Más allá de las anotaciones readonly/openWorld/idempotent, la descripción revela un comporamiento clave: devuelve una lista compacta, no el inventario completo, y no admitem paginación profunda. También especifica qué campos contiene cada resultadoy para qué sirven (entityId/resolveWith), lo crue ayuda a entándir su alcance.

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?

La descripción es compacta, ordenda y front-loaded: la primera frasse ya dice que es el punto de entra da y cuándo usario. Cada oración aporta información útil y no hay relleno ni redundancias innecesarias.

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

Completeness5/5

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

Aunque no hay output-schema, la descripción explica suficientemente qué devuelve, cómo enlasar los siguients llamads (get_current_state/resolve_entity), y sus limitaciones. Para un tool de búsqueda de entra da con esta simplicidad, la información es compelta para que un agente lo seleccione e invogue correctamente.

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?

La cobertura del esquema es del 100%: query y limit están documentados en el propiio input-schema, incluyendo máximos y ejemplos. La descripción no añade detalies semánticos más allás de lo que ya ofrece el esquema, por lo que se mantiene el baseline de 3.

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?

La descripción identifica una acción concreta y un recurso específico: es un 'BUSCADOR' que devuelve URLs canónicas de Alicante y sirve como punto de entra da. Se distiguie de lostools hermanos al declirar que se usa PRIMERO y que no devuelve el inventario completo ni admitem paginación.

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?

La descripción establece explicitamente cuándo utilizario: 'úsalo PRIMERO ante cualquier consul ta sobre Alicante' y orienta los siguientes pasos: pedir estado en get_current_state o resolver con resolve_entity. Aunque no enumera excluiones frente a lostools de dominio específicos, sí define un flujo de uso y limitaciones.

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.

TDQS

A3.7/5.0
Disambiguation3/5

Most tools map cleanly to distinct domains (beach, fuel, weather, events, flights), but several transit tools overlap: find_transit_stop, favorite_stop, next_departures, get_current_state, and resolve_entity all deal with finding stops/stations and/or retrieving arrivals. Descriptions provide flow hints, so an agent can often disambiguate, but the boundaries are not crisp.

Naming Consistency3/5

Names mix verb-led patterns (find_*, resolve_entity, get_current_state) with noun-led patterns (beach_conditions, fuel_prices, parking_availability) and oddities like favorite_stop and whats_on. The style is readable and mostly snake_case, but there is no consistent verb_noun convention.

Tool Count3/5

16 tools is at the heavy end, and the travel-info surface could be consolidated (e.g., favorite_stop vs next_departures vs get_current_state). That said, Alicante's broad scope—transit, parking, beaches, food, weather, fuel, flights, events—makes the count defensible.

Completeness4/5

The set gives agents discovery (search_alicante, discover_capabilities), entity resolution (resolve_entity), and live/catalog state across transport, parking, beaches, weather, fuel, food, POIs, and events. Minor gaps exist (no general route planning, no editing/persistence beyond 'favorite'), but core informational workflows are well covered.

Resources