Skip to main content
Glama

Qatar Land Parcels & PIN Lookup (قطع الأراضي)

Map image of a Qatari parcel and its neighbours

QA_parcel_image
Read-onlyIdempotent

A map image centred on a Qatari parcel (id, its 8-digit PIN) or a point (query), with every parcel in view outlined and labelled with its PIN, 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, pin, buildingHeight, 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. 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": "QA_parcel_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoPIN (8 digits), 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.1/5.0
Behavior5/5

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

Beyond the read-only annotations the description discloses the things that actually change agent behaviour: cadastre/imagery offset of a few metres, imagery age, labels omitted on overlap with the recovery strategy, per-basemap line colouring, and a context-cost estimate per image. Those are non-obvious traits annotations cannot convey.

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?

Dense but front-loaded: what you get, then return shape, then basemaps, then caveats, then cost. Minor redundancy between "labelled: false where its label didn't fit" and "Labels are left off where they'd overlap" costs it the top mark.

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?

There is no output schema, and the description compensates fully: it enumerates the returned JSON fields and explains that one JPEG comes per requested basemap. Combined with the caveats and cost note, an agent has everything needed to call and interpret this correctly.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description does add genuine meaning the schema lacks — what each basemap actually depicts, the red highlighting of id, the default radius fitting the parcel with a margin — but size and the id/query exclusivity are left to the schema.

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

Purpose4/5

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

"A map image centred on a Qatari parcel ... or a point ... with every parcel in view outlined and labelled" gives a precise verb, resource and rendering behaviour, so the agent knows exactly what comes back. It never names the sibling QA_parcel_search or states the division of labour (search to find a PIN, this to view it), so differentiation is left implicit.

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?

Explicit situational advice: pass several basemaps "to match buildings with street names", and "call again with a smaller radius" when labels are dropped, plus a cost warning "ask for what you need". What is missing is the routing to QA_parcel_search as the way to obtain an id, and any statement of when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.