Query OpenStreetMap data for the whole planet with the Overpass API, find places by name and look up heights. Minutely updates, history back to 2012.
Scored across 7 tools
Each tool targets a distinct capability: quota/plan info (account_status), point heights (elevation_points), path profiles (elevation_profile), forward and reverse geocoding, an example cookbook, and raw Overpass QL execution. The only near-neighbours — elevation_points vs elevation_profile and geocode_search vs overpass_query — are clearly separated by descriptions (list of points vs sampled path; name lookup vs tag/geometry query). No tool appears redundant.
All names are snake_case and follow a predictable domain-prefix pattern: account_*, elevation_*, geocode_*, overpass_*. Within each family the suffix identifies the operation or resource, so an agent can guess the right family before reading descriptions.
Seven tools is well-scoped for an OSM query service with geocoding and elevation add-ons. Each tool earns its place: no thin single-purpose wrappers, and the auxiliary tools (account_status, overpass_examples) support the core query tools rather than duplicating them.
The read-only surface is largely complete: forward/reverse geocoding, point and profile elevation, area-id handoff between geocode_search and overpass_query, example discovery, and quota awareness. Minor gaps remain — no direct single-element detail or batch/multi-query convenience tool, and geometry retrieval only via out geom inside a full query — but agents can work around these.
The plan of the API key of this connection and its use this month: Overpass requests used and left, when the allowance starts again, running queries, elevation lookups, geocoding requests, and the date of the data. It names the products on a free plan, which is not for commercial use. It does not count as a request.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world. The description adds genuinely useful behavior beyond them: calling it 'does not count as a request', so it does not consume the very quota it reports, and it discloses free-plan/commercial-use constraints on the named products.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but the middle is a dense comma list with loose grammar ('its use this month', 'the date of the data'), and the free-plan sentence is confusingly worded. Content earns its place; the phrasing is harder to parse than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 burden of describing returns and does so by enumerating the reported metrics and reset timing. For a zero-parameter read-only status tool this is nearly complete, missing only units or format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4; the schema is trivially complete and needs no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource — the API key's plan and monthly usage — and enumerates what is reported (Overpass requests used/left, reset time, running queries, elevation, geocoding, data date). It is clearly a diagnostics/status tool, distinct from the query siblings, though the phrasing 'its use this month' is slightly awkward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the tool to check quota or plan before issuing heavy queries. There is no explicit 'use this when...' or reference to alternatives, but none of the siblings overlap in purpose, so the risk of misselection is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heights above sea level in metres for a list of points, negative at sea. Switzerland and Liechtenstein: swissALTI3D, a 2 m grid of the ground (credit "© swisstopo"). Elsewhere on land: Copernicus GLO-30, a 30 m grid of the surface that includes buildings and trees. At sea: GEBCO. Each point counts as one lookup; account_status shows the plan maximum per call.
| Name | Required | Description | Default |
|---|---|---|---|
| points | Yes | the points, each with lat and lon | |
| max_chars | No | most characters of the answer to show; larger answers are cut, and offset shows the next part |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, open-world, idempotent, non-destructive), yet the description adds genuinely non-obvious behavior: source dataset and resolution per region (swissALTI3D 2 m ground grid vs Copernicus GLO-30 30 m surface including buildings and trees vs GEBCO at sea). It also discloses the attribution obligation ('© swisstopo') and the cost model (each point is one lookup, plan maximum shown by account_status), which are real operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the purpose before regional data-source detail and the cost note. Every sentence carries information, though the data-source sentence is long and packed into a single run-on structure that could be split for scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description responsibly states units, sign convention and the responsible data source per region, so an agent knows what comes back and how accurate it is. Gaps remain around behavior for points outside coverage or ocean-vs-land edge cases and what happens on partial failures, but nothing essential for calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so lat/lon ranges, the array shape and max_chars truncation/offset semantics are already fully documented in the schema. The description adds only the accounting meaning of a point ('each point counts as one lookup'), which is modest value beyond the structured fields; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: heights above sea level in metres for a list of points, including the sign convention (negative at sea). It is clear what the tool returns, but it never distinguishes itself from the sibling elevation_profile, which an agent could plausibly pick for a similar-looking task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: 'a list of points' suggests discrete point lookups versus a profile, and the per-point lookup accounting hints at batching considerations. There is no explicit when-to-use / when-not-to-use statement and no named alternative, leaving the agent to infer the boundary with elevation_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Elevation profile along a path of two or more points: distance, ascent, descent, the lowest and the highest point, and up to 100 points along the way (distance from the start, height, lat, lon). The path is sampled every 90 m unless samples or interval_m is set. Each sample counts as one lookup, up to the plan maximum per call.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | the points of the path in order, each with lat and lon | |
| samples | No | number of samples along the path | |
| interval_m | No | metres between samples, at least 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the description correctly focuses elsewhere: it discloses the default 90 m sampling interval, the roughly 100-point cap on returned samples, and the cost model ('each sample counts as one lookup, up to the plan maximum per call'). That quota/cost disclosure is exactly the kind of context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: output shape first, then default sampling, then cost. Dense but no filler; the only minor ambiguity is the 'up to 100 points' cap, which sits uneasily next to a samples parameter with no maximum in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return-value burden and does so by naming every returned field. Combined with the sampling and quota notes, an agent has enough to call it correctly; only mutually-exclusive behavior of samples vs interval_m is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics the schema lacks: the implicit 90 m interval when neither samples nor interval_m is supplied, and the cap on output points. It stops short of explaining precedence when both samples and interval_m are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (elevation profile) and scope (a path of two or more points), and enumerates the returned values (distance, ascent, descent, min/max, sampled points). It does not explicitly distinguish itself from the sibling elevation_points (single-point lookups), leaving that inference to the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the requirement of a path with at least two points, and the default sampling behavior (90 m unless samples or interval_m is set) is stated. However, there is no explicit when-not-to-use guidance or named alternative such as elevation_points for single locations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the address or place at a point (reverse geocoding). detail chooses what to return: the nearest address or object (address, the default), the street, the district, the city, the county, the state or the country that contains the point. The result has the same fields as those of geocode_search. One call counts as one geocoding request.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | latitude, -90 to 90 | |
| lon | Yes | longitude, -180 to 180 | |
| detail | No | what to return | |
| language | No | language of the names and addresses; the local names when not set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent/open-world annotations, it discloses that each call consumes one geocoding request, which matters for quota planning, and explains how detail controls result granularity. It does not mention error or not-found behavior for points with no address.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the operation and then the detail semantics; four sentences with little waste. The quota sentence could arguably be its own trailing note, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter lookup with no output schema, the description covers purpose, the key enum's meaning, result shape (via reference to geocode_search) and cost. Relying on a cross-reference to a sibling to understand return fields is the only soft spot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baselines are already met by structured fields, but the description adds real meaning for the terse 'what to return' enum by spelling out each detail level (address, street, district, city, county, state, country). lat/lon and language add nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("finds the address or place at a point") and parenthetically names the operation class ("reverse geocoding"), which immediately separates it from geocode_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this applies: you have a coordinate and want the containing address/place. It names the sibling geocode_search only to describe result fields, not as an explicit alternative, and offers no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds places, addresses and points of interest by name (geocoding). Partial text works, as for autocomplete. Each result has the name, the address, lat and lon, a bounding box (south, west, north, east), the OpenStreetMap element (osm), and for ways and relations an overpass_area_id to use in overpass_query as area(id:N). Languages: en, de, fr. One call counts as one geocoding request.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | only places of this kind; settlement is a city, town, village or district | |
| near | No | prefer results near this point, such as a place named in the conversation | |
| limit | No | most results | |
| query | Yes | what to find, such as "Bundesplatz 3, Bern", "Zermatt" or "Louvre" | |
| within | No | ||
| language | No | language of the names and addresses; the local names when not set | |
| country_codes | No | only results in these countries, ISO 3166-1 alpha-2 codes such as CH or DE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is handled. Beyond that, the description adds real behavioral context: quota semantics ("One call counts as one geocoding request"), the result fields, the bounding-box ordering, and the cross-tool overpass_area_id handoff. It stops short of describing no-result or error behavior, which keeps it at a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first clause, and the remaining sentences each carry useful information about results and quota. The only waste is the sentence "Languages: en, de, fr", which merely repeats the enum already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, nested objects and no output schema, the description compensates well by enumerating the return fields (name, address, lat/lon, bounding box, osm, overpass_area_id). The main gap is that the geographic filters near and within are left entirely to the schema, so the definition never states how those actually narrow the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the schema already documents each parameter, including the enum values and the nesting of near and within. The description adds a little meaning about partial-match behavior for query and the effect of language, but it never explains near, within, limit, kind or country_codes. With the schema doing most of the work, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Finds places, addresses and points of interest by name (geocoding)." The phrase "by name" also implicitly distinguishes it from the sibling geocode_reverse, so an agent can choose between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes the usage context well: "Partial text works, as for autocomplete" tells the agent this is suitable for incremental or fuzzy lookups. It also documents a downstream handoff (overpass_area_id to use in overpass_query as area(id:N)). However, it never states when NOT to use it or explicitly names geocode_reverse/elevation_points as alternatives, so there is no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the cookbook of overpass.ch: Overpass queries that were tested on the full planet, with explanations. Give a topic in a few words, such as "bakeries in a city", "hiking routes", "count buildings" or "changes since a date", and get the 5 closest examples with their query and a link. It does not count as a request.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | what the query should find, in a few English words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description does not need to restate them. It adds two pieces of genuine behavioral context the annotations cannot convey: the result shape ('5 closest examples with their query and a link') and the quota note 'It does not count as a request', which matters for rate-limited agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The core action is front-loaded, the topic examples sit next to the instruction that uses them, and the closing quota note is a single short clause rather than a paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by stating exactly what comes back (five closest examples, each with its query and a link). For a one-parameter, read-only lookup tool, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one fully documented parameter, the schema already carries the mechanics, so the baseline is 3. The description adds real meaning by specifying the expected input form — a topic in a few words, in English — and by illustrating the granularity expected through four sample topics, which the schema's terse 'in a few English words' does not fully pin down.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Searches the cookbook of overpass.ch') plus the concrete payoff ('get the 5 closest examples with their query and a link'). Combined with the title, an agent can tell this apart from overpass_query, which actually runs a query, without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended context is clear: supply a short topical phrase and receive example queries, which implies using this to learn query patterns before running overpass_query. Four concrete topic examples ('bakeries in a city', 'hiking routes', 'count buildings', 'changes since a date') make invocation easy. It stops short of an explicit 'use this instead of / before overpass_query' routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs an Overpass QL query on the full OpenStreetMap planet at overpass.ch (minutely updates) and returns the matching nodes, ways and relations with their tags. Start the query with a settings line such as [out:json][timeout:25]; JSON is used when the query does not set [out:]. [timeout:N] stops the query after N s: at most 120 s through this tool, and the plan may allow less. Patterns:
Box (south,west,north,east): nwr"amenity"="cafe"; out center;
Radius in metres around lat,lon: nwr"amenity"="pharmacy"; out center;
In a place: overpass_area_id from geocode_search, then area(id:3600051701)->.a; nwr"tourism"="hotel"; out center;
By name (exact, local language): area["name"="Wien"]["admin_level"="4"]->.a;
Count: out count; Tags only: out tags; At most 50: out center 50; Lines with coordinates: out geom; (large)
Regex, any case: ["name"~"^Bahnhof",i]
By id: node(3470507586); out; way(id:1,2,3); out tags;
The map at a past date (Medium and Large plans): [date:"2015-01-01T00:00:00Z"] in the settings line. The answer starts with counts and the date of the data, then one JSON object per element and line, up to max_chars characters. When it is cut, call again with offset, or narrow the query. Each call counts as one request of the plan, a cut one too. Data © OpenStreetMap contributors, ODbL.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | the Overpass QL (or XML) query | |
| offset | No | the element (or CSV row) to start at, for the next part of a cut answer | |
| max_chars | No | most characters of the answer to show; larger answers are cut, and offset shows the next part | |
| add_elevation | No | add the height in metres to every point of a JSON answer; one elevation lookup per point |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses the 120 s timeout ceiling and that the plan may allow less, that every call including a truncated one consumes a plan request, and exactly how truncation works with offset to resume. It also states the answer's leading counts and data date, and the ODbL attribution requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then timeout, then a scannable pattern list, then return/truncation behavior. Dense and nearly every line earns its place, though the pattern list is long enough that an agent must read past a lot of syntax examples to reach the output-behavior details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description explains the response format (counts, data date, one JSON object per element per line, cut at max_chars) and the resume procedure. For a single-complex-parameter open-world query tool, nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning: it explains the settings line and [out:] default, the query forms the query string may take, and the resume relationship between max_chars and offset. Only add_elevation is left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Runs an Overpass QL query on the full OpenStreetMap planet") plus the return shape ("matching nodes, ways and relations with their tags"). It also anchors freshness ("minutely updates") and names the sibling geocode_search as the source of area ids, so the agent can place it among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage patterns and routes one dependency explicitly ("overpass_area_id from geocode_search"), plus plan/date caveats (date filter only on Medium and Large plans). It stops short of saying when to prefer overpass_examples or geocode_search instead of this tool, so selection guidance is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
geocode_search1 field changedInput schema / properties / near / descriptionPrevious value: -"prefer results near this point"New value: +"prefer results near this point, such as a place named in the conversation"elevationelevation_pointsgeocodegeocode_reversegeocode_searchreverse_geocodeaccount_statuselevationelevation_profilegeocodeoverpass_examplesoverpass_queryreverse_geocode
Add one secure layer between your agents and this server.