whats_onAgenda de actividades y cine en Alicante para una fecha o búsqueda concreta: eventos publicados y sesiones de cine con hora y sala.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Fecha YYYY-MM-DD en Europe/Madrid. | |
| limit | No | Resultados (máx. 10). | |
| query | No | Evento, película o palabra clave. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and open-world, so the description does not need to restate those. The description adds useful context about the returned content (published events and cinema sessions with time and screen), but it does not disclose any deeper behavioral traits 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 tool's purpose and scope. There is no redundant or filler wording.
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 provides a solid high-level picture and mentions the key returned data (events and cinema sessions with time and room). However, with no output schema and all parameters optional, it leaves some ambiguity about default behavior when neither date nor query is provided, and about the exact response structure.
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 parameters (date, limit, query) are already documented. The description's 'fecha o búsqueda concreta' aligns with date and query but adds no additional semantic detail 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 identifies the resource: an agenda of activities and cinema in Alicante for a specific date or search. It conveys "what's on" well, but it lacks an explicit verb and does not directly distinguish itself from broader siblings like search_alicante.
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 phrase 'para una fecha o búsqueda concreta' provides clear context for when to use the tool: when the user wants events or cinema sessions for a specific date or keyword. However, it gives no explicit exclusions or comparison with sibling tools such as search_alicante or find_place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.