parking_availabilityEstado de los aparcamientos públicos de Alicante: plazas libres cuando hay observación de sensores vigente, y ficha (capacidad, dirección, tarifa) cuando solo existe catálogo. dataType declara si el dato es LIVE o CATALOG.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: results may be LIVE or CATALOG, and static entries include capacity, address, and tariff. This explains output variability beyond what annotations or schema indicate.
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 filler. The main purpose is front-loaded, and the data-mode distinction and field reference are placed logically. Every sentence 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?
For a parameterless query tool, the description is largely complete: it explains both output modes and the discriminator field. The absence of an output schema is partially mitigated by the explicit field list. Minor gaps remain around whether the list is paginated or sorted, but these are not critical 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 zero parameters, the baseline is 4. The description still adds semantic value by mentioning the `dataType` field and what fields appear in the CATALOG case (capacity, address, rate), which helps an agent interpret results even though no input parameters exist.
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 states a specific verb and resource: it reports the status of public parking in Alicante. It goes further by distinguishing two data modes (LIVE sensor observations vs. CATALOG-only records) and names the `dataType` discriminator, which clearly differentiates it from sibling tools like beach_conditions or find_place.
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 the tool: whenever an agent needs parking availability or parking facility details for Alicante. However, it does not explicitly state exclusion criteria or reference alternatives such as search_alicante or find_place, leaving some routing ambiguity.
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.