Skip to main content
Glama
dragosh29

AppyWay MCP server

by dragosh29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

AppyWay MCP server

An MCP server that lets Claude, ChatGPT and other MCP clients use the AppyWay API: UK kerbside parking rules and prices, parking entities (on-street bays and lines, car parks), controlled zones, local authorities and AppyWay's reference data. It is built from AppyWay's public documentation and its three published OpenAPI documents (Explorer, Traffic Data, Reference). Every tool is read-only.

Once it's connected, someone with an AppyWay API key can ask things like:

  • "Can I park near 51.5195, -0.1100 between 6 and 8pm tonight, and what will it cost?"

  • "I have a blue badge and an electric car. Where in this area can I park for the next two hours, and for how much?"

  • "When do the single yellow lines in this controlled zone apply tomorrow?"

  • "What are the operating hours of this bay on Saturday, and how do I pay for it?"

  • "Which authorities does our key cover, and when were their traffic orders last updated?"

  • "Give me the links to Northgate's full restriction data as it stood on 1 September."

Tools

Tool

What it does

API calls

ping

Checks which of the three API sections the key can reach.

GET /explorer/ping, /traffic-data/ping, /reference/ping

find_parking_rules_near

For a time window and an area (a point with a square viewport, or a bounding box; at most 1.5 km2, as documented): every parking entity, nearest first, with whether parking is allowed for the whole window, part of it or not at all, and the quotes (cost, max stay, no-return, free-until, payment methods). Adds each entity's name, address, bay types and zone, and the zone default rules for the same area. Vehicle details (type, fuel, permits such as a blue badge, emissions, year, engine size) and the documented filters are passed through.

POST /explorer/findParkingQuotesByCentreAndViewportSize or /findParkingQuotesByViewport, /fetchEntitiesByIds, /findZoneDefaultRulesByViewport

fetch_kerb_segments

The static parking map for an area or for given entity ids: on-street segments (bays, yellow and red lines) and car parks with bay types, capacity, address, a WGS84 point, zone and authority. Optionally the operating hours of each for one date.

POST /explorer/findParkingEntitiesByCentreAndViewportSize or /findParkingEntitiesByViewport, or /fetchEntitiesByIds; /fetchOperatingHoursByIds

get_parking_entity

One entity: details, operating hours for a date (periods marked Free, Paid or Mixed, and closed periods), payment providers and links, and a quote when a start time is given.

POST /explorer/fetchParkingEntityById, /fetchOperatingHoursById, /fetchPaymentProvidersByParkingEntityId, /fetchParkingQuoteById

get_zone_rules

One zone with its type and notes, and the default rules for its kerb types over a window (when each applies, max stay).

POST /explorer/fetchZoneById, /fetchZoneDefaultRulesById

list_authorities

Without a location: the authorities the key is entitled to, with slug, data quality, last traffic-order update, centroid and notes. With a point or a bounding box (at most 300 km2): the authorities covering it, with notes and payment providers; one outside the key's entitlement is listed under not_accessible with AppyWay's reason.

POST /traffic-data/fetchAllAuthorities; or /explorer/findAuthorityIdsByViewport, /explorer/fetchAuthorityById

get_authority_restrictions

One authority by slug, and the links to its full restriction data (zones, on-street parking, sets of hours and tariffs, moving-traffic features), optionally as at a date. The links are returned; the documents are never downloaded.

POST /traffic-data/fetchFullAuthorityBySlug, /fetchFullAuthorityInfoBySlug

list_reference_values

Any of the 23 reference lists (vehicle, permit, fuel, activity, restriction, zone types, payment methods and providers, countries, regions, ...), or one country or region by id.

POST /reference/fetchAll*, /fetchCountryById, /fetchRegionById

Almost every AppyWay endpoint is a POST with a JSON body, but these POSTs are queries: they search or fetch and change nothing, which is why every tool carries the MCP readOnlyHint annotation. The API has no write endpoints in the published specs, so there is no write switch.

Not covered on purpose: the Traffic Data file exports (exportAuthorityRestrictions*.geojson, .dxf, exportAuthorityMovingRestrictionsById) and wfs, because they are downloads; fetchParkingQuotesByIds and fetchEventDatesById, which the tools above do not need. The Traffic Data spec defines schemas for traffic orders (Order, FullOrder, ...) but no endpoint that returns them, so there is no traffic-order tool; list_authorities reports each authority's lastTmoUpdate as last_traffic_order_update.

