Skip to main content
Glama

check_clearance_on_route

Measure a vehicle's overhead clearance along a route against surveyed point cloud geometry, wherever survey coverage exists. Routes with truck costing (so the search already avoids the height restrictions the map has tagged), then measures that corridor. Give origin, destination and height_m; optional width_m asks the corridor-width axis too, and optional margin_m adds your operating margin to the vehicle before the verdict. Returns pass, fail, indeterminate or no_verdict with the limiting point, the measured headroom, its uncertainty bound (safe_headroom_m, sigma_m, sampling_gap_m) and a link to that exact view in the survey viewer. An indeterminate carries indeterminate_reasons as codes to branch on and the same reasons as English inside explanation; read out the English. A pass may carry no limiting point at all, which means the survey found nothing above that corridor, and the width axis may answer not_assessed where the corridor edges are too sparsely surveyed while the height axis still answers. Honesty, and it matters here: this measures physical geometry from a dated survey. It is not a signed or posted height, clearance_enforcement.route_certified is always false, and the caveat is on every answer including the clear one. Ground the survey did not cover comes back as not_surveyed_m and is never judged, so a pass is possible over complete coverage and nowhere else; sparse or stale coverage comes back separately as insufficient_data_m. Reach for this when a truck route came back unchanged and you need to know whether that means anything: an unchanged route avoids what the map records, which is a different claim from measured headroom, because a structure nobody tagged is routed through like open road. Needs the MapMap gateway (GATEWAY_URL + GATEWAY_API_KEY), which holds the surveys; there is no fallback, and it will not answer from the routing step alone. The mapmap://guide/clearance resource sets out what each answer proves.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
originYesRoute origin.
width_mNoVehicle width in metres. Supplying it asks the width axis as well as the height axis; the width answer is reported separately and is never a headroom.
height_mYesVehicle height in metres. Required: there is no default vehicle, because a default vehicle is how somebody gets an answer about a lorry that is not theirs.
margin_mNoOperating margin in metres, added to the height before the verdict is decided (default 0). Your compliance policy, not ours: the measured figure and the safe bound are both reported whatever you set here, and the margin is echoed back. It is applied to the measurement, not to the routing step, where the map's own posted heights already carry a margin of their own.
destinationYesRoute destination.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
basisYesAlways `"surveyed_geometry_not_signage"`.
widthYesThe width axis, answered separately when `width_m` was given.
verdictYes`pass`, `fail`, `indeterminate` or `no_verdict` for the height axis. A `pass` is possible over completely surveyed ground and nowhere else: unsurveyed ground yields `no_verdict`, never a pass.
datasetsYesThe surveys drawn on, with their capture dates and staleness.
limitingNoThe limiting point on a `fail`, the tightest point on a `pass`, the worst contested point on an `indeterminate`. Absent on a `no_verdict`, and absent on a `pass` where the survey found nothing at all above the corridor.
view_urlNoDeep link to that exact view in the survey viewer, so the reading can be looked at rather than taken on trust.
advisoriesYesNotes on stretches of the route: vegetation age, a reading limited by a wire, a seam between surveys.
assessed_mYesMetres of route measured against survey data good enough to decide on.
explanationYesWhat was measured, when, with what bound, and what the tool declined to conclude. It may over-restrict; it never under-restricts.
not_surveyed_mYesMetres of route no survey covers. This is the absence of a measurement, and it is never the same statement as a measured open sky. No verdict is drawn over it.
resolution_hintNoWhat would resolve an `indeterminate`, in one sentence, as the measuring service phrased it.
route_distance_mYesLength of the route the vehicle was routed over, metres.
route_duration_sYesEstimated driving time for that route, seconds.
geometry_polyline6YesThe route as a six-digit-precision encoded polyline, so the same shape can be drawn or re-measured without routing again.
insufficient_data_mYesMetres of route a survey covers but too sparsely, or too stale, to decide on. Also an absence, and reported apart from `not_surveyed_m` because the two have different remedies.
clearance_enforcementYesWhat this answer does and does not prove. Read it.
indeterminate_reasonsYesWhy an `indeterminate` could not be called, as machine-readable codes (`inside_uncertainty_band`, `vegetation_age_exceeded`, `artefact_stale`, `artefact_freshness_unchecked`). Empty on every other verdict. These are for branching on, not for reading out: the same reasons appear as English in `explanation`, and a person shown `artefact_freshness_unchecked` has been failed by whatever displayed it.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses dated-survey limitations, that route_certified is always false, how coverage gaps return not_surveyed_m and insufficient_data_m, and how pass/fail/indeterminate/no_verdict correspond to physical evidence. It even flags that a pass may have no limiting point and that width can return not_assessed.

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?

The purpose is front-loaded and nearly every sentence adds functional or caveat information. It is quite long and has rhetorical and grammatical turns ('Honesty, and it matters here'; 'Routes with truck costing... then measures that corridor') that keep it from being optimally concise.

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?

Given the tool's complexity and the lack of annotations, the description is remarkably complete: it names all required and optional inputs, explains verdict semantics, uncertainty fields, coverage handling, authentication requirements, and where to find further guidance. An agent has enough information to call the tool correctly and interpret all answer types.

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 schema already covers parameters at 100%, so the baseline is 3. The description adds useful meaning by explaining that margin_m is applied to the measurement rather than the routing step, that width_m is reported separately and never as headroom, and that there is no default vehicle height, though it adds little new detail for origin and destination.

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 first sentence states a specific verb and resource: 'Measure a vehicle's overhead clearance along a route against surveyed point cloud geometry.' It also distinguishes itself from map-tagged height restrictions and sibling tools like check_adr_tunnel by clarifying it measures physical surveyed geometry, not posted or signed heights.

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 a concrete trigger: 'Reach for this when a truck route came back unchanged' and states prerequisites (MapMap gateway, no fallback). However, it does not explicitly name an alternative sibling tool or say 'do not use this for posted height checks,' so the when-not guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools target a distinct action and resource pair, and descriptions are explicit about which tool fits which scenario. The closest overlaps—plan_ev_route vs cheapest_charging_along_route, and route vs plan_day vs order_stops vs optimise_routes—are mitigated by clear guidance, so an agent can usually pick correctly.

Naming Consistency4/5

Tool names overwhelmingly follow a verb_noun snake_case pattern (plan_ev_route, set_palette, list_style_layers) with a consistent geo_ prefix for geometry helpers. Minor deviations like elevation, route, and matrix are short and readable but break the strict verb_noun convention.

Tool Count2/5

At 39 tools, this surface is well past the 25+ threshold and feels heavy even for a broad mapping platform. The set spans routing, geocoding, places, styles, EV/fuel, telematics, usage, and feedback, which would be easier for an agent to navigate if split into smaller domain-focused servers.

Completeness4/5

For the stated breadth, coverage is strong: routing, multi-stop planning, VRP, EV/fuel detours, geocoding, places, geometry, style lifecycle, and telematics all have workable primary paths. Minor gaps like no style deletion, no route alternatives, and no batch geocoding are present but do not create dead ends for core workflows.

Resources