Pakistan Land Parcels & Khasra Lookup (پنجاب اراضی)

Map image of a Punjab parcel and its neighbours

PK_parcel_image

Read-onlyIdempotent

A map image centred on a Punjab parcel (id, or its uniParco code) or a point (query), with every parcel in view outlined and labelled with its khasra plot 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, uniParco, society, landuse, 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. PULSE linework is indicative: offsets of several metres from both imagery and the legal boundary are normal. 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": "PK_parcel_image"
  }
}

Input Schema

Name	Required	Description
`id`	No	parcel id ('lda_schemes-148641') or uniParco code, 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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Well beyond the annotations: it discloses the return shape (JSON parcel list plus one JPEG per basemap), a context-cost budget (~1,000 words per image), imagery staleness, colour coding per basemap type, the indicative nature of PULSE linework with multi-metre offsets, and the label-overlap fallback. These are exactly the operational caveats an agent needs before spending context on images.

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?

Front-loaded with the core purpose, then returns, then basemap choices, then caveats — a logical order with no filler. It is dense and long-ish, and a couple of clauses (scale bar location, parcel outline colours) could be trimmed, but each sentence carries usable information.

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 by describing both the JSON payload fields and the accompanying images, plus cost, caveats, and remediation for unreadable labels. Nothing an agent needs in order to call this correctly and interpret the result is missing.

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; the description still adds value by explaining that id is drawn in red with a larger label while query becomes a red dot, and by framing basemaps as a comparison set rather than a single choice. The radius default behaviour is repeated from the schema rather than extended.

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?

States a specific verb and resource: a map image centred on a Punjab parcel or point, with every parcel in view outlined and labelled by khasra number. It also distinguishes the two modes (id vs query) and the visual encoding (red parcel / red dot), so an agent can tell exactly what this produces versus the sibling PK_parcel_search.

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?

Gives concrete usage advice: pass several basemaps to compare (e.g. satellite + streets to match buildings with street names), and call again with a smaller radius when labels are omitted for overlap. It does not explicitly route the agent from PK_parcel_search to this tool or state when-not-to-use, which keeps it below a 5.

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

All Pakistan Land Parcels & Khasra Lookup (پنجاب اراضی) tools Inspect

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.