Related MCP server: ChurchSuite Bookings MCP

Setup

Requires Node 18 or later.

npm install
npm run build

You need an AppyWay API key. AppyWay's getting-started guide says keys are obtained from AppyWay by emailing apisupport@appyway.com; the key is sent in the API-KEY header. A key only covers the authorities it has been granted.

Claude Desktop: add this to claude_desktop_config.json:

{
  "mcpServers": {
    "appyway": {
      "command": "node",
      "args": ["/absolute/path/to/appyway-mcp/dist/index.js"],
      "env": { "APPYWAY_API_KEY": "your-key" }
    }
  }
}

Claude Code:

claude mcp add appyway -e APPYWAY_API_KEY=your-key -- node /absolute/path/to/appyway-mcp/dist/index.js

Variable

Required

Meaning

APPYWAY_API_KEY

yes

Your API key, sent in the API-KEY header.

APPYWAY_BASE_URL

no

Defaults to https://api.appyway.com/v1; the server appends /explorer, /traffic-data and /reference. Used by the tests.

Safety defaults

  • Read-only: every tool is a query and carries readOnlyHint: true and destructiveHint: false. There is no write tool and no write switch.

  • No personal data is expected in this API. Still, telephone numbers (a payment provider's pay-by-phone number, a car park operator's number, the telephone on an authority note) are only returned when the assistant explicitly asks (include_contact_details); by default the output only says has_pay_by_phone: true. In free text (zone and authority notes and note titles, entity, zone and authority names, authority tags, entity address lines and location codes, reference-list names such as event venues, and AppyWay's own error messages, whatever the HTTP status) email addresses are replaced with [email redacted] and phone-number-like sequences with [phone redacted], using the same heuristic as the other servers in this series (international +/00 numbers including +44 (0)…, bracketed UK area codes, and 0… numbers of 9 to 11 digits; GUIDs, ETags and dates are left alone). include_contact_details returns the text unredacted. The heuristic only looks for emails and phone numbers. Ids, URLs (payment pages, app links, websites, note links) and the id/code/url fields of reference records are passed on as given.

  • The Traffic Data Authority record contains an ordnanceSurvey object with an Ordnance Survey API key and licence. It is never returned, not even with include_contact_details.

  • No bank, card or payment data exists in these endpoints. Payment-provider links (cardPaymentsExternalUrl, paymentsUrl) are the provider's own public payment pages and are returned; app deep links are returned per platform as given.

  • Nothing is downloaded: get_authority_restrictions returns the four data-document links and never fetches them (AppyWay says they can be large; they are cached indefinitely and can be kept until the endpoint returns different links). Entity geometry is reduced to one WGS84 point (a Point without a CRS, or with EPSG:4326/CRS84); shapes and projected (EPSG:3857) coordinates are left out.

  • Input is checked before any call is made: a location must be either lat+lng or a bbox, never both; the area limits AppyWay documents are enforced locally (1.5 km2 for parking and entity searches, so a square side of at most 1224 m; 300 km2 for authority searches); times must be ISO 8601 with a Z or an offset (a time given without seconds is sent with :00 added, since the specs document YYYY-MM-DDThh:mm:ssTZD), dates YYYY-MM-DD and real calendar dates (2026-02-30 is refused), and an end time after the start. Entity, zone and authority ids must be GUID-like strings (letters, digits, -, _, up to 64 characters, optionally wrapped in a pair of braces, which are removed before sending): the specs type them as plain strings, and every request example in AppyWay's guides is a bare GUID. Slugs must be letters, digits, - and _. Name filters (query) are trimmed, and one that is empty after trimming is refused.

  • Operating-hours requests set the documented includeClosedPeriods: true, so the closed periods AppyWay has for that date are returned as closed_periods.

  • Defaults: a parking window starts now and lasts one hour; a zone-rules window lasts 24 hours; operating hours are for today's UTC date; a square viewport is 300 m; a point given to list_authorities becomes a 100 m square. Ids sent to fetchEntitiesByIds and fetchOperatingHoursByIds go 50 per request; that cap is this server's choice (no maximum is documented).

  • Rate limits: AppyWay documents a 429 Too many requests response on every operation but no limit, quota or Retry-After behaviour. Requests are spaced 250 ms apart (about four per second). A 429 is retried at most twice for any method (a rate-limited request was not processed), waiting for Retry-After (whole or fractional seconds, or an HTTP-date; 2 s then 4 s when the header is absent or unreadable). Each wait is capped at 10 seconds; if AppyWay asks for a longer wait, the call gives up at once and says how long to wait. A tool call that makes several requests can still run past the MCP client's default 60-second request timeout.

  • 502, 503 and 504 are retried the same way for GET (the pings) only. A POST is never repeated after a gateway error, even though every POST here is a query; the error says it is safe to call the tool again. A GET that fails three times is reported with advice and without the gateway's HTML.

  • A 200 whose body is not JSON (a proxy or login page in the way) or whose envelope says success: false is reported as an error, never as an empty result.

  • Errors say what to do: a wrong key (401) names APPYWAY_API_KEY; the documented 401 for an authority outside the key's entitlement ("No permissions to authority …") says the key is not entitled to that authority and points to list_authorities and apisupport@appyway.com; a 403 says the key may not be enabled for that API section and suggests ping; 400 and 404 pass on AppyWay's message and per-field errors.

Tests

npm test

The test suite:

  1. Validates every fixture record against the component schemas in AppyWay's three published OpenAPI documents (Explorer ParkingEntity, ParkingEntitySearchResult, Zone, ZoneSearchResult, Authority, ParkingEntityOperatingHoursResult, PaymentProvider; Traffic Data Authority, FullAuthority; Reference list responses), with negative controls. The specs are downloaded from Stoplight to spec-explorer.json, spec-traffic-data.json and spec-reference.json on the first run. Three adjustments are made so Ajv can use the documents, and the test says so in code: {"nullable": true} without a type (10 places) is read as "any value"; the OpenAPI 3.0 boolean exclusiveMinimum (once) is converted to the numeric form; and the Explorer Geometry schema, which lists only type and crs and forbids other keys, is allowed a coordinates array, because the Explorer guide's example entity has coordinates on every geometry (a check proves the unadjusted schema rejects the fixtures). The response of fetchFullAuthorityInfoBySlug is validated against a schema written by hand from the endpoint's description ("The initial object contains only the URLs"), because the published AuthoritySnapshotInfoDoc schema describes the documents behind the links, not the links; a check shows the published schema rejects a links-only response.

  2. Starts a local mock of the API under /v1/explorer, /v1/traffic-data and /v1/reference that checks the API-KEY header and serves the fixtures (the API has no pagination). Its results are validated against each operation's documented response schema, and its errors against the documented shapes: 400 BadRequestResponse, 404 NotFoundResponse, and the getting-started guide's 401 example for an authority outside the key's entitlement. A wrong key and 429s get no body, as the specs document those responses with a description only. The Explorer guide's example search request is validated against the request schema and accepted by the mock. The enum names the server prints are checked against the specs' descriptions, and the TimeSpan parser against the documented [-][d.]hh:mm:ss[.fffffff] format and the spec's own example.

  3. Starts the built server and drives it over stdio with the official MCP client: 21 checks covering tools/list and annotations (the same 8 read-only tools with APPYWAY_ALLOW_WRITES=true); every tool; the centre-and-size and polygon forms of the searches with every documented filter, vehicle detail, onStreetParkingTypes, includeNotApplicableTimes, maxDate and localeCode passed through exactly; the defaults (window, viewport, date); times without seconds sent with them; the 50-per-request batching of ids, braced ids sent bare and a repeated id reported once; includeClosedPeriods sent and the closed periods returned; an empty area making no follow-up calls; refusal of bad input before any call (two or no locations, inverted windows, bad ids, slugs, impossible dates, blank queries); the area limits just under and just over 1.5 km2 and 300 km2; redaction of emails and phone numbers in notes, note titles, entity, zone and authority names, tags, address lines, location codes and error messages (including a success: false 200) and the withholding of telephone numbers by default, and their return on request; a Point in EPSG:3857 left out; a data-document link given as a list passed on and an inline document summarised; the Ordnance Survey key never returned; the entitlement 401 and a 403 (on a GET and on a POST) reported with advice; a 404 for an unknown id; requests spaced about 250 ms apart; the 429 retry waiting for Retry-After in the seconds, fractional-seconds and HTTP-date forms and 2 s when the header is missing or unreadable, giving up after three attempts on a persistent 429 and at once on a Retry-After just above the 10 s cap (10.5 s); a 502 retried for GET and never for a POST; a GET failing three times with 503 reported without the gateway's HTML; a non-JSON 200 and a success: false envelope reported as errors; a wrong key; and that every request carried the API-KEY header and no other credential, hit a documented method and path, and sent a body that validates against the operation's documented request schema (or no body where none is documented).

All three parts (24 checks) run in about 45 seconds.

Status

This is a working prototype. It has not been run against the live API, because it was built without an AppyWay account (AppyWay offers no self-serve key or sandbox). Everything below is taken from the published specs and guides and should be confirmed on a real account:

  • The error bodies for a wrong key (401), 403 and 429: the specs document them with a description only. The server handles any JSON message/errors[] and no body at all. Whether a 429 carries Retry-After, and what the rate limit is, are not documented.

  • The entitlement error: the guide's 401 example ("No permissions to authority '{GUID}'", property authority). Which endpoints return it, and whether searches in an area outside the entitlement return it or just return fewer results, is not documented; the mock returns it for id and slug lookups.

  • The body of GET /explorer/ping and GET /traffic-data/ping (not documented; the Reference ping documents {success, result: string}, and the description says "pong").

  • The response of fetchFullAuthorityInfoBySlug: the schema describes FeatureCollections while the description says the object contains only URLs. The server passes on a string or a list of strings and summarises anything else without inlining it. Whether ospsUrl is one URL or several is not clear from the docs.

  • Geometry: whether Explorer geometries carry coordinates (the schema omits them; the guide's example has them), and which CRS the Point uses when none is given (assumed WGS84, as in the guide's example; a point with another CRS is left out).

  • The format of entity, zone and authority ids (all examples are GUIDs; the Traffic Data authority id is format: uuid), of slugs, and of country and region ids (up to 36 characters, as documented).

  • Whether the list endpoints of the Reference API and fetchAllAuthorities accept a POST with no body (no request body is documented; that is what the server sends), and whether fetchAllRestrictionTypes accepts {} when no locale is given.

  • The time window: the Explorer query schemas list endTime as optional but describe it as "Required"; the server always sends it. duration is read-only in the spec and is never sent. The format of requestedDuration in responses (a .NET TimeSpan per the guide) and how times are normalised.

  • The operating hours returned when no date is sent (not documented); the server always sends one (today's UTC date by default, while AppyWay describes dates as local). What includeClosedPeriods adds on the live API, and the format of the closed periods' times (the spec's DateTimeRange example has no time zone), are not confirmed; the mock returns them only when the flag is set.

  • The platform keys of paymentsAppDeepLinks (documented as a map "by platform" without naming the platforms) and whether paymentsTelephone is ever something other than a public pay-by-phone number.

  • The area limits: the server enforces 1.5 km2 and 300 km2 with its own approximate area calculation for bounding boxes; AppyWay's own calculation may differ slightly at the edges. The documented viewportSize maximum on findParkingEntitiesByCentreAndViewportSize is 1225 m; the server allows at most 1224 m everywhere.

  • Whether fetchEntitiesByIds and fetchOperatingHoursByIds accept 50 ids per request, or more (no maximum is documented).

  • How many requests per second the API tolerates; the throttle here is a guess on the polite side.

Going to production

This version runs locally over stdio, with the key holder's own API key. For AppyWay's customers to connect from claude.ai or ChatGPT without handling keys, the next step is a remote server (Streamable HTTP) behind OAuth, hosted by AppyWay, and then a listing in the Claude and ChatGPT connector directories.

Licence

MIT. Built by Alexandru Dragoș (alexandru.dragos96@gmail.com) with an AI agent (Claude) working under his direction.

Available Tools

8 tools
fetch_kerb_segmentsFetch kerb segments and car parksA
Read-onlyIdempotent

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.

NameRequiredDescriptionDefault
latNoLatitude of the centre point
lngNoLongitude of the centre point
bboxNoBounding box in WGS84 degrees; sent to AppyWay as a closed GeoJSON polygon
entity_idsNoFetch these entities instead of searching an area
max_resultsNo
distance_fromNoPoint to measure distances and order results from (area search only)
viewport_size_mNoSide of the square around lat/lng, in metres (AppyWay limit: 1.5 km2)
exclude_car_parksNoLeave out car parks (area search only)
exclude_on_streetNoLeave out on-street entities (area search only)
operating_hours_dateNoAlso fetch each entity's operating hours for this local date (YYYY-MM-DD)
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
on_street_parking_typesNoOnly on-street entities of these types (area search only), e.g. LoadingBay, DisabledBay, SingleYellowLine

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so safety is covered. The description adds genuinely useful beyond-annotation context: the data is 'static', scope is capped at 1.5 km2, hours are only for one date, and prices are absent. It stops short of describing pagination or result-count behavior.

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?

Three sentences with no filler, and the payload (what is returned) is front-loaded before the optional hours and the explicit exclusion. It is dense with parentheticals, which slightly reduces scannability, but every clause carries usable information.

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?

With 12 optional parameters and no output schema, the description carries the output burden and does it well, enumerating entity fields (name, address, WGS84 point, zone, authority, bay types, capacity). Remaining gaps are minor: no mention of result limits/pagination or the relationship between max_results and the two search modes.

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 92%, so the baseline is 3, but the description adds real semantics by clarifying that lat/lng plus viewport and bbox are alternative ways to define the same area and that the 1.5 km2 cap applies to that area, plus that entity_ids replaces area search. This complements individual parameter descriptions rather than restating them.

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?

The description names a specific verb and resource (fetch the static parking map: on-street segments and car parks), scopes it precisely (area point+viewport or bbox up to 1.5 km2, or entity ids), and enumerates returned attributes. It also explicitly differentiates itself from a sibling by stating it does not return prices and routing to find_parking_rules_near.

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?

It gives clear context for the two invocation modes (area search vs entity_ids) and explicitly names the alternative tool for pricing data. It does not, however, distinguish itself from get_parking_entity for single-entity lookups, so the 'which sibling when' guidance is incomplete.

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

find_parking_rules_nearFind parking rules and prices near a placeA
Read-onlyIdempotent

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.

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

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.

get_authority_restrictionsGet an authority's restriction dataA
Read-onlyIdempotent

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.

NameRequiredDescriptionDefault
slugYesAuthority slug, e.g. from list_authorities
max_dateNoSee the restrictions in force at this date (default: now)
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

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses genuinely useful behavior: it returns links and never downloads the underlying documents, and those documents 'can be very large'. That prevents an agent from expecting inline payloads. It doesn't add auth or rate-limit context, but the annotations already cover the safety profile.

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?

Front-loaded with the resource and scope, then a second sentence carrying the important non-downloading constraint. Dense but every clause earns its place; the enumerated data surfaces make the first sentence long but informative rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so: the authority record plus links, the categories behind those links, and the fact that the documents themselves are not inlined. Nothing an agent needs in order to call this correctly and interpret the result is missing.

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

Parameters3/5

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

Schema coverage is 100%, so all three parameters are already documented, including the slug source and the contact-detail redaction behavior. The description adds only the temporal framing for max_date ('optionally as they stood at max_date') and says nothing about include_contact_details, so it stays at the baseline for a fully described schema.

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+resource (get the authority record plus links to its full restriction data) and enumerates the data surfaces covered: zones, on-street parking bays/lines, sets and moving-traffic features. It also names list_authorities as the source of the required slug, which cleanly separates it from siblings like get_zone_rules or find_parking_rules_near.

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?

It implies when to reach for it (you have an authority slug and want the entry point to all of that authority's published restriction data) and points to list_authorities for the slug. It does not explicitly say when to prefer the narrower siblings such as get_zone_rules or get_parking_entity instead, so no exclusions are stated.

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

get_parking_entityGet one parking entityA
Read-onlyIdempotent

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.

NameRequiredDescriptionDefault
dateNoLocal date (YYYY-MM-DD) for the operating hours; defaults to today (UTC date)
end_timeNoEnd of the quoted window; defaults to one hour after start_time
entity_idYesEntity id from find_parking_rules_near or fetch_kerb_segments
start_timeNoAlso quote parking from this time
fuel_type_idNoFuel type id (list_reference_values fuel_types)
vehicle_yearNoVehicle registration year
co2_emissionsNoVehicle CO2 emissions in g/km
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
activity_type_idNoActivity type id, e.g. parking or loading (list_reference_values activity_types)
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

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds real value beyond them by disclosing return content and conditional behavior: operating hours are marked Free/Paid/Mixed, payment providers and links are included, and the parking quote appears only when start_time is supplied.

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 single dense sentence, but it is front-loaded with the primary identity of the tool and then layers on the returned facets in a readable order. Nothing is padding, though the compound structure is heavy for one sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must carry the return-shape burden, and it does: it enumerates the entity fields, the hours semantics, the payment info, and the optional quote. For a complex 12-parameter read-only tool, an agent has enough to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 12 parameters, including the vehicle and permit fields the description never mentions. The description adds only light semantic framing (date drives hours, start_time triggers the quote), which is the expected baseline when the schema does the heavy lifting.

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 ('get') and resource ('one on-street segment or car park by id') and enumerates the returned facets (name, address, bay types, capacity, zone, authority, hours, payment, quote). It clearly distinguishes a single-entity lookup from the sibling listing/rule tools like find_parking_rules_near and fetch_kerb_segments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call it when you already have an entity id, and start_time is the condition that adds a quote. However, the description never explicitly states when to prefer this over siblings such as get_zone_rules or find_parking_rules_near; that routing information lives only in the entity_id schema description.

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

get_zone_rulesGet a zone and its default rulesA
Read-onlyIdempotent

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.

NameRequiredDescriptionDefault
zone_idYesZone id (zone_id from find_parking_rules_near, fetch_kerb_segments or get_parking_entity)
end_timeNoEnd of the window; defaults to 24 hours after start_time
start_timeNoStart of the window; defaults to now
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
on_street_parking_typesNoOnly these kerb types (default: every type the zone defines a default for)
include_not_applicable_timesNoAlso list the windows in which each default does not apply

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds useful domain behavior — defaults are per kerb type with in-force windows and a max stay, and bay-level rules take precedence — but says nothing about result size, pagination, or failure modes.

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 single compact sentence front-loaded with the resource and its identity key. The parenthetical examples ('single yellow line, paid bay, ...') cost a little space but usefully anchor an unfamiliar domain.

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?

With no output schema, the description usefully enumerates the payload shape (type, notes, per-kerb-type defaults, in-force windows, max stay). For a 6-parameter read tool that mostly does what its name says, this is close to sufficient; only result volume and error behavior are unaddressed.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (zone_id, start_time, end_time, include_contact_details, on_street_parking_types, include_not_applicable_times) is already documented in the schema. The description reinforces the notion of a time window and kerb-type scope but adds no syntax, format, or defaulting information beyond that.

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 ('One zone ... by id with its type, notes and the default rules'), scoping exactly what is returned. It is clearly distinguishable from siblings like find_parking_rules_near (search) and fetch_kerb_segments (segment geometry), which operate at a different granularity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the id-based lookup phrasing, and the closing note that 'Rules set on an individual bay override these defaults' implicitly tells the agent when zone-level defaults are insufficient. However, no sibling tool is named as an alternative and there are no explicit when-not conditions.

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

list_authoritiesList local authoritiesA
Read-onlyIdempotent

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.

NameRequiredDescriptionDefault
latNoLatitude of a point to find the covering authority
lngNoLongitude of a point
bboxNoBounding box in WGS84 degrees; sent to AppyWay as a closed GeoJSON polygon
queryNoCase-insensitive match on name, legal name or slug (without a location)
max_resultsNo
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

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/open-world safety, so the description adds genuinely new behavior: entitlement-scoped results, the not_accessible bucket with AppyWay's reason, the 300 km² limit, and the redaction toggling in include_contact_details. This is real context beyond structured fields.

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?

Two dense sentences, front-loaded with the no-location case before the location case, and the entitlement caveat placed last. No filler sentences, though the wording is heavy enough that a reader must parse carefully.

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 read-only list tool with no output schema, the description enumerates the returned fields for both modes and the edge-case bucket, which covers most of what an agent needs. It omits pagination/max_results behavior and what the response shape looks like, but nothing critical is missing.

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 83% so the baseline is 3, but the description adds constraints not present in the schema – the 300 km² bbox cap and the query-only-applies-without-location rule. It leaves lat/lng/bbox combinability and max_results semantics to the schema.

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?

The description states two distinct modes clearly: listing all entitled authorities (with slug, data quality, last update date, centroid, notes) versus finding authorities covering a point or bbox (with notes and payment providers). The verb+resource are specific and the internal API names (fetchAllAuthorities/Explorer) plus the not_accessible behavior distinguish it from siblings like get_authority_restrictions.

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?

It clearly delineates when each mode applies (no location vs. point/bbox) and states the 300 km² bbox constraint and the entitlement fallback. It does not explicitly name sibling tools or say when to prefer them, so it stops just short of full alternative routing.

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

list_reference_valuesList reference valuesB
Read-onlyIdempotent

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.

NameRequiredDescriptionDefault
idNoFor countries or regions: fetch this one record
listYesWhich reference list
queryNoCase-insensitive match on name
locale_codeNoFor restriction_types: the IETF BCP 47 locale for names (e.g. en-GB)
max_resultsNo
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

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered by structured data. The description adds domain context (countries carry public holidays, regions carry event venues; single-record retrieval for countries/regions) but says nothing about pagination, rate limits, or the redaction behavior that include_contact_details controls.

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?

Two sentences, front-loaded with what the tool returns, and the trailing clause about id-based single-record fetches is placed where it matters. The parenthetical list of list-names is somewhat long but serves as concrete scope evidence rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing return shape, and it only gestures at it ('an id fetches one record') without saying whether lists return id/name pairs or full objects. Combined with a 23-value enum and six parameters, the definition is adequate but leaves an agent guessing about response format.

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

Parameters3/5

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

Schema description coverage is 83%, so the baseline is 3, and the description largely restates the schema's own id semantics ('an id fetches one record'). It does usefully name several of the list values and clarifies that payment_providers is distinct from payment_methods, but it does not explain query, max_results, or locale_code behavior beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (AppyWay reference data / lookup lists) and explains what the values are for: the numeric ids consumed by other tools. An agent can tell it is a taxonomy lookup rather than a rule/geometry tool. It does not, however, distinguish itself from the sibling list_authorities, which is also a list-style tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'the numeric ids used by the other tools' implicitly tells the agent to call this to resolve ids before using other endpoints, which is real usage context. There are no explicit when-to-use conditions, no exclusions, and no routing advice relative to list_authorities or get_parking_entity.

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

pingCheck the API keyA
Read-onlyIdempotent

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.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real behavioral value beyond them by disclosing that it fans out to three named API sections and returns per-section reachability, which is not inferable from the annotations or the empty schema.

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

Conciseness5/5

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

Two sentences, both front-loaded with the essential fact first and the actionable trigger second. Every clause earns its place; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description adequately conveys the return shape ('reports which ones this API key can reach'). For a zero-parameter, read-only diagnostic whose annotations carry the safety profile, nothing an agent needs in order to call it correctly is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter hints are present.

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 mechanism ('Calls GET /ping on each AppyWay API section') plus the outcome ('reports which ones this API key can reach'). This clearly distinguishes it from all domain-data siblings like find_parking_rules_near or list_authorities, which fetch business data rather than test reachability.

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?

Provides a clear triggering condition: 'Use it first when other tools report 401 or 403.' That tells the agent when to reach for this tool versus the siblings. It does not state an explicit when-not or offer other alternatives, so it falls short of the top tier but is well above the bare-context threshold.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv0.1.0
    • First observedfetch_kerb_segments
    • First observedfind_parking_rules_near
    • First observedget_authority_restrictions
    • First observedget_parking_entity
    • First observedget_zone_rules
    • First observedlist_authorities
    • First observedlist_reference_values
    • First observedping
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

Resources

Related MCP Connectors

Related MCP Servers

  • parknyc-mcp

    ltyu
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables managing NYC parking sessions, vehicles, and zones through MCP clients using the ParkNYC/Flowbird API.
    -

  • ultimate-travel-agent

    Gustor1
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP clients to access 21 read-only tools for local travel planning, including trip and itinerary validation, budget calculation, booking requirements, integration provider status, flight/train/accommodation/activity searches, route/weather/currency lookups, and travel source search.
    MIT