Skip to main content
Glama

Site appraisal dossier

site_appraisal
Read-onlyIdempotent
Everything known about ONE site, assembled and judged — the site dossier.

Give a `uprn` (from address_resolve or address_autocomplete) or a `land_id`
(from sourcing_search). Returns in one call what would otherwise be six:

  * `site` — the land parcel: area, land use, built coverage, and the
    boundary as GeoJSON you can put straight on a map
  * `valuation` — our AVM against the last recorded sale, with gain and
    years held
  * `ownership` — the registered proprietor, type, company number
  * `energy` — the latest EPC
  * `auction_history` — every appearance, matched on address as well as
    UPRN, and whether it ever sold
  * `designations` — LIVE checks: conservation area, green belt, AONB,
    national park, flood risk, listed buildings
  * `signals` — the judgement

READ `signals` FIRST. It is why this exists rather than being six calls.
Each entry names what fired it and carries its evidence: repeat auction
failure with the guide-to-estimate ratio, long_held with the nominal gain,
mees_unlettable with the EPC band (F and G cannot legally be let),
under_built with the plot coverage, corporate_owner with the company
number. A site with nothing to say returns `signal: "none"` explicitly.

ABSENCE IS A REAL ANSWER, NOT AN ERROR. No registered proprietor means the
polygon-to-title backfill has not reached this parcel — it covers about 44%
— not that the land is unregistered. No EPC, no auction history and no
valuation are all normal, and each says so in its own block.

A designation check that FAILS is reported as UNKNOWN, never as absent. Do
not tell a user a site is unconstrained on the strength of a failed check.

A SCHEME PRICES THE BUILD. Pass `scheme_gia_m2` (and `scheme_units` for a
cost per unit) and you get a `scheme` block: build cost from the published
construction index times the regional factor, with on-costs. You must
supply `rate_gbp_m2` yourself — no £/m² benchmark is loaded, so without one
the block reads `not_available` rather than inventing a rate. It is
CONSTRUCTION COST ONLY: no land, finance, sales, S106 or CIL, so it is one
side of a residual and never a residual. Say that when you report it.

`precedents` summarises what nearby applications were decided: an approval
rate with its denominator, and a median decision time on the much smaller
sample that carries both dates. Quote each with its own n, and never as a
probability for this scheme.

`plot_utilisation` gives built coverage and unbuilt ground. Coverage is
footprint over area — a ground-plane measure, NOT a density — and unbuilt
ground is an upper bound before any constraint or access test, not a
developable area.

`include_designations=False` skips the live lookups and answers from the
warehouse alone, which is faster.

UK only. Costs 25 credits (25p).

Input Schema

NameRequiredDescriptionDefault
uprnNo
regionNoNATIONAL
sectorNoresidential
land_idNo
rate_gbp_m2No
rate_periodNo
scheme_unitsNo
scheme_gia_m2No
include_precedentsNo
precedent_radius_mNo
include_designationsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations: discloses cost (25 credits/25p), UK-only coverage, the ~44% polygon-to-title backfill limit, that missing EPC/auction/valuation are normal, that a failed designation check reports UNKNOWN not absent, and that the scheme block returns not_available without a supplied rate. These are exactly the failure modes an agent could otherwise misreport to a user.

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?

Long but front-loaded and bulleted, with the critical 'READ signals FIRST' instruction placed high. The interpretive caveats (absence, UNKNOWN designations, construction-cost-only, precedent denominators) each earn their space, though the prose runs longer than strictly necessary for a tool an agent calls repeatedly.

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 an output schema present, the description focuses on interpretation rather than field listing, and it covers the highest-risk misreadings: precedence of signals, absence semantics, failed-vs-absent designations, the scheme block's scope and limits, and how to quote precedent rates with their n. Nothing critical for correct reporting is missing.

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 description coverage is 0%, so the description must carry all 11 parameters. It explains uprn, land_id, scheme_gia_m2, scheme_units, rate_gbp_m2 and include_designations well, but region, sector, rate_period, include_precedents and precedent_radius_m are never mentioned — notably region/sector drive the regional cost factor, so their effect is invisible.

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 outcome — one assembled and judged dossier for a single site — and enumerates the exact blocks returned (site, valuation, ownership, energy, auction_history, designations, signals). It explicitly positions itself against the six separate calls it replaces, so an agent knows what it is versus the atomic siblings like valuation_full or property_flood_risk.

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?

Names the upstream producers for each key (uprn from address_resolve/address_autocomplete, land_id from sourcing_search) and gives a speed tradeoff for include_designations=False. It lacks an explicit 'use this instead of property_report / area_report when…' exclusion, so the boundary against other aggregate siblings is inferred rather than stated.

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.

Resources