Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
APPYWAY_API_KEYYesYour AppyWay API key, sent in the API-KEY header. Obtained from AppyWay by emailing apisupport@appyway.com.
APPYWAY_BASE_URLNoBase 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues