Geodata for any place, inside your agent: map data, terrain, routes, satellite images, GIS files.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
Each tool has a distinct GIS purpose, and descriptions explicitly separate adjacent workflows such as routing, straight-line measurement, and isochrones. Minor overlap remains around buffering (measure radius/buffer vs. process_geometry buffer) and general vs. France-specific building/parcel data, but the boundaries are mostly clear.
Almost all names use snake_case and are descriptive, with a predictable verb_noun style such as convert_coordinates, extract_open_data, get_elevation, and process_geometry. The main deviations are bare measure and the domain-prefixed french_building_heights/french_parcel, but the set remains readable and consistent overall.
Thirteen tools is well within a reasonable range for a broad GIS platform and each tool covers a recognizable, non-trivial capability. The set is scoped without obvious padding or missing basic utility slots.
The surface covers a wide GIS workflow: geocoding, data extraction, coordinate conversion, elevation, imagery, routing, isochrones, cadastral/building data, file conversion, and geometry processing. Minor gaps remain for layer-level reprojection, attribute filtering/query, and spatial joins, but most common tasks have a usable tool path.
Use this when the user gives coordinates and wants them in another system or format: decimal degrees, degrees minutes seconds (GPS), UTM, MGRS, Lambert 93 (EPSG:2154, the French grid) or an EPSG code, for example Lambert 93 to WGS84 latitude and longitude, or GPS coordinates to UTM. The format of each line is detected automatically, including "lat, lon" or "lon, lat"; for a national grid the numbers alone cannot reveal (Dutch RD, Swiss LV95, British National Grid, Polish 1992, Belgian Lambert 72) or a UTM zone given apart from the numbers, set source_epsg. Converts one point or up to 1,000 lines to decimal degrees, DMS, UTM and MGRS (1 m), and optionally to an EPSG code, shows them on a map, and recommends the local projected CRS for working in QGIS. Returns a CSV and a GeoJSON download (both open directly in QGIS). Needs actual coordinates: to explain what a CRS, a projection or an EPSG code is, or to write conversion code, answer without this tool. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | One coordinate per line, up to 1,000 lines. A label may follow the numbers. | |
| source_epsg | No | Optional system the input is in, as an EPSG code, when it cannot be detected: Dutch RD EPSG:28992, Swiss LV95 EPSG:2056, British National Grid EPSG:27700, Poland 1992 EPSG:2180, UTM zone 32N EPSG:32632, ETRS89 or ED50 UTM EPSG:25830 / EPSG:23030. Leave out to detect each line. | |
| target_epsg | No | Optional extra output system as an EPSG code. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered, but the description adds real operational context: the 1,000-line limit, CSV+GeoJSON outputs, that download links build files lazily with nothing saved, and the caution not to feed those links to open_gis_file. It does not describe error handling for ambiguous lines, which keeps it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the 'Use this when...' trigger and packs the format list, detection caveats, output behavior, and exclusions into a dense but non-redundant block. It is long and parenthetical-heavy, which slightly hurts scannability, but nearly every clause earns its place.
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?
Even though an output schema exists (so return values need not be explained), the description covers input formats, detection limits, output artifacts, and the QGIS-oriented recommendation, leaving no material gap for a 3-parameter geospatial conversion tool.
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 genuine routing logic the schema lacks: why source_epsg is needed (national grids the detector cannot disambiguate) and the auto-detection behavior including 'lat, lon' vs 'lon, lat' ordering. target_epsg 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+resource (convert coordinates) and enumerates the exact formats supported (decimal degrees, DMS, UTM, MGRS, Lambert 93, EPSG). It also distinguishes itself from siblings, explicitly routing map/file handling to open_gis_file and CRS explanations away from this tool.
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 explicit when-to-use (user supplies coordinates wanting another system) and explicit when-not (conceptual CRS explanations, writing conversion code). It also documents the trigger condition for source_epsg (national grids like Dutch RD, Swiss LV95 where numbers alone are ambiguous).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants map data or GIS layers for a place or an area anywhere in the world, such as the data of a city, a town, a neighbourhood or a site: buildings, roads, addresses, points of interest (shops, schools, pharmacies), land use, waterways, water areas, railways, transit stops, power lines, protected areas, administrative divisions and boundaries, places or routes. The area is a place, a place with a radius, or a bbox. Returns the count, sample attributes, a map and a file (GeoJSON, KML, Shapefile zip or CSV) with its licence, ready for QGIS. One extract holds at most 20,000 features: for a town centre use a radius of about 1 km, for dense cities less. For one kind of place (pharmacies, schools, supermarkets) or land (forest, vineyards), set kind: the limit then counts that kind only, so a whole city usually fits. For administrative boundaries (a commune, the departments of a region, a country) use divisions with level and the place name, without a radius. One theme per call: extract the layers the user asks for; when they ask for the data of a place without naming a layer, or what data exists for a project, name the useful themes and let them choose before extracting several. Data: Overture Maps and OpenStreetMap. Never use the user's current location unless they type it. Give the place as the user names it (place name, address or coordinates): this tool locates it, so find_places is not needed first. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file: list every format the user needs in formats, in this one call.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | The area: a bbox, or a place (name, address or coordinates) with an optional radius in metres. The place the user asks about, not the user's own location. | |
| kind | No | Keep only some kinds of feature, matched against their OpenStreetMap tag value in English: pharmacy, school, supermarket, restaurant, hospital, farmland, forest, vineyard. One kind, or several in one call (["forest", "meadow", "grass"]). Leave out for all of the theme. | |
| level | No | For the divisions theme: the administrative level to keep. region = French région, US state, German Land; county = French département, US county; municipality = commune, town or city. With a named place, a division of that name at this level is returned alone, and lower levels are kept only inside the named place ("the departments of Brittany": place Brittany, level county). | |
| theme | Yes | The data layer. | |
| formats | No | Download formats. A GeoPackage is always included. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and open-world, but the description adds material context beyond them: the hard 20,000-feature cap with sizing heuristics, that download links build the file when opened and no file is saved, and the underlying data sources (Overture Maps and OpenStreetMap). These are exactly the operational traits an agent cannot infer from structured fields.
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 when-to-use trigger and packed with useful detail, with essentially no filler sentences. It is a single dense block, though, so the many distinct instructions (sizing, theme choice, link handling, fixed place input) would be easier to scan if grouped rather than run together.
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 five-parameter, nested-area, enum-heavy tool with an output schema, the description covers everything an agent needs: input form for area, how to constrain by kind or level, size limits, licensing/format output, and the cross-tool handoff rules. Nothing operational 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 baseline would be 3, but the description adds real meaning: it explains how to size radius_m ('about 1 km' for a town centre, less for dense cities), that kind filters against English OSM tag values and also lifts the feature limit to that kind only, how level works with a named place, and that all needed formats must be requested in a single call.
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 (extract) and resource (map data / GIS layers for a place or area anywhere in the world) and enumerates the themes covered, so an agent knows exactly what it produces. It also distinguishes itself from siblings by name (find_places not needed, never pass links to open_gis_file), removing ambiguity about which tool to pick.
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?
Explicit routing rules: use divisions with level and a place name (no radius) for administrative boundaries; set kind for a single feature type; one theme per call; when the user names no layer, present themes and let them choose before extracting several. It also gives negative guidance ('Never use the user's current location unless they type it', 'Never pass these links to open_gis_file').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the coordinates (latitude and longitude, GPS position) of an address or place name, the address at given coordinates, or wants places or addresses put, pinned or plotted on an interactive map, including a whole list of addresses (up to 100, pasted or as CSV with an address column). Worldwide, OpenStreetMap data; French street addresses are refined with the national address base. Shows the points on a map; for a list, gives a CSV with latitude and longitude added (opens directly in QGIS as a delimited text layer), plus KML and GeoJSON. Not for weather, opening hours, reviews, driving or travel directions and times, property prices, or general knowledge about a place (history, facts, travel advice): answer those without this tool. Never use the user's current location unless they type it. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | A list as text: one address per line, or CSV with an address column. The place the user asks about, not the user's own location. | |
| limit | No | For a single query: maximum number of matches. | |
| query | No | One address or place name. The place the user asks about, not the user's own location. | |
| title | No | For a list: map title, also used for file names. | |
| latitude | No | Latitude for a reverse lookup. The place the user asks about, not the user's own location. | |
| addresses | No | A list of addresses to place, up to 100. The place the user asks about, not the user's own location. | |
| longitude | No | Longitude for a reverse lookup. The place the user asks about, not the user's own location. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful non-annotation behavior: download links build their file on open with nothing saved to disk, a cross-tool constraint never to pass those links to open_gis_file, and that French street addresses are refined with the national address base. However, these are caveats rather than a rich account of data sourcing, error handling, or resolution confidence, so this sits at solid-but-not-exceptional.
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 trigger condition, then outputs, then exclusions, then operational caveats in a single dense block. Nearly every clause carries routing or behavioral information, though it runs long and the output-format enumeration partially duplicates what the output schema already covers.
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?
Covers modes, coverage (worldwide OSM plus French national base), output formats, batch limits, and the location-privacy rule. With an output schema present, it need not explain return values, yet the added format hints (QGIS-ready CSV, KML, GeoJSON) still help the agent set user expectations. Nothing needed 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 description coverage is 100%, so the baseline is 3 and the schema already documents each parameter's intent and bounds. The description adds mode-mapping value (query vs latitude/longitude vs text vs addresses, list capped at 100, CSV with an address column), but does not add syntax or format detail the schema lacks. 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?
States specific verbs and resources across three modes: forward geocoding (coordinates of an address/place), reverse geocoding (address at given coordinates), and batch plotting of a list on a map. An agent can distinguish this from siblings like convert_coordinates, get_elevation, or french_parcel without opening the 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?
Explicitly names when to use it and, more unusually, lists when NOT to use it (weather, opening hours, reviews, directions, property prices, general knowledge) with the instruction to answer those without the tool. It also routes the agent away from the user's own location unless typed, which is a real disambiguation risk for geocoders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how tall the buildings are around an address or in a small area in France: height in metres per building, floors, main use, year built and ground altitude, from IGN BD TOPO. The area is a place with a radius (default 150 m) or a bbox, at most 0.6 km². Shows the buildings on a map with a height summary (count, median, tallest) and GeoJSON, KML, Shapefile zip or CSV downloads. France only (mainland, Corsica and overseas departments). Never use the user's current location unless they type it. Give the place as the user names it (place name, address or coordinates): this tool locates it, so find_places is not needed first. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file: list every format the user needs in formats, in this one call.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | The area: a bbox, or a place (name, address or coordinates) with an optional radius in metres. The place the user asks about, not the user's own location. | |
| formats | No | Download formats. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description adds genuinely new behavior: the download links lazily build their file when opened and no file is stored, and all needed formats must be requested in a single call. These are non-obvious operational traits an agent could not infer from annotations or schema.
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?
Purpose and outputs are front-loaded, then constraints, then sibling routing — a sensible order with almost no filler. It is dense and runs long, but nearly every clause carries a distinct constraint or exclusion.
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?
Covers territory limits, area-size limits, default radius, output summary content, available formats, and the lazy-download quirk. With an output schema present, the description need not detail return structure, and nothing an agent needs to invoke this 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 the baseline is 3; the description goes beyond it by stating the default radius (150 m) and the 0.6 km² cap, neither of which appears in the schema, plus guidance on how to pass 'place' and on batching formats in one call. It does not explain bbox ordering, but the schema already does that.
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 concrete verb+resource+scope: building heights around an address or small area in France, listing exactly what attributes are returned (metres, floors, use, year, altitude) and the source (IGN BD TOPO). This is clearly distinguishable from siblings like get_elevation or french_parcel.
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?
Explicit when-to-use (user asks how tall buildings are), explicit constraints (France only including Corsica and overseas departments, at most 0.6 km²), and explicit exclusions ('Never use the user's current location unless they type it'). It also routes away from two siblings by name: find_places is not needed first, and links must not be passed to open_gis_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which cadastral parcel (parcelle cadastrale, plot of land) is at an address or point in France, its reference (commune, section, number) and cadastral area, or which local urban plan zone applies there (PLU or PLUi zoning: zone label, type such as U, AU, A or N, and the plan document), for example before buying land or a house or before a building project. Reads the open data of the French cadastre (DGFiP) and of the Géoportail de l'Urbanisme. Shows the parcel on a map with GeoJSON and KML downloads. France only. Never returns owners or property sales. The zone is not a building permit decision. Never use the user's current location unless they type it. Give the place as the user names it (place name, address or coordinates): this tool locates it, so find_places is not needed first. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | An address in France. The place the user asks about, not the user's own location. | |
| latitude | No | Latitude in France. The place the user asks about, not the user's own location. | |
| longitude | No | Longitude in France. The place the user asks about, not the user's own location. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only/idempotent/open-world profile, and the description goes well beyond them: it names the data sources (DGFiP cadastre, Géoportail de l'Urbanisme), states what is deliberately never returned (owners, property sales), clarifies the zoning output is not a building-permit decision, and explains download-link behavior (file built on open, nothing saved).
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 long, but front-loaded with the 'use this when' trigger and organized as purpose, then data sources, then scope limits and caveats. Nearly every clause carries a distinct constraint; a small amount of repetition around location-vs-user could be tightened.
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 read-only open-data lookup with an output schema present, the description covers everything needed to call it correctly: inputs accepted, geographic scope, sources, output form (map with GeoJSON/KML), and the important negative constraints. Nothing material 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 each parameter already carries a description, so the baseline is 3. The description adds real semantic guidance beyond the schema: pass the place as the user names it (place name, address, or coordinates) and repeatedly clarifies it is the queried place, not the user's own location.
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 set ('which cadastral parcel ... is at an address or point', plus PLU/PLUi zoning) with concrete field-level detail (commune, section, number, cadastral area; zone label/type). It explicitly distinguishes itself from siblings by noting find_places is not needed and that links must never go to open_gis_file.
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 explicit trigger contexts (before buying land or a house, before a building project) and explicit exclusions/scoping: France only, never use the user's current location, never pass download links to open_gis_file, and it pre-empts the find_places step. Nothing about when to select this tool 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.
Use this when the user asks how high a place is (altitude, height above sea level), wants an elevation profile or the climb between places (a hike, a ride or a road up a mountain: elevation gain and loss, highest and lowest points, cross-section), or asks about the terrain of an area, anywhere in the world: a DEM, relief or hillshade for QGIS, contour lines (topographic lines) and how steep or flat it is (slope). Place names work directly, for example a town and a summit. Reads the values from Copernicus DEM, a 30 m surface model of the whole world, and returns the numbers, a profile chart, the path or contours on a map and files. mode "point": up to 100 points. mode "path": 2 or more points, sampled into at most 500 samples. mode "area": a bbox, a place or a place with a radius, of any size: returns the DEM clipped to the area as a GeoTIFF (30 m, coarser for very large areas), a hillshade GeoTIFF and a slope GeoTIFF, which open directly in QGIS; for areas up to about 10 x 10 km it also returns contour lines (interval_m between lines; Shapefile, GeoJSON, KML) and slope statistics, so one call answers how steep a site is. Not for routes or travel times. Needs a place, coordinates or an area: to explain what a DEM, a DSM or contour lines are, answer without this tool. Never use the user's current location unless they type it. Give the place as the user names it (place name, address or coordinates): this tool locates it, so find_places is not needed first. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | For area: The area: a bbox, or a place (name, address or coordinates) with an optional radius in metres. The place the user asks about, not the user's own location. | |
| mode | No | point: elevation of each point; path: profile along the points; area: DEM, hillshade and slope GeoTIFFs, plus contour lines and slope statistics for small areas. | point |
| points | No | For point and path: points or place names. The place the user asks about, not the user's own location. | |
| samples | No | For path: number of samples along the path. | |
| interval_m | No | For area: vertical interval between contour lines, in metres. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, and the description adds substantial context beyond them: data source and resolution, per-mode sampling limits (100 points, 2+ points sampled to ≤500 samples), the ~10x10 km threshold for contour output, and the non-obvious fact that download links build the file on open with nothing saved server-side.
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 user-facing trigger before the technical detail, which is the right ordering. It is dense and somewhat long, with mild repetition of the return payload (chart/contours vs. the later DEM/hillshade/slope GeoTIFF list), but almost every sentence carries operational information.
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 five-parameter, mode-switching tool with nested area objects and an output schema, the description covers inputs, outputs, limits, data provenance, and the sibling-routing caveats. Nothing an agent needs in order to choose a mode and call 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 the baseline is 3. The description goes slightly further by tying each mode to the parameters it activates (points for point/path, area for bbox/place/radius, interval_m for contour spacing) and stating the any-size area behaviour, though most of these constraints are already present in 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+resource set (altitude lookup, elevation profile, terrain DEM/contours) and names the concrete data source (Copernicus DEM, 30 m). It also draws explicit boundaries against siblings: 'find_places is not needed first' and 'Never pass these links to open_gis_file.'
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?
Opens with an explicit when-to-use trigger list (altitude, climb between places, terrain/contours/slope), followed by when-NOT-to-use ('Not for routes or travel times', don't use it to explain what a DEM is, don't use the user's current location unless typed). Alternatives are named and the conditions that select them are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether a forest is natural, primary, naturally regenerating, planted, a plantation or tree crops (oil palm, cocoa, coffee, rubber, orchards, agroforestry), for example for EUDR due diligence (deforestation-free sourcing, 2020 cut-off), certification, a carbon or biodiversity project or a land purchase. The area is a bbox, a place, or a place with a radius (default 1,000 m), at most about 300 km². Reads Forest Typology (ForTy) 2020 v1 by Google DeepMind, a 10 m global map, and returns the share of each class in percent and hectares (primary forest, naturally regenerating forest, planted forest, plantation forest, tree crops and agroforestry, other land), the dominant class, a map, and a GeoTIFF of the class raster clipped to the area that opens in QGIS. Caveat: 2020 baseline; planted vs naturally regenerating is the least reliable class. Not for forest loss after 2020, tree height or species. Never use the user's current location unless they type it. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | The area: a bbox, or a place (name, address or coordinates) with an optional radius in metres. The place the user asks about, not the user's own location. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantive context beyond them: 2020 baseline, the least-reliable class (planted vs naturally regenerating), the ~300 km² area cap, and that download links build files on open with nothing saved. The cross-tool warning 'Never pass these links to open_gis_file' is a rare and valuable interoperability constraint.
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?
Dense but well ordered: trigger and use cases first, then source/area limits, then return shape, then caveat and exclusions. The class list is repeated between the trigger clause and the return-values clause, which is the only real redundancy.
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 one-parameter, read-only lookup with a nested area object, the description covers source, resolution, vintage, return shape, download-link behavior, accuracy caveat, and scope exclusions. An output schema exists, so further return-value detail is unnecessary.
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 bbox/place/radius semantics are already documented. The description still adds the default radius (1,000 m) and the maximum area (~300 km²), which meaningfully constrains how an agent should size the `area` argument.
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 the exact resource (forest type: natural, primary, naturally regenerating, planted, plantation, tree crops) and the underlying dataset (Forest Typology 2020 v1, 10 m global). It is unmistakably distinct from siblings like get_elevation, french_building_heights, or get_satellite_image.
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 gives an explicit trigger ('when the user asks whether a forest is natural...'), concrete use cases (EUDR due diligence, certification, carbon/biodiversity projects, land purchase), and explicit exclusions ('Not for forest loss after 2020, tree height or species'). It also states a hard behavioral rule: never use the user's current location unless typed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the driving, walking or cycling route between 2 to 25 places or points in order: the distance and travel time along the roads and paths, per leg and in total, and the route line. Computed by Valhalla on the TerraLab server from the OpenStreetMap road network, with each road's typical speed. Options avoid tolls, highways or ferries. Returns the figures (distance_m, distance_km, duration_s, duration_min), a map of the line and GeoJSON, KML, GPX, Shapefile zip and GeoPackage downloads. Not for a straight-line distance (use measure), live traffic, departure-time travel times, public transport or turn-by-turn navigation. Never use the user's current location unless they type it. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | How the route is travelled. | driving |
| points | Yes | Start, optional stops and destination, in travel order: place names or {latitude, longitude}. | |
| avoid_tolls | No | Driving: avoid toll roads where a reasonable alternative exists. | |
| avoid_ferries | No | Avoid ferries where possible. | |
| avoid_highways | No | Driving or cycling: avoid motorways and highways where possible. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which already declare read-only, open-world, idempotent): it names the engine and data source (Valhalla on TerraLab, OSM roads with typical speeds), discloses that download links generate their file only when opened and save nothing, and warns not to feed those links to open_gis_file. These are non-obvious behaviors an agent could otherwise get wrong.
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 core purpose and use case, then progressively adds exclusions, provenance and caveats. It is dense and runs long, and the format enumeration (GeoJSON, KML, GPX, Shapefile zip, GeoPackage) is slightly redundant given the output schema, but nearly every sentence carries actionable information.
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?
An output schema exists, yet the description still tells the agent what units and fields come back and how the download artifacts behave, and it covers provenance and the no-file-saved caveat. Nothing needed to call or interpret this tool 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 the baseline is 3; the description still adds value by restating the 2–25 point ordering requirement and summarizing what the avoid_tolls/avoid_highways/avoid_ferries options mean in practice. It does not add format or syntax detail beyond the schema, which limits it to a 4.
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 ('driving, walking or cycling route between 2 to 25 places or points in order') and immediately scopes the output to distance, travel time per leg and total, plus the route line. It is unmistakable against siblings like measure or get_travel_area.
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?
Explicit when-to-use framing ('Use this when the user wants...') plus a concrete exclusion list with a named alternative ('Not for a straight-line distance (use measure), live traffic, departure-time travel times, public transport or turn-by-turn navigation'). It even resolves a subtle policy question: never use the current location unless the user types it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants a satellite image or aerial photo of an area as a file for QGIS: a recent true colour picture, a false colour image, or NDVI to see vegetation, crops or forest health. The area is a bbox, a place, or a place with a radius. Two sources: IGN orthophotos (France only, about 0.5 to 1 m pixels, areas up to 2 x 2 km; the default inside metropolitan France for true colour) and Copernicus Sentinel-2 L2A (worldwide, 10 m, a scene every few days, areas up to 20 x 20 km; the default elsewhere and for false colour, NDVI or a date). For Sentinel-2 it picks the least cloudy scene covering the whole area in the date range (default: the last 60 days, at most 20 % cloud) and says its date, id and cloud cover. Returns a GeoTIFF in the source's own projected CRS (UTM or Lambert-93) with the licence in the file, and a preview on a map. Not for street-level photos, live weather or a picture more recent than a few days; to explain what NDVI or a band is, answer without this tool. Never use the user's current location unless they type it. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | The area: a bbox, or a place (name, address or coordinates) with an optional radius in metres. The place the user asks about, not the user's own location. | |
| date | No | Sentinel-2: one day, YYYY-MM-DD. | |
| source | No | ign_ortho: IGN orthophotos, France only, true colour. sentinel2: Copernicus Sentinel-2, worldwide, 10 m. Default: ign_ortho inside metropolitan France for true colour without a date, sentinel2 otherwise. | |
| date_to | No | Sentinel-2: end of the date range, YYYY-MM-DD. Default: today. | |
| product | No | Sentinel-2 only. true_color; false_color (B08, B04, B03: vegetation in red); ndvi (float32, NaN where cloud, shadow, snow or no data). | true_color |
| date_from | No | Sentinel-2: start of the date range, YYYY-MM-DD. Default: 60 days before date_to. | |
| max_cloud_percent | No | Sentinel-2: highest cloud cover of the whole scene, in percent. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds materially: hard area caps per source (2x2 km IGN, 20x20 km Sentinel-2), the least-cloudy-scene selection rule with default 60-day/20% cloud window, return format and CRS, embedded licence, and the non-obvious quirk that 'download links build their file when opened; no file is saved'. The instruction never to pass those links to open_gis_file is exactly the kind of cross-tool caveat only a description can carry.
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 use case, then constraints, with zero filler sentences — every clause carries a decision rule. It is a single dense paragraph with semicolon-chained clauses, which makes it slightly harder to scan than a short bulleted structure would be.
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?
Covers selection logic, geographic and size limits, defaults, scene-picking behavior, output format and CRS, and edge-case exclusions — everything an agent needs to choose between sources and avoid misuse. With an output schema present, it correctly does not spend words on return-value structure beyond the GeoTIFF/preview note.
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 the schema already documents every parameter including defaults and enums; the description nonetheless adds meaning the schema lacks, notably the area-size limits tied to each source and the default-source decision rule. It does not add syntax detail for date/bbox formats beyond the schema, so it stays just above baseline.
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 (retrieve a satellite/aerial image of an area as a file for QGIS) and enumerates the product variants (true colour, false colour, NDVI). It clearly separates itself from siblings by naming the file-consumer (QGIS) and the things it is not (street-level photos, weather, explanations of NDVI).
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?
Explicitly states when to use it, when not to ('Not for street-level photos, live weather or a picture more recent than a few days; to explain what NDVI or a band is, answer without this tool'), and gives routing rules between the two sources including which is the default in which geography and product combination. It even gives an alternative action (answer directly) instead of calling a tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the area reachable from 1 to 10 places within a travel time or a distance along the roads (an isochrone, catchment or service area): for example everything within 5, 10 and 20 minutes on foot from a station, or 30 km by car. Driving, walking or cycling, computed by Valhalla on the TerraLab server from the OpenStreetMap road network with each road's typical speed. Returns one polygon per start and value, with fields start, minutes or km, and mode, a map, and GeoJSON, KML, Shapefile zip and GeoPackage downloads. Up to 4 values, at most 120 minutes or 200 km. Not for a circle of a fixed radius (use measure), live traffic, a given departure time or public transport. Never use the user's current location unless they type it. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file.
| Name | Required | Description | Default |
|---|---|---|---|
| km | No | Distances along the roads in km, instead of minutes. | |
| mode | No | How the area is travelled. | driving |
| starts | Yes | Start places or points: place names or {latitude, longitude}. | |
| minutes | No | Travel times in minutes, one polygon each. Leave out when km is given. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive, but the description adds substantial context: computation by Valhalla on the TerraLab server from OSM with typical road speeds, no live traffic or departure-time modeling, and download links that build files on open without saving. The one caveat is that the 'never pass to open_gis_file' instruction is a routing rule rather than a behavioral trait, but the rest is genuinely useful beyond annotations.
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 dense but front-loaded: the primary use case comes first, then examples, then limits, then exclusions. It runs long as a single block, but nearly every sentence carries actionable information, so little 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?
Despite having four parameters, an output schema, and full annotations, the description still covers the key usage decisions: input limits, computation source, output formats, and when to use a different sibling tool. An agent has enough to call it correctly and interpret the response.
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 goes beyond it by explaining that minutes and km are alternatives, that each value produces one polygon, that up to 4 values are allowed, and that limits are 120 minutes or 200 km. It also clarifies that starts are 'places the user asks about, not the user's own location,' adding meaning to the schema's start 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?
States a specific verb and resource (area reachable from 1 to 10 places within a travel time or distance) and names the domain term isochrone/catchment/service area. It immediately distinguishes itself from measure (fixed-radius circle) and open_gis_file, so an agent can route correctly without opening a 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?
Gives explicit when-to-use examples (5/10/20 min on foot from a station, 30 km by car) and explicit when-not-to-use conditions: not for fixed-radius circles (use measure), not for live traffic, departure times, or public transport. It also rules out using the user's current location unless typed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants a straight-line (as the crow flies) distance between places with midpoint and bearing, the length of a drawn line, the area and perimeter of a polygon, a circle of a given radius around a place, or a buffer of a given width around a drawn line or polygon. Distances and areas are geodesic on the WGS 84 ellipsoid, buffers are built in a local equidistant projection; every figure states its unit (m, km, m², ha, km²). method "distance" takes 2 or more points or place names, or a line in geometry; "area" takes 3 or more points or a polygon in geometry; "radius" takes a center and radius_m; "buffer" takes a geometry and radius_m. Not a road or travel distance. Returns the numbers, a map and GeoJSON, KML, Shapefile zip or CSV downloads. Never use the user's current location unless they type it. Give the place as the user names it (place name, address or coordinates): this tool locates it, so find_places is not needed first. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file: list every format the user needs in formats, in this one call.
| Name | Required | Description | Default |
|---|---|---|---|
| center | No | For radius: the center, a point or a place name. The place the user asks about, not the user's own location. | |
| method | Yes | What to measure. | |
| points | No | For distance (2+) and area (3+): points or place names in order. The place the user asks about, not the user's own location. | |
| formats | No | Download formats. | |
| geometry | No | A drawn geometry as GeoJSON (Point, LineString, Polygon, MultiLineString or MultiPolygon, WGS 84 longitude, latitude), or a Feature holding one. | |
| radius_m | No | For radius and buffer: the distance in metres (convert km or miles to metres first). |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, so the description adds the parts annotations cannot: geodesic math on WGS 84 for distances and areas versus a local equidistant projection for buffers, unit disclosure for every figure, and the non-obvious download-link behavior (the file is built on open, nothing is persisted). The output contract is described only briefly ('the numbers, a map and GeoJSON, KML...'), which the output schema covers anyway, so a small gap remains rather than a contradiction.
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 capability and mode list, then rules and exclusions, so an agent gets the essentials in the first sentence. It is dense and the closing run of imperatives (location, place naming, download links, open_gis_file) is somewhat stream-of-consciousness, though essentially every clause carries distinct operational information.
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 four-mode, six-parameter tool with nested geometry, this leaves nothing an agent needs unresolved: mode selection, input formats, units, projection choice, precision limits (radius_m max 2,000,000), download behavior, and the two sibling traps are all addressed. The output schema covers return shape, so the short mention of returns is sufficient.
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 genuine semantics the schema cannot express: it maps each method value to the specific parameter set it consumes, which matters because only 'method' is required and the conditional requirements are invisible in the schema. It also states the minimum point counts and the metres-only unit convention for radius_m, plus multi-format batching guidance.
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 set (measure distance, line length, area/perimeter, radius circle, buffer) with the exact outputs per mode (midpoint, bearing, perimeter). It explicitly carves out the alternative it is not — 'Not a road or travel distance' — which separates it cleanly from get_route and get_travel_area, and the method enum names are all defined in prose.
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 explicit per-method trigger conditions (distance = 2+ points or a line; area = 3+ points or polygon; radius = center + radius_m; buffer = geometry + radius_m) and explicit exclusions ('Not a road or travel distance'). It also resolves the two most likely sibling confusions in advance: find_places is not needed first, and download links must never be routed to open_gis_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user shares or links a geographic file (GeoJSON, KML, KMZ, GPX track, zipped Shapefile, CSV with coordinates, WKT), pastes its content, or has a list of points or GeoJSON to put on a map, and wants to see it, understand it (format, coordinate system, extent, feature count, geometry types, fields, problems) or convert it to GeoJSON, KML, KMZ, GPX, Shapefile zip or CSV, for example a GPX track to a Shapefile or a KML to GeoJSON. Shapefile, GeoJSON, KML and CSV outputs open directly in QGIS. Also covers long tracks or point lists too big to write in the chat. Not for fetching new data about a place: that is extract_open_data. Files up to 50 MB. Never use the user's current location unless they type it. Download links build their file when opened; no file is saved. TerraLab reads the file or link to answer and keeps no copy.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | A public http(s) link to the file. | |
| file | No | A file uploaded in the conversation. | |
| text | No | The file content pasted as text (GeoJSON, KML, GPX, CSV or WKT). | |
| title | No | Name for the map and the output files when there is no file name. | |
| points | No | Points to show and convert, with a name. The places the user asks about, not the user's own location. | |
| geojson | No | A GeoJSON FeatureCollection, Feature or geometry in WGS 84, given as an object. | |
| file_name | No | Optional name of the file, used to name the outputs. | |
| convert_to | No | Output formats wanted. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description still adds material context beyond them: a 50 MB size ceiling, the rule that the user's current location is never used unless typed, that download links are built on open, that no file is saved, and that no copy of the source is retained. These are exactly the retention/privacy/limit facts an agent cannot infer from structured fields.
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 'Use this when...' trigger and organized as trigger, formats, examples, exclusions, limits, privacy. It is a dense single paragraph with some run-on packing, but each clause carries distinct operational information rather than 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?
An output schema exists, so return values need no explanation. For an 8-parameter tool with nested objects, the description still supplies the input triggers, format scope, size limit, location caveat, retention policy, and sibling routing — everything needed to call 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 real meaning: concrete conversion pairings (GPX track to Shapefile, KML to GeoJSON), which output formats open directly in QGIS, and the disambiguation that 'points' means the places the user asks about rather than the user's own location. It stops short of describing individual parameter mechanics, which the schema already handles.
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 set (open, map, convert) on a specific resource (geographic files) and enumerates the accepted inputs (GeoJSON, KML, KMZ, GPX, zipped Shapefile, CSV, WKT). It also names the sibling it is not (extract_open_data), so the agent can separate it from alternatives without opening schemas.
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 explicit triggers (user shares/links a file, pastes content, or supplies a point list) and an explicit exclusion ('Not for fetching new data about a place: that is extract_open_data'). It even handles the edge case of oversized inputs that can't be written in chat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to apply one GIS operation to a set of features (an uploaded file, a link, inline GeoJSON, or a download link from another TerraLab answer) and get the result as a file: buffer every feature by radius_m, union (dissolve all features into one, or one per value of dissolve_field), intersection or difference with a second layer, clip to a second layer or to an area (place, place with radius_m, or bbox), simplify by tolerance_m, centroid of each feature, or area_length (adds area_m2, perimeter_m and length_m to each feature, geodesic). Overlays run in WGS 84 degrees; buffer, simplify and centroid in a local equidistant projection. Up to 20,000 features and 100,000 vertices (10,000 for buffer). Returns the feature count, geometry types, total area or length, a map and GeoJSON, KML, Shapefile zip, GeoPackage and CSV downloads. Not for one distance or the area of a shape drawn in the chat: that is measure. Not for reading or converting a file without changing its geometry: that is open_gis_file. Never use the user's current location unless they type it. Download links build their file when opened; no file is saved. Never pass these links to open_gis_file: list every format the user needs in formats, in this one call. TerraLab reads the file or link to answer and keeps no copy.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | A public http(s) link to the features, or a TerraLab download link from an earlier answer. | |
| area | No | For clip: the area to keep, as a bbox or a place with a radius (its bounding box is used). The place the user asks about, not the user's own location. | |
| file | No | A file uploaded in the conversation (GeoJSON, KML, KMZ, GPX, zipped Shapefile, CSV or WKT). | |
| title | No | Name for the map and the output files. | |
| formats | No | Download formats. All five by default. | |
| geojson | No | The features as a GeoJSON FeatureCollection, Feature or geometry in WGS 84 (longitude, latitude). | |
| radius_m | No | For buffer: the distance in metres (convert km or miles first). | |
| with_url | No | For intersection, difference and clip: a link to the second layer, or a TerraLab download link. | |
| operation | Yes | The operation to apply. | |
| with_file | No | For intersection, difference and clip: the second layer, uploaded in the conversation. | |
| tolerance_m | No | For simplify: the largest allowed shift of the outline in metres. | |
| with_geojson | No | For intersection, difference and clip: the second layer as GeoJSON in WGS 84. Only its polygons count. | |
| dissolve_field | No | For union: dissolve into one feature per value of this field instead of one feature. |
| Name | Required | Description |
|---|---|---|
| code | No | Error code, on errors only. |
| hint | No | What to do next, on errors only. |
| message | No | Error message, on errors only. |
| sources | No | Data sources and licences of the result. |
| downloads | No | Download links; each builds its file when opened. |
| truncated | No | |
| totalFound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses CRS handling per operation (WGS 84 for overlays, local equidistant for buffer/simplify/centroid), hard limits (20,000 features, 100,000 vertices, 10,000 for buffer), that download links are built lazily on open with no file saved, and that TerraLab keeps no copy. The 'no file is saved' and 'never pass these links to open_gis_file' notes are exactly the kind of behavior annotations cannot express.
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 trigger clause and every sentence carries information — operation list, CRS, limits, return payload, exclusions, link semantics. It is a single very dense run-on paragraph, though; the exclusion and call-shape rules would scan faster as separate sentences.
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 13-parameter tool with nested objects and an output schema, the description covers what an agent needs before calling: which inputs are accepted, which parameters go with which operation, coordinate system expectations, size ceilings, and what the downloads are. Return-value detail is duplicated only briefly and the output schema carries the rest.
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 real cross-parameter semantics the schema cannot: radius_m is scoped to buffer, tolerance_m to simplify, dissolve_field to union (one feature per value vs. one feature), and area applies only to clip with place/radius/bbox forms. It does not restate the numeric bounds or formats enum, which it correctly leaves 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?
The description names the concrete verb (apply one GIS operation) and enumerates every operation the tool supports — buffer, union/dissolve, intersection, difference, clip, simplify, centroid, area_length — plus the input forms and the file output. It explicitly distinguishes itself from the two nearest siblings, measure and open_gis_file, so an agent can route without opening the 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?
Starts with an explicit 'Use this when...' trigger, then gives two explicit negative exclusions with the correct alternative named for each ('that is measure', 'that is open_gis_file'). It also adds a usage rule ('Never use the user's current location unless they type it') and a call-shape rule ('list every format the user needs in formats, in this one call').
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.
get_forest_typeextract_open_data4 fields changedInput schema / examplesPrevious value: -[
- {
- "area": {
- "bbox": [
- 2.34,
- 48.857,
- 2.343,
- 48.859
- ]
- },
- "formats": [
- "shapefile"
- ],
- "theme": "buildings"
- },
- {
- "area": {
- "place": "Annecy",
- "radius_m": 500
- },
- "kind": "pharmacy",
- "theme": "pois"
- }
-]New value: +[
+ {
+ "area": {
+ "bbox": [
+ 2.34,
+ 48.857,
+ 2.343,
+ 48.859
+ ]
+ },
+ "formats": [
+ "shapefile"
+ ],
+ "theme": "buildings"
+ },
+ {
+ "area": {
+ "place": "Annecy",
+ "radius_m": 500
+ },
+ "kind": "pharmacy",
+ "theme": "pois"
+ },
+ {
+ "area": {
+ "place": "Bretagne, France"
+ },
+ "formats": [
+ "shapefile"
+ ],
+ "level": "county",
+ "theme": "divisions"
+ }
+]Input schema / properties / formats / descriptionPrevious value: -"Download formats."New value: +"Download formats. A GeoPackage is always included."Input schema / properties / formats / items / enumPrevious value: -[
- "geojson",
- "kml",
- "shapefile",
- "csv"
-]New value: +[
+ "geojson",
+ "kml",
+ "shapefile",
+ "csv",
+ "geopackage"
+]Input schema / properties / levelAdded value: +{
+ "description": "For the divisions theme: the administrative level to keep. region = French région, US state, German Land; county = French département, US county; municipality = commune, town or city. With a named place, a division of that name at this level is returned alone, and lower levels are kept only inside the named place (\"the departments of Brittany\": place Brittany, level county).",
+ "enum": [
+ "country",
+ "region",
+ "county",
+ "municipality"
+ ],
+ "type": "string"
+}french_building_heightsget_routeget_satellite_imageget_travel_areameasureprocess_geometryget_elevation1 field changedInput schema / properties / mode / descriptionPrevious value: -"point: elevation of each point; path: profile along the points; area: contour lines and slope statistics."New value: +"point: elevation of each point; path: profile along the points; area: DEM, hillshade and slope GeoTIFFs, plus contour lines and slope statistics for small areas."convert_coordinatesextract_open_datafind_placesfrench_parcelget_elevationopen_gis_fileMaps for agents: truck/ADR routing, geocoding, places, matrices, isochrones, EV and fleet planning.
Mobility, geocoding and nearby urban services for AI agents.
Routing, geocoding, places, matrix and map tools for location-aware AI workflows.
Real-world data for agents: air quality, geocoding, quakes, holidays, web search
Add one secure layer between your agents and this server.