Skip to main content
Glama

find_speed_cameras

Read-onlyIdempotent

Find published speed-enforcement locations by town, street, or coordinates for trip planning, including fixed and red-light cameras, section control, and announced mobile checks with the StVO notice.

Instructions

Returns a town's published speed-enforcement locations (fixed and red-light cameras, section control, announced mobile checks, measuring sites) by kind and street, with the § 23 Abs. 1c StVO notice. Use when someone plans a trip and asks where speed cameras are ("Blitzer Köln"). Planning only — show the notice verbatim. If they say they are driving now: show the notice, offer the list for before the trip or a stop. Never read locations to a driver, never a live warning. Do NOT use for speed limits (get_driving_rules) or roadworks (check_road_status). Area ≤ 25 km. Shows the attribution line.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude in WGS 84, e.g. 48.137. Use with lon when the caller already holds coordinates; otherwise use place.
lonNoLongitude in WGS 84, e.g. 11.576. Use with lat; otherwise use place.
limitNoHow many locations to list (1–50, default 20); the answer says how many more the area holds.
placeNoWhere to look, as free text: a city ("München", "Munich"), a district or Kreis ("Kreis Fulda"), a Bundesland, a station or stop ("Hamburg Hbf"), a motorway junction ("AK Neufahrn"), or a street address with a house number ("Bahnhofstraße 12, 36037 Fulda"). A motorway number alone ("A7") resolves to the road, which has no single point — name a town or junction on it instead. Use this instead of coordinates whenever the person named a place. An address needs its town or postcode — a street and a number alone exist in many towns. A place or lat+lon is required (unless the tool names another way in, such as a road): when the person named neither, ask them for a town, a postcode or their position before calling. Given both, the answer is about lat+lon with the place as its label, and is refused only when the two lie further apart than the search reaches.
languageNoSet this on every call to the language the person is writing in: "en" if they wrote English, "de" if they wrote German. Do not leave it out: it defaults to German ("de"), which is only the fallback when the language is genuinely unclear, so an English question sent without it is answered in German — a wrong answer. Place names, station names and road numbers are never translated in either language; in English the German term is kept in parentheses so the person recognises it on signs and in local apps.de
radius_kmNoThe area around place or lat+lon, in kilometres (1–25, default 5). An area, not an order: the list is never sorted by distance. Example: 5

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare this a safe, idempotent, closed-world read, so the bar is lower; the description still adds non-obvious behaviour: the mandatory § 23 Abs. 1c StVO notice shown verbatim, the attribution line in the output, the 25 km area cap, and the hard rule never to read locations to a driver or act as a live warning. It does not say what the result payload looks like or how truncation beyond `limit` is surfaced, which keeps it below a 5.

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 what the tool returns, then when to use, then safety constraints and exclusions — a sensible order with no filler. It is dense and reads as a run-on in the safety section (several clauses in one sentence), costing a point on structure but not on substance.

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 still covers scope, the legal notice requirement, attribution, area limit, sibling exclusions, and the driver-safety refusal rule — everything an agent needs to invoke and phrase the result correctly. Nothing material is missing for a read-only lookup of this complexity.

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 explains lat/lon vs. place, the language enum, and the radius. The description only echoes the area cap (≤ 25 km) and the by-kind/by-street grouping, adding little beyond the structured fields — the baseline 3 applies.

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 published speed-enforcement locations), enumerates the kinds covered (fixed, red-light, section control, mobile checks, measuring sites) and the keying (by kind and street). It explicitly rules out the two sibling tools an agent might confuse it with — get_driving_rules for speed limits and check_road_status for roadworks.

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

Usage Guidelines5/5

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

Gives concrete trigger phrasing ("Blitzer Köln"), a temporal condition (planning vs. driving now), and an explicit do-not-use list naming the correct alternatives. It even prescribes the fallback behaviour when the user says they are driving — offer the list for before the trip or a stop — so no routing decision is left to inference.

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