Italian cadastral parcels, geocoding, OMI valuations, risk and demographic data. 85M parcels.
Scored across 6 tools
Each tool has a clearly distinct purpose: two geocoding tools split cleanly by direction (reverse vs. forward), and three parcel tools split cleanly by lookup key (ID, location/bbox, cadastral reference). Overlap between geocode_search and parcel_search is resolved by their descriptions targeting addresses vs. cadastral references.
All tools follow a consistent zornade_<domain>_<action> pattern (geocode_reverse, geocode_search, parcel_by_id, parcel_locate, parcel_search). The grouping by domain prefix is predictable and readable throughout, with only 'admin_lists' being a minor stylistic quirk.
Six tools is well-scoped for a focused cadastre/geospatial domain, with each tool earning its place. No redundant or filler tools are present.
The surface covers the core lifecycle well: administrative reference data, bidirectional geocoding, and parcel lookup by ID, location, and cadastral reference. Minor gaps exist (e.g., no POI/location-name search, no bulk or multi-parcel enrichment beyond the 10-point cap), but agents can work around these.
Italian administrative reference data: regions, provinces, or municipalities. Provinces can be filtered by region; municipalities by province or region.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Which administrative list to return | |
| region | No | Filter by region name (provinces, municipalities) | |
| province | No | Filter by province name (municipalities) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds only the implicit signal that this is stable 'reference data'; it says nothing about result size, pagination, or whether region/province filters are exact-match or fuzzy.
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 compact sentences with zero filler; the resource scope is front-loaded and the filter applicability follows immediately. Every clause carries 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 simple, fully-specified read-only lookup tool with 100% schema coverage and clear annotations, the description covers what the agent needs. No output schema exists, but the return value (a list of administrative names) is self-evident; only minor gaps like filter matching behavior remain.
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. The description's filtering note ('provinces by region, municipalities by province or region') merely restates what the schema parameter descriptions already say, adding no syntax, format, or matching-behavior detail.
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 set (Italian administrative reference data) and enumerates the three variants (regions, provinces, municipalities), matching the enum in the schema. It clearly differentiates from the geocoding and parcel siblings. It lacks an explicit verb like 'list'/'return', which the title supplies, so it falls just short of a 5.
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 states which filters apply to which type ('Provinces can be filtered by region; municipalities by province or region'), which is usage guidance for parameters. However, it gives no when-to-use vs. alternatives guidance — e.g. that this is static lookup data rather than geocoding — and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse geocoding: find Italian addresses near WGS84 coordinates. Returns the closest ANNCSU addresses with distance in meters.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude WGS84, Italy bounds 35.5-47.5 | |
| lng | Yes | Longitude WGS84, Italy bounds 6.0-19.0 | |
| limit | No | Max results, default 5 | |
| radius | No | Search radius in meters, default 100, max 500 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds value beyond that by disclosing the return content ('closest ANNCSU addresses with distance in meters'), which matters because there is no output schema. It does not mention behavior when coordinates fall outside Italy or when no address is found within radius.
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, zero waste, with the operation type front-loaded and the return shape following immediately. Nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter read tool with annotations covering safety and no output schema, the description supplies the essential return content and units. The only gap is edge-case behavior (out-of-bounds coordinates, empty results), which is minor given the tight schema bounds.
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%, with bounds, defaults and units documented for all four parameters, so the schema carries the semantic load. The description adds no parameter-level detail beyond the coordinate reference frame, which the schema already states.
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 ('reverse geocoding', 'find Italian addresses near WGS84 coordinates') and contrasts with the forward-looking sibling zornade_geocode_search by naming the direction explicitly. It does not name the sibling outright, but an agent can distinguish the direction of the operation from the wording.
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 only implied: 'reverse geocoding' tells an agent to call this when it holds coordinates rather than a text query. There is no explicit when-to-use statement, no exclusions, and no pointer to zornade_geocode_search or zornade_parcel_locate for adjacent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forward geocoding for Italian addresses. Searches the ANNCSU street archive (18.7+ million addresses) by street name and optional municipality. Returns matches with WGS84 coordinates, postal code, municipality, province and region. Does NOT find points of interest: search by street name instead.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Street name or search text, min 2 chars. Example: "Via del Corso" | |
| city | No | Municipality name filter. Example: "Roma" | |
| limit | No | Max results, default 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description still adds useful behavior beyond them: the data source and coverage scale, the exact fields returned (WGS84 coordinates, postal code, municipality, province, region), and the negative capability regarding POIs. No auth or rate-limit detail, hence not 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?
Three sentences, each earning its place: purpose, data source plus return payload, then the negative capability. The most decision-relevant fact (forward geocoding) is front-loaded and there is 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 3-parameter read-only lookup with no output schema, the description supplies exactly what is missing: the source dataset, the returned fields, and the scope limitation. An agent has everything needed to decide to call it and to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents q, city, and limit with examples and bounds. The description only restates that search is by street name with optional municipality, adding no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Forward geocoding for Italian addresses') plus the underlying dataset ('ANNCSU street archive, 18.7+ million addresses'). The word 'Forward' cleanly separates it from the sibling zornade_geocode_reverse, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use (street name plus optional municipality) and an explicit exclusion: it does NOT find points of interest, with the corrective action 'search by street name instead'. It stops short of naming which sibling tool to use for POI or parcel lookups, so it is strong but not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enriched cadastral parcel profile by FID or GML ID. Returns municipality, area, cadastral reference, and the requested data sections (risk, subsidence, terrain, buildings, economics, demographics, valuation, valuation_history, solar, POI, etc.). Geometry is omitted to keep the reply compact.
| Name | Required | Description | Default |
|---|---|---|---|
| fid | Yes | Parcel FID number (example "28009975") or GML ID | |
| include | No | Comma-separated sections: risk,subsidence,terrain,population,buildings,economics,demographics,land_cover,land_use,valuation,valuation_history,coastal_erosion,cultural_heritage,poi,solar,nightlights. Default: risk,economics,solar,valuation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and side-effect behavior are covered. The description adds genuine extra context: geometry is deliberately omitted to keep the reply compact, which tells the agent not to expect spatial data. It does not mention quota/rate limits or whether 'include' sections can be missing from the response.
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 compact sentences, front-loaded with the identity of the resource and the key, followed by return contents and the geometry caveat. 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?
There is no output schema, but the description enumerates the main response fields (municipality, area, cadastral reference, section data) and the geometry omission, which is enough for an agent to call and interpret it. Minor gap: it does not state response format or ordering guarantees.
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 both fid and include (with its full section list and default) are already documented in the schema. The description only restates the ID concept and the notion of 'requested data sections', adding no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Enriched cadastral parcel profile') plus the retrieval key ('by FID or GML ID'), and enumerates the returned content. This clearly separates it from the ID-based lookup vs the sibling locate/search tools that work by other means.
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 'by FID or GML ID' phrasing implies the tool is used when an identifier is already known, but there is no explicit when-to-use statement, no mention of when to prefer zornade_parcel_locate or zornade_parcel_search instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find cadastral parcels by coordinates or bounding box. Three modes: single point (lat+lng), multiple points (points="lat,lng;lat,lng", max 10), or bounding box (bbox="minLng,minLat,maxLng,maxLat", max 0.05 degrees per side). Returns matching parcels with FID, municipality and centroid.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for single-point mode | |
| lng | No | Longitude for single-point mode | |
| bbox | No | Bounding box as "minLng,minLat,maxLng,maxLat", max 0.05 degrees per side | |
| limit | No | Max results, default 50 | |
| points | No | Multiple points as "lat,lng;lat,lng", max 10 pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower; the description still adds operational constraints not in the annotations (max 10 point pairs, max 0.05 degrees per bbox side) and names the returned fields (FID, municipality, centroid) despite there being no output schema. It does not explain behavior when multiple mode parameters are supplied simultaneously.
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 load-bearing: the purpose, the three mode syntaxes with their caps, and the return payload. Mode information is front-loaded and no sentence is 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 usefully names the returned fields, and it covers all five parameters through the mode enumeration. It leaves open what happens if lat/lng, points, and bbox are supplied together, which matters given all five parameters are optional and the modes appear mutually exclusive.
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 every parameter is already documented in the schema, and the limits quoted in the description (max 10 points, 0.05 degrees, default 50) largely restate the schema text. The description's added value is tying parameters into named modes rather than per-field meaning, which is a marginal gain over 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 (find) and resource (cadastral parcels) plus the spatial inputs it accepts, which implicitly separates it from sibling parcel_by_id and parcel_search. It never names those siblings or explicitly contrasts their use, so an agent must infer the boundary rather than read it.
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 three modes are enumerated with the exact input shape for each (lat+lng, points string, bbox string), giving clear context for which parameters to populate. There is no statement of when to prefer this over zornade_parcel_search or geocode_reverse, and no exclusion guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cadastral parcels by cadastral reference: municipality (fuzzy match), sheet number (foglio), parcel label, optional section. Returns matching parcels with FID, municipality, sheet, area and centroid.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Parcel label. Example: "A" or "123" | |
| limit | No | Max results, default 20 | |
| comune | Yes | Municipality name, required. Example: "Roma" | |
| foglio | No | Cadastral sheet number. Example: "481" | |
| sezione | No | Administrative section. Example: "A" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safe-read profile is covered. The description adds one genuine behavioral trait beyond the annotations ('municipality (fuzzy match)') and lists returned fields, but says nothing about result truncation, ordering, or what happens when no parcel matches.
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, front-loaded with the query keys and followed by the return shape; no filler. It could be slightly tighter by merging the field list, but there is no wasted prose.
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 naming the returned fields (FID, municipality, sheet, area, centroid), which is exactly what an agent needs. The 'limit' parameter and pagination/result-cap behavior are left entirely to the schema, a minor gap for a 5-parameter search 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 description coverage is 100%, with examples for label, comune, foglio and sezione, so the schema carries the parameter semantics. The description restates the same fields and tags 'sezione' as optional, adding little beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Search cadastral parcels') and enumerates the reference fields used for the query (municipality, foglio, label, sezione). It is clearly distinguishable from zornade_parcel_by_id in spirit, but it never explicitly contrasts itself with that or with zornade_parcel_locate, so the differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by cadastral reference' and the required municipality, but there is no explicit when-to-use or when-not-to-use statement, and no routing to the sibling parcel tools (parcel_by_id, parcel_locate). An agent can guess the context but must infer it.
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.
zornade_admin_listszornade_geocode_reversezornade_geocode_searchzornade_parcel_by_idzornade_parcel_locatezornade_parcel_searchFrench real estate data: cadastre, DVF sales, DPE energy ratings, price estimates, parcel context
Cadastral parcels from 29 European countries, by reference in 27 and by coordinates in all 29
Real estate data for AI agents: US parcel boundaries (tiles), owners, sale history, permits, hail.
Italy — national legislation, from Normattiva's Open Data service (Istituto Poligrafico e Zecca…
Add one secure layer between your agents and this server.
