MarketCode

Comparable sales near the property, scored

valuation_comparables

Read-onlyIdempotent

Comparable completed sales for a valuation, beyond the property's own
building: Land Registry sales of the nearest units (within 1 km, the 60
months before `as_of`), widening from 250 m and 12 months until at least
6 qualify. A sale qualifies when it is the same broad type (flats with
flats, houses with houses, from the type recorded at the sale), within
0.67-1.5x the subject's floor area when both are known, category A and
not an anomaly. Category B, anomalous, new-build and out-of-band sales
are returned with `flags`, never dropped: review contrary sales rather
than ignoring them. Each sale: price, date, UPRN, address, distance,
floor area, bedrooms, tenure, `qualifies`, `similarity` (score with
distance, recency, size, type and bedrooms components). Floor area and
bedrooms are the unit's CURRENT record, not as at the sale
(`attributes_after_sale` flags a record dated after it). `selection`
names the step used; `provenance` lists every step tried and the data
watermark. Time-adjust prices with the published index before use.
`as_of` YYYY-MM or YYYY-MM-DD (default today); `limit` 1-60.
UK only. Costs 10 credits (10p). Keyed on a UPRN, not an address: call `address_autocomplete` (free) to narrow, then `address_resolve` to get one.

Input Schema

Name	Required	Description	Default
`uprn`	Yes
`as_of`	No
`limit`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: it discloses the widening radius/time window, the six-sale minimum, qualification criteria, and that non-qualifying sales are returned with flags rather than dropped. It also warns that floor area and bedrooms reflect the current record, explains selection and provenance, advises time-adjustment, and states the 10-credit cost.

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

Conciseness5/5

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

Although dense, the description is front-loaded with the tool's purpose and then proceeds through qualification, return behavior, caveats, parameters, cost, and prerequisites. Every sentence adds material information needed to interpret or invoke the tool correctly.

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?

The description is complete for a complex valuation-comparables tool: it covers scope, selection logic, flags, data caveats, return-field semantics, provenance, time adjustment, pricing, geography, and lookup prerequisites. Because an output schema exists, it does not need to restate the full response shape, and it already explains the most important returned concepts.

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

Parameters5/5

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

With schema description coverage at 0%, the description fully compensates: it explains that the key is a UPRN rather than an address, gives as_of accepted formats and default, and states the limit range. The parameter meanings are clear enough to call correctly.

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 description states a specific resource and operation: completed Land Registry comparable sales near the subject property for valuation, explicitly beyond the property's own building. It distinguishes the scope and qualification logic from generic property or transaction lookup tools without needing to name siblings.

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 clear usage context and prerequisites, including that the call is keyed on a UPRN and that address_autocomplete then address_resolve should be used to obtain one. It explains the widening search and qualification rules, but does not explicitly contrast this tool with siblings such as property_comps or valuation_rent_comparables.

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

All MarketCode 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.

Resources

Need Help?