AppyWay MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APPYWAY_API_KEY | Yes | Your AppyWay API key, sent in the API-KEY header. Obtained from AppyWay by emailing apisupport@appyway.com. | |
| APPYWAY_BASE_URL | No | Base URL of the AppyWay API. Defaults to https://api.appyway.com/v1; the server appends /explorer, /traffic-data and /reference. Used by the tests. | https://api.appyway.com/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | Calls GET /ping on each AppyWay API section (Explorer, Traffic Data, Reference) and reports which ones this API key can reach. Use it first when other tools report 401 or 403. |
| find_parking_rules_nearA | 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. |
| fetch_kerb_segmentsA | The static parking map for an area (point with square viewport or bounding box, at most 1.5 km2) or for given entity ids: on-street segments (bays and yellow/red lines, with their bay types and capacity) and car parks, with name, address, a WGS84 point where AppyWay gives one, zone and authority. Optionally adds each entity's operating hours for one date. No prices: use find_parking_rules_near for those. |
| get_parking_entityA | One on-street segment or car park by id: name, address, bay types, capacity, zone and authority; its operating hours for a date (open periods marked Free, Paid or Mixed); how to pay (payment providers and links); and, when start_time is given, the parking quote for that window. |
| get_zone_rulesA | One zone (e.g. a controlled parking zone) by id with its type, notes and the default rules that apply to its kerb types over a time window: when each default (single yellow line, paid bay, ...) is in force and the maximum stay. Rules set on an individual bay override these defaults. |
| list_authoritiesA | Without a location: every authority this API key is entitled to (Traffic Data fetchAllAuthorities), with slug, data quality, the date of the last traffic-order update, centroid and notes; filter by name with query. With a point or a bounding box (at most 300 km2): the authorities covering that area (Explorer), with their notes and payment providers; an authority outside the key's entitlement is listed under not_accessible with AppyWay's reason. |
| get_authority_restrictionsA | For one authority slug (from list_authorities): the authority record and the links to its full restriction data as published by AppyWay's Traffic Data API: zones, on-street parking (bays and lines with their restriction sets), sets (operating hours, tariffs, exceptions, exemptions) and moving-traffic features, optionally as they stood at max_date. The documents behind the links can be very large; this server returns the links and never downloads them. |
| list_reference_valuesB | AppyWay's reference data: the numeric ids used by the other tools (vehicle_types, permit_types, fuel_types, activity_types, payment_methods, restriction_types, zone_types, ...), plus countries (with public holidays), regions (with event venues) and payment providers. For countries and regions an id fetches one record. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Tools target distinct resources (area rules, kerb map, entity, zone, authorities, reference data) and descriptions actively cross-reference each other (e.g. fetch_kerb_segments tells you to use find_parking_rules_near for prices). Minor overlap remains between find_parking_rules_near and fetch_kerb_segments since both take an area and return parking entities, and get_parking_entity vs fetch_kerb_segments both return entity details.
Strong verb_noun convention throughout (find_parking_rules_near, fetch_kerb_segments, get_parking_entity, get_zone_rules, list_authorities, get_authority_restrictions, list_reference_values). Only 'ping' deviates, which is a minor and understandable exception for a health-check tool.
Eight tools is well-scoped for a read-only parking data API, with each tool earning its place (health check, two area queries, two entity/zone lookups, authority queries, reference data). No redundant or filler tools.
Covers the main lifecycle for querying parking data: accessibility check, area search, entity/zone lookup, authority discovery and restrictions, and reference ids. Gaps are minor (e.g. no explicit address/geocode search or pagination handling), but agents can work around these via the provided area and id-based tools.