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 has a clearly distinct resource and action: account status, point elevations, elevation profiles, forward geocoding, reverse geocoding, query examples, and raw Overpass queries. The closest pair, elevation_points and elevation_profile, is separated by batch point lookup versus path sampling with summary statistics.
All tool names follow the same snake_case domain_action pattern: account_status, elevation_points, elevation_profile, geocode_reverse, geocode_search, overpass_examples, overpass_query. The convention is predictable and readable throughout.
Seven tools is well scoped for a geospatial/OpenStreetMap API surface. Each tool covers a distinct workflow and none appears redundant or filler.
The set covers the core workflows: account usage, forward and reverse geocoding, point and path elevation, example discovery, and full Overpass querying. Minor gaps exist, such as no explicit batch geocoding tool or direct feature-detail endpoint, but overpass_query can handle many of those cases.
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?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses what the annotations cannot: the per-region data sources (swissALTI3D 2 m, Copernicus GLO-30 30 m, GEBCO at sea), the crucial difference that GLO-30 measures surface including buildings and trees while swissALTI3D measures ground, a legally required attribution ("© swisstopo"), and the billing model where one point equals one lookup.
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 sentences, front-loaded with the definition and output unit, then the source/accuracy caveats, then the cost model. Every sentence carries distinct information, including the attribution obligation, with no 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 geospatial lookup with no output schema and only two parameters, the description covers the important unknowns: units, sign, vertical datum caveats by source, and quota behavior. It leaves secondary details (whether results preserve input order, how out-of-coverage or sea-adjacent points are reported) unstated, which keeps it from a 5.
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 lat/lon bounds and max_chars are already documented; the baseline would be 3. The description earns an extra point by explaining that each element of `points` is charged as a lookup and that account_status reveals the per-call plan maximum, which is quota semantics the schema cannot express.
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?
"Heights above sea level in metres for a list of points" names a specific resource and output unit, and "negative at sea" pins down the sign convention. It implies the contrast with elevation_profile (a list of discrete points rather than a sampled line) but never names that sibling explicitly, so an agent must infer the boundary.
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 qualifying clause "for a list of points" hints at when this is the right tool over elevation_profile, and the lookup/plan-maximum note signals a cost constraint per call. There is no explicit when-to-use or when-not-to-use statement and no named alternative, so guidance stays implied.
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 declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context: a 90 m default sampling interval, an override mechanism, a 100-point return cap, and a per-sample quota cost that can hit the plan maximum per call.
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 sentences, each earning its place: returns first, sampling default second, cost third. No output schema exists, so enumerating the returned fields is necessary rather than redundant.
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 correctly carries the return-value burden and adds the quota constraint. Remaining gaps are the truncation behavior above 100 points and the precedence rule between the two sampling parameters.
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, and the description only partially goes beyond it by explaining that `samples` or `interval_m` replace the 90 m default. It does not clarify what happens if both are set simultaneously, nor how `samples` interacts with the 100-point cap.
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+resource (elevation profile) and scopes it to "a path of two or more points," which implicitly separates it from the sibling `elevation` tool for single points. It also enumerates exactly what is computed: distance, ascent, descent, lowest/highest point, and per-sample distance/height/lat/lon.
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 explains sampling defaults and the cost model ("each sample counts as one lookup, up to the plan maximum"), which tells the agent how to use it economically. However, there is no explicit when-to-use routing versus the `elevation` sibling, and no stated precedence when both `samples` and `interval_m` are supplied.
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?
Annotations already declare read-only, idempotent, non-destructive and closed-world. The description adds two pieces of context the annotations don't carry: that 'one call counts as one geocoding request' (quota/cost) and that the result matches geocode_search's fields (return shape, useful with no output schema). Neither rate limits nor error behavior are covered.
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 sentences, front-loaded with the core operation, then the detail semantics, then cost and return-shape notes. The middle enumeration is long but each level earns its place; the only friction is the slightly awkward 'same fields as those of geocode_search' phrasing.
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 compensates by pointing to geocode_search for the result shape, and it discloses quota cost. All four parameters are accounted for between schema and description. A note on what happens when no address exists at the point (empty result vs. nearest fallback) is the main missing piece.
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 meaning beyond the schema: it documents the default for detail ('address, the default') which the schema does not, and explains that street/district/city/county/state/country are the containing units of the point. It says nothing about the language parameter, which is left 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 ('Finds the address or place at a point') and names the operation type (reverse geocoding), which cleanly separates it from geocode_search, which goes the other direction. It references geocode_search only for output fields, so the differentiation is implicit rather than spelled out.
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 reverse-geocoding framing makes the use case (you have coordinates, you want a place name) clear, and the detail parameter is described as a choice among levels. No explicit when-not-use or named alternative (geocode_search for forward lookups) is given, so the exclusion side is missing.
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 | |
| 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?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds real behavioral context: it enumerates the return payload (name, address, lat/lon, bounding box, osm element, overpass_area_id) and discloses a quota cost ('One call counts as one geocoding request'). It does not say what happens on zero matches or how results are ranked, which keeps it out of the top band.
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?
A single dense but well-ordered block: purpose first, then matching behavior, then result shape, then the overpass hand-off, then language list, then quota. It is slightly run-on and the trailing language sentence duplicates the schema enum, but nothing is seriously wasted.
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 correctly compensates by describing the result fields, including the bounding-box ordering (south, west, north, east) that the nudge toward overpass_query depends on. For a 7-parameter, nested-object tool it is close to complete; missing only failure/empty-result behavior and relevance ordering.
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 kind, near, within, limit, language, country_codes and query. The description adds one genuine clarification beyond that – partial/substring matching on the query string – but otherwise restates the language enum and describes return values rather than input semantics. 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?
Opens with a specific verb and resource ('Finds places, addresses and points of interest by name (geocoding)'), which is clearly forward geocoding and implicitly the complement of geocode_reverse. It stops short of naming the sibling it contrasts with, so an agent must infer the forward-vs-reverse split.
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?
'Partial text works, as for autocomplete' tells the agent how to phrase queries, and the note that the returned overpass_area_id should be passed to overpass_query as area(id:N) gives a concrete hand-off to a sibling tool. However, there is no explicit statement of when to prefer this over overpass_query or geocode_reverse, and no exclusion conditions.
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. Free: 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 readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds real value by disclosing the return shape ("the 5 closest examples with their query and a link") and the quota behavior ("Free: it does not count as a request"). What remains unstated is how "closest" relevance is determined or what happens when no examples match.
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, both front-loaded: the identity of the tool first, then the input/output contract. The example list is compact and each example maps to a distinct query pattern, so no sentence is wasted.
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 single-parameter, read-only lookup tool with no output schema, the description supplies everything needed: what it searches, what to pass, what comes back, and that it costs nothing against quota. 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?
Schema coverage is 100% and the schema already describes topic as "what the query should find, in a few English words." The description goes beyond that by giving four concrete example topics and the "in a few words" format expectation, which helps the agent phrase a good input rather than just understand the field.
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?
"Searches the cookbook of overpass.ch: Overpass queries that were tested on the full planet" gives a specific verb (searches) and resource (a curated example-query cookbook), and the contrast with executing queries is implicit in the wording. It does not name the sibling overpass_query explicitly, so the differentiation from that tool is left to inference rather than stated.
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 concrete sample topics ("bakeries in a city", "hiking routes", "count buildings", "changes since a date") that show what kinds of inputs this tool is meant for, and notes it is free, nudging the agent to try it before composing a query. It stops short of explicitly saying "use this before calling overpass_query" or stating when-not to use it.
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?
Beyond the annotations, the description discloses operational behavior: minutely data freshness, a 120-second maximum timeout that may be lower on the plan, output shape starting with counts and data date, per-element JSON lines, truncation at max_chars, continuation via offset, and that every call including a cut one counts as one plan request. It also notes the ODbL attribution requirement. This is rich behavioral context that annotations alone do not provide.
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 description is front-loaded with the core behavior, then organized into a compact settings paragraph and a useful pattern list. Despite its length, every section earns its place by covering query construction, truncation, cost, and licensing for a complex query language.
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, but the description explains the return format, the date and count prefix, JSON-line output, truncation behavior, timeout limits, request cost, and historical-data availability. For a complex query tool, this provides everything an agent needs to invoke it correctly.
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 for query syntax and for offset as the continuation point when an answer is cut, and for max_chars as the truncation threshold. It does not explain add_elevation beyond what the schema already says, so it is not a 5.
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 states a specific verb and resource: it runs an Overpass QL query against the full OpenStreetMap planet at overpass.ch and returns matching nodes, ways, and relations with tags. This is specific enough to distinguish it from sibling tools such as overpass_examples, geocode_search, and elevation_points.
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 usage context through query patterns for boxes, radii, areas, names, counts, tags, geometry, regex, IDs, and historical dates. It also explains that a cut answer should be continued with offset or narrowed, and points to geocode_search for area IDs. It does not explicitly compare when to use this tool versus overpass_examples, which keeps it below a 5.
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.
elevationelevation_pointsgeocodegeocode_reversegeocode_searchreverse_geocodeaccount_statuselevationelevation_profilegeocodeoverpass_examplesoverpass_queryreverse_geocode
Add one secure layer between your agents and this server.