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.

Input Schema

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: absence semantics (44% polygon-to-title backfill), failed checks reported as UNKNOWN not absent, 25-credit cost, UK-only scope, and not_available behavior for missing rate inputs. However, it says the designation checks are 'LIVE' while openWorldHint=false implies no external-world access — not a hard contradiction, but the sourcing of the live lookups is left ambiguous, which caps this at 3.

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 purpose, then a scannable bulleted block list, then per-block caveats. Nearly every sentence guards against a specific misreporting error, though the caveat tail is long and could be tightened slightly without losing meaning.

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?

An output schema exists so return values need not be documented, yet the description still maps each block and warns how to interpret it. For a broad 11-parameter aggregator with zero schema descriptions, the guidance on identifiers, scheme pricing, precedents denominators and plot-utilisation limits is enough to call it correctly.

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 description coverage is 0%, so the description carries the whole burden. It explains the two identifier params with their source tools, the interaction between scheme_gia_m2, scheme_units and the mandatory user-supplied rate_gbp_m2, and the effect of include_designations. It leaves region, sector, rate_period, include_precedents and precedent_radius_m wholly unexplained, so compensation is strong but incomplete.

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 concrete verb and resource — 'Everything known about ONE site, assembled and judged' — and distinguishes itself from siblings with 'Returns in one call what would otherwise be six.' The identifying inputs are routed to their source tools (address_resolve, address_autocomplete, sourcing_search), so an agent can tell this apart from the individual report tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Gives explicit trigger conditions ('Give a uprn or a land_id'), names the alternatives it replaces (the six calls), prescribes reading order ('READ signals FIRST'), and offers a faster mode via include_designations=False for warehouse-only answers. The condition selecting each path is stated rather than inferred.

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