Skip to main content
Glama

Find parking rules and prices near a place

find_parking_rules_near
Read-onlyIdempotent

Find parking rules, availability, and costs near a location for a chosen time window, including on-street bays, car parks, and zone restrictions.

Instructions

For a time window and an area (a point with a square viewport, or a bounding box, at most 1.5 km2), returns every parking entity AppyWay knows there (on-street bays and lines, car parks), nearest first: whether parking is allowed for the whole window, part of it or not at all, and the quotes (cost, currency, max stay, no-return, free-until, payment methods). Adds each entity's name, address, bay types and zone, and the controlled-zone default rules (e.g. single yellow line hours) for the same area. Vehicle details (type, permits such as a blue badge, fuel) change the answer, they do not filter it; the exclude_* options filter.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude of the centre point
lngNoLongitude of the centre point
bboxNoBounding box in WGS84 degrees; sent to AppyWay as a closed GeoJSON polygon
end_timeNoEnd of the parking window; defaults to one hour after start_time
max_costNoLeave out places costing more than this for the window (no effect with exclude_paid)
start_timeNoStart of the parking window; defaults to now
max_resultsNoMaximum number of results to return (nearest first)
exclude_freeNoLeave out free parking
exclude_paidNoLeave out paid parking
fuel_type_idNoFuel type id (list_reference_values fuel_types)
vehicle_yearNoVehicle registration year
co2_emissionsNoVehicle CO2 emissions in g/km
distance_fromNoPoint inside the area to measure distances and order results from (defaults to the centre)
engine_size_ccNoEngine size in cc
permit_type_idsNoPermit type ids the driver holds, e.g. a blue badge (list_reference_values permit_types)
vehicle_type_idNoVehicle type id (list_reference_values vehicle_types); AppyWay assumes a standard petrol car when no vehicle details are given
viewport_size_mNoSide of the square around lat/lng, in metres (AppyWay limit: 1.5 km2, so at most 1224 m)
activity_type_idNoActivity type id, e.g. parking or loading (list_reference_values activity_types)
exclude_car_parksNoLeave out off-street car parks
exclude_on_streetNoLeave out on-street parking
exclude_truncatedNoLeave out places where parking is allowed for only part of the window
exclude_no_parkingNoLeave out places where parking is not allowed at all during the window
include_zone_rulesNoAlso return the zone default rules for the area (findZoneDefaultRulesByViewport)
include_entity_detailsNoFetch each result's name, address, bay types and zone (fetchEntitiesByIds)
include_contact_detailsNoReturn telephone numbers of payment providers, car park operators and notes, and stop redacting email addresses and phone numbers from names, notes, tags, addresses and location codes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive. The description adds genuinely non-obvious behavior: vehicle details change the answer rather than filter it, the 1.5 km2 area cap, nearest-first ordering, and what extras get attached (name, address, bay types, zone, controlled-zone defaults). Missing notes on cost/auth or truncation behavior for large result sets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

A dense but well-ordered passage — returns, then result contents, then the vehicle-vs-filter distinction. Every clause carries information, though it is a single long sentence that could be split for scannability.

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?

For a complex 25-parameter, 0-required, no-output-schema tool, the description covers what is returned and the key filtering/vehicle distinction well. It stops short of describing the shape of per-entity results or how partial-window matches are represented, which would matter more given there is no output schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantic value by explaining that vehicle attributes (type, permits, fuel) and exclude_* options have different effects on the answer versus the filter set, and reiterates the viewport area limit tied to viewport_size_m.

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?

States a specific verb and resource ('returns every parking entity AppyWay knows') with scope (time window + area, on-street bays/lines, car parks). An agent can tell this apart from siblings like get_parking_entity or get_zone_rules without opening a schema.

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?

Implies context (search by viewport/bbox for a time window) and clarifies that vehicle details affect the answer while exclude_* filter, plus names the internal siblings findZoneDefaultRulesByViewport and fetchEntitiesByIds. No explicit when-not-to-use or alternative-selection guidance, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.