Skip to main content
Glama

heritage_narration

Three to five short spoken lines an hour about the ground a route is on: one sentence, at the point the driver reaches the thing it is about, and then silence. Not a tour and not a chatbot. NOTHING IS GENERATED HERE: every line is a sentence a person wrote from a public-domain plaque inscription and a person reviewed, compiled into the gateway binary, so no model runs in this path and the lines are identical for every driver. Give geometry_polyline6 from the route tool and, IMPORTANT, duration_s from the same answer: without it the silence budget falls back to a distance, and "four lines an hour" is a claim about time that a distance answers wrongly at both ends. Optional min_gap_s, min_gap_m, max_offset_m (default 60, hard ceiling 80), max_lines and voice_format ("opus" or "m4a", which adds each line's audio cache key and URL and NEVER synthesises). COVERAGE IS ONE CORRIDOR, deliberately: the Chelsea riverside, 18 reviewed lines over 5 km. EVERY OTHER ROUTE ANSWERS WITH NO LINES, and that is a correct answer rather than a failure. ALWAYS READ THE CENSUS, which is the record of WHAT WAS NOT SAID: no lines with every entry in beyond_reach means this feature does not cover the journey; no lines with entries in silenced_by_budget means the corridor is covered and the budget is holding them back. They are different answers and must never be relayed the same way. On the reference route the census reports 1 spoken and 17 silenced, which is the design working, not a thin corpus. Every line publishes offset_m, the measured distance from the plaque to the route, because it is the entire warrant for the word "here", and plaque_ids so any claim can be taken back to its source. TWO OMISSIONS ARE DELIBERATE: no line says anything is visible, still standing or unchanged (a plaque records that somebody was somewhere, and nothing more), and NO LINE SAYS WHICH SIDE OF THE ROAD anything is on, because nothing in the source records it and a look that finds nothing spends the driver's trust in everything else. Do not add either. COSTS 1 UNIT a call: it reads no tiles and opens no archive. Requires the MapMap gateway (GATEWAY_URL + GATEWAY_API_KEY).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_linesNoCeiling on how many lines come back, 1 to 50 (default 12).
min_gap_mNoLeast distance between two lines, metres (default 400). A floor under the time budget in every case.
min_gap_sNoLeast time between two lines, seconds (default 900, which is four an hour). Applied only with `duration_s`.
duration_sNoThat route's own duration, seconds: `duration_s` from the same answer. **Supply it.** Without it the silence budget falls back to a distance, and "three to five lines an hour" is a claim about time that a distance answers wrongly at both ends.
max_offset_mNoHow near a plaque must come to the route before its line may be spoken, metres (default 60, hard ceiling 80).
voice_formatNoContainer to address each line's audio clip in: `opus` or `m4a`. Given, every line gains a `clip` with its synthesis cache key and URL. It NEVER synthesises: the key is a pure function of the sentence, so asking here buys nothing.
geometry_polyline6YesThe route shape, precision-6 encoded: `geometry_polyline6` straight out of the `route` tool's answer.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
linesYesThe lines, in route order. Empty is the ordinary answer nearly everywhere: read `census` before saying anything about it.
caveatYesThe standing limits, for relaying to users.
censusYesThe census of what was NOT said: `corpus_entries`, `within_reach`, `beyond_reach`, `spoken`, `silenced_by_budget`, the gap that was applied and what it was derived from. An empty `lines` with every entry in `beyond_reach` means this feature does not cover the journey; an empty `lines` with entries in `silenced_by_budget` means the budget is working. They are different answers and must not be reported the same way.
corridorYesThe corridor that was consulted: its id, name, the road it runs on and the date its lines were reviewed.
attributionYesThe licence notice for this answer.
route_length_mYesThe route's own length, metres.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

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 fully carries the behavioral burden and does so exceptionally: no model runs, lines are pre-reviewed and identical for every driver, audio is never synthesised, deliberate omissions are listed, census semantics are explained, and the cost/unit and gateway requirement are stated. This is far beyond typical disclosure.

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 description is long and emphatic, but nearly every sentence earns its place by preventing a specific misuse or misinterpretation. The all-caps warnings hurt readability slightly, and the single dense paragraph could be better structured, but it remains information-dense 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?

For a tool with unusual coverage limits, silent-failure semantics, and deliberate omissions, the description is complete: it covers inputs, output expectations, coverage scope, census interpretation, cost, authentication gateway, and what not to add. Since an output schema exists, the tool's return structure does not need to be spelled out in the description.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: `geometry_polyline6` and `duration_s` must come from the same `route` answer, and it explains why `duration_s` changes the silence budget from a distance to a time. It reinforces defaults and the no-synthesis meaning of `voice_format` beyond the schema's isolated descriptions.

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 deliverable ('three to five short spoken lines an hour'), ties it to a concrete resource (the route ground and plaque inscriptions), and sharply distinguishes it from a tour or chatbot. It also states the deliberate single-corridor coverage, which prevents an agent from treating it as a general narration tool.

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?

The description gives explicit operational context: feed it `geometry_polyline6` and `duration_s` from the same `route` answer, and interpret no-lines as a correct answer outside the Chelsea corridor. It does not name a specific sibling alternative, but 'not a tour and not a chatbot' plus the corridor coverage effectively bounds when it should be chosen.

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.

Resources