Rajasthan khasra parcels from Rajdharaa by coordinates or khasra number in a village.
Scored across 2 tools
The two tools divide cleanly along search-vs-visualise: IN_parcel_search resolves a location/ULPIN/number into parcel records, while IN_parcel_image renders a map around an id or point. Their inputs and outputs are described in a way that makes it obvious which one to call for which intent, and they cross-reference each other explicitly.
Both names follow the identical pattern `IN_parcel_<action>` with a shared domain prefix and lowercase snake_case. There is no mixing of conventions, and the action suffix (search, image) is descriptive of the verb performed.
Two tools is thin for a cadastral data server — the entire surface is one lookup and one render call. Both earn their place and the narrow domain justifies a small set, but there is no room for adjacent operations (e.g. bulk village export, geometry-only retrieval) without overloading the existing parameters.
Coverage is solid: search supports coordinates, ULPIN, parcel id, khasra number, village listing with paging, radius search and optional GeoJSON geometry, and image covers four basemaps plus labelling. Minor gaps remain — no direct export/download of boundaries, no way to enumerate states or villages without already knowing names, and geometry retrieval is only a flag on search rather than its own operation.
A map image centred on an Indian parcel (id, 'rj-123' from IN_parcel_search) or a point (query), with every parcel in view outlined and labelled with its khasra or survey number, so you can see which parcel is where. The parcel passed as id is drawn in red with a larger label; a query point is a red dot. Returns the parcels in view as JSON (label, id, number, village, area in m²; labelled: false where its label didn't fit), then one JPEG per basemap. Basemaps: satellite (Esri World Imagery, often a few years old), hybrid (the same imagery with road and place names), streets and topo (Esri's street and topographic maps). Pass several to compare, e.g. ['satellite', 'streets'] to match buildings with street names. Parcel outlines are yellow on imagery and magenta on maps. The portals' maps are digitised village sheets: offsets of 10 m or more from imagery are common. A scale bar is at bottom left. Labels are left off where they'd overlap; call again with a smaller radius to read them. Each image costs about as much context as 1,000 words, so ask for what you need.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Parcel id (rj-123, ga-45), drawn in red | |
| size | No | Image width and height in pixels | |
| query | No | 'latitude, longitude' to centre on instead of a parcel | |
| radius | No | Metres from the centre to the image edge. Default: fits the parcel with a margin, or 80 m around a point | |
| basemaps | No | One image per basemap |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description focuses on what annotations can't say: imagery may be years old, portal maps are digitised village sheets with offsets of 10 m or more, labels are omitted where they'd overlap, outlines are yellow on imagery and magenta on maps, and a scale bar sits bottom left. It also quantifies context cost per image, which is decision-relevant behavior not captured anywhere else.
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 the id-vs-query distinction before the detail, and nearly every sentence carries operational information. It is a single dense block with some run-on enumeration of basemaps and colors that could be tightened, but little genuine padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return contract itself: parcels in view as JSON with label, id, number, village, area in m² and labelled:false when a label didn't fit, followed by one JPEG per basemap. Combined with the provenance caveats, an agent has what it needs to call this correctly and 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it characterizes each basemap (satellite = Esri World Imagery, often a few years old; hybrid = same imagery with road and place names) and describes the radius default relative to parcel size versus point. It goes beyond the schema without fully documenting every parameter edge case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb-and-resource statement: a map image centred on an Indian parcel (by id) or a point (query), with every parcel in view outlined and labelled. It also distinguishes itself from the sibling IN_parcel_search by naming it as the source of the id ('rj-123' from IN_parcel_search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit selection guidance among basemaps ('Pass several to compare, e.g. ["satellite", "streets"] to match buildings with street names'), explains id vs query usage, and states a recovery path when labels are dropped ('call again with a smaller radius to read them'). It also frames the cost tradeoff ('Each image costs about as much context as 1,000 words, so ask for what you need'), which shapes invocation choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Indian cadastral parcels by location, ULPIN, or number in a village, with each parcel's whole record. query takes coordinates as 'latitude, longitude' (e.g. 15.3433, 74.1764), a Madhya Pradesh ULPIN, a parcel id from an earlier result ('ga-123'), or a khasra/survey number ('35/1') with state and village: a village name in Rajasthan, Goa and Delhi ('Calem', 'Mundka'), the village's LGD code in Madhya Pradesh. state and village without a number list the village's parcels, paged with offset. Assam is searchable by coordinates only. With coordinates it returns parcels containing the point (distance 0), then the nearest within radius metres, closest first. Each parcel has id, state, number, village, record (the state's own fields), mapArea (m²) and bbox. Set include_geometry for each boundary as GeoJSON (keep limit small). Use IN_parcel_image to see a parcel and its neighbours.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results | |
| query | No | 'latitude, longitude', a ULPIN, a parcel id (ga-123), or a khasra/survey number with state and village | |
| state | No | rj Rajasthan, mp Madhya Pradesh, ga Goa, as Assam, ld Lakshadweep, dl Delhi; needed with a number or village | |
| offset | No | Skip this many matches of a number or name search, to page through them | |
| radius | No | Search radius in metres around coordinates | |
| village | No | Village name (Rajasthan, Goa, Delhi) or LGD code (Madhya Pradesh) | |
| include_geometry | No | Include each boundary as a GeoJSON MultiPolygon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description goes well beyond them: it explains that coordinate searches return containing parcels (distance 0) first then nearest within radius, that results are closest-first, that state+village without a number pages the village's parcels, and that include_geometry is expensive and should be paired with a small limit.
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 core purpose and alternatives are front-loaded, and nearly every clause carries operative information. The second sentence is very densely packed with state-specific rules, which costs some readability, but 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?
With 7 optional parameters, no output schema, and a complex multi-mode search, the description supplies the missing return shape (id, state, number, village, record, mapArea, bbox) and the ordering semantics. An agent can construct a valid, correctly scoped call for every supported state and query mode from this text.
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 would be 3, but the description adds real meaning the schema alone does not convey: which query formats pair with which state/village conventions, that Assam accepts coordinates only, and that geometry output is a GeoJSON boundary best kept to small limits. It does not explain how offset interacts with limit or whether limit applies to coordinate searches.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Find Indian cadastral parcels by location, ULPIN, or number in a village') and states it returns each parcel's whole record. It is clearly distinguishable from the only sibling, IN_parcel_image, which is named and routed to at the end.
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 enumerates every accepted query form (coordinates, MP ULPIN, parcel id 'ga-123', khasra number) and the per-state village identification rules (name in Rajasthan/Goa/Delhi, LGD code in MP), plus the coordinate-only restriction for Assam. It also gives an explicit alternative ('Use IN_parcel_image to see a parcel and its neighbours') and a caution to keep limit small when geometry is requested.
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.
IN_parcel_imageIN_parcel_searchMadhya Pradesh khasra and plot parcels from MP Bhulekh by coordinates, ULPIN or khasra number.
Indian khasra and survey parcels in five states by coordinates, ULPIN or number in a village.
Croatian DGU cadastral parcels by katastarska općina and parcel number, or coordinates.
Lakshadweep survey parcels on Kavaratti island by coordinates or survey number.
Add one secure layer between your agents and this server.
