Skip to main content
Glama
dragosh29

AppyWay MCP server

by dragosh29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

List local authorities

list_authorities
Read-onlyIdempotent

Fetches UK local authority details and access status based on API key entitlements. Use a point, bounding box, or name query to find covering authorities and their payment providers.

Instructions

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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.

Deploy Server

Other Tools