Skip to main content
Glama
Sign In

South Africa Cadastral Parcels (Surveyor-General · Erven & Farms)

by io.github.BumiAtlas
OverviewDiscussionsAdmin

Map image of a South African parcel and its neighbours

ZA_parcel_image
Read-onlyIdempotent

A map image centred on a South African parcel (id, '<PRCL_KEY>:' from ZA_parcel_search) or a point (query), with every parcel in view outlined and labelled with its CSG label (RE/13583), 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, type, area in m²; labelled: false where its label didn't fit), then one JPEG per basemap. Erven and the farm portions under them overlap, so both are outlined. 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. Imagery is not always aligned with the cadastre: offsets of a few metres are possible. 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ZA_parcel_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoParcel id (EBUFC023000400013583000001:E), drawn in red
sizeNoImage width and height in pixels
queryNo'latitude, longitude' to centre on instead of a parcel
radiusNoMetres from the centre to the image edge. Default: fits the parcel with a margin, or 80 m around a point
basemapsNoOne image per basemap

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the safety annotations (readOnly, idempotent, non-destructive), the description discloses the return shape (JSON of parcels in view, then one JPEG per basemap), per-call context cost (~1,000 words each), staleness of imagery, cadastral misalignment of a few metres, label-suppression on overlaps, and colour conventions per basemap. These are exactly the operational facts an agent needs before spending context on image calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with what the tool produces and stays dense throughout, but at roughly 200 words it is long for a five-parameter tool and repeats the outline-colour idea across two sentences. No sentence is pure filler, though several clauses could be merged.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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-value burden and does so fully: JSON parcel list plus one JPEG per basemap, colour coding, scale bar, and label-omission behaviour. Nothing material about invoking or interpreting this tool is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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: the id must be '<PRCL_KEY>:<type>' obtained from ZA_parcel_search and is drawn in red, a query point is a red dot, and radius defaults to fitting the parcel with a margin or 80 m around a point. It also explains what the basemaps actually look like, which the bare enum does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names the exact resource (a map image centred on a South African parcel or point), the inputs that select it (id from ZA_parcel_search or query), and the visible outcome (parcels outlined and CSG-labelled). It also names the sibling ZA_parcel_search as the source of the id, so an agent can route between the two 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete selection guidance: 'Pass several to compare, e.g. ["satellite", "streets"] to match buildings with street names', and a recovery path ('call again with a smaller radius to read them'), plus a cost warning that discourages over-requesting. There is no explicit statement of when not to use it in favour of ZA_parcel_search, so it falls 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.

All South Africa Cadastral Parcels (Surveyor-General · Erven & Farms) toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources