Skip to main content
Glama

Search land or units by criteria

sourcing_search
Read-onlyIdempotent
Find land parcels, property units or buildings matching search criteria — the
sourcing tool. Give a `location` (place name, area code or postcode
district) or a `bbox`.

STRATEGY MODE (preferred). Pass a `strategy` key from
`sourcing_strategies` with `lad_code` or `postcode_district`, and the
search runs the published preset: its filters, its ranking, and a
`score_components` breakdown on every row saying which term earned what.
Override any published filter with `strategy_overrides` — `{"min_yield_pct":
8}` — or pass null for a key to switch that filter off. An unknown key is
rejected rather than ignored. `listing_state` restricts to on- or
off-market units; page with `cursor` from `next_cursor`. Strategy mode
ignores the legacy filters below.

Filter land by use class and `max_built_coverage` (built footprint as a
share of plot, so 0.2 finds substantially empty plots), units by type,
bedrooms, EPC band and tenure, and either by owner — `min_years_owned` is
the usual off-market signal, and `owner_types` separates companies from
public bodies.

Returns parcels with ownership attached where the bulk register knows it.
For land or units, use sourcing_owners to resolve a specific set afterwards.

PARKS, HEATHS, RAILWAYS, CEMETERIES AND UTILITY LAND ARE EXCLUDED BY
DEFAULT. The scan is ordered by parcel size, and the largest parcels in any
area are its open spaces — unfiltered, a Camden search returned Regent's
Park, Hampstead Heath, a cemetery and railway land as its top six, while
13,047 residential parcels in the same borough never appeared. Pass
`include_undevelopable=True` to see them; they come back with no indicative
land value, because a residual on a heath is a meaningless number that
reads as an authoritative one.

BUILDINGS: asset="buildings" searches recorded footprints with footprint
area, storey count, unit count, dominant EPC and tenure. Supply one location,
bbox or drawn polygon. Results include matching footprints and stable
building IDs for linked-unit inspection. Page with offset, limit up to 100.
Unit/owner/strategy criteria are rejected for buildings.

INVENTORY PAGINATION: for land or units, supply offset=0, then next_offset
while has_more is true. These bounded pages apply every criterion before
pagination; derived-score/strategy criteria are not accepted in this mode.
Unit size uses min/max_floor_area_m2; land and buildings use min/max_area_m2.
Repeated warehouse reads are cached for five minutes. Results remain metered
by the gateway. No unknown tenure or EPC is asserted to meet a positive filter.

UK only. Costs 40 credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNo
assetNoland
limitNo
cursorNoSTRATEGY MODE ONLY: `next_cursor` from the previous page. Inventory pages use `offset`.
epc_inNo
offsetNo
tenureNo
landuseNo
min_rlvNo
lad_codeNoSTRATEGY MODE scope (GSS code, e.g. E09000032). Without a strategy, pass the code as `location` instead.
locationNo
max_bedsNo
min_bedsNo
strategyNoA preset key from `sourcing_strategies`. Turns on strategy mode.
max_unitsNo
min_scoreNo
min_unitsNo
max_floorsNo
min_floorsNo
max_area_m2No
min_area_m2No
owner_typesNo
area_geojsonNo
listing_stateNoSTRATEGY MODE ONLY, units only: restrict to on- or off-market units. Rejected without `strategy`. For what is on the market now use `sourcing_live_listings`.
require_ownerNo
company_statusNo
property_typesNo
min_years_ownedNo
max_floor_area_m2No
min_floor_area_m2No
postcode_districtNoSTRATEGY MODE scope (e.g. SW11). Without a strategy, pass it as `location`.
max_built_coverageNo
opportunities_onlyNo
strategy_overridesNoSTRATEGY MODE ONLY. Values for the preset's own filter keys.
exclude_owner_typesNo
max_unexpired_yearsNo
include_undevelopableNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on substantial extra behavior: the 40-credit cost, five-minute warehouse read caching, gateway metering, the default exclusion of parks/heaths/railways/cemeteries, why undevelopable land returns no indicative value, and the rule that unknown tenure/EPC is never asserted to meet a positive filter. This is far beyond what the structured fields 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?

Long but front-loaded and organized into labeled sections (strategy, filters, exclusions, buildings, inventory pagination) that match how an agent would work through the call. The Camden example is vivid and earns its space, but the 'strategy mode ignores the legacy filters below' constraint and the pagination rules are restated in more than one place.

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?

For a 37-parameter, multi-mode tool with only 16% schema coverage, the description covers selection of mode, required geography input, pagination in both modes, default exclusions, cost, and metering. An output schema exists, so the description is not obliged to detail return shapes, and the rows/score_components mention is a helpful bonus rather than a gap.

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 only 16% across 37 parameters, so the description carries most of the burden and does so for the hard ones: strategy/strategy_overrides (including the null-to-disable and unknown-key-rejected semantics), listing_state, cursor vs offset, lad_code/postcode_district vs location, max_built_coverage as a share of plot, min_years_owned as an off-market signal, owner_types, include_undevelopable, and the split between floor_area and area parameters. Several parameters (min_rlv, opportunities_only, min_score, max_unexpired_years, company_status, exclude_owner_types) remain undocumented, so it falls short of full compensation.

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 ('Find land parcels, property units or buildings matching search criteria') and explicitly labels its role ('the sourcing tool'), which separates it from the many sibling sourcing_* and property_* tools. The three asset modes (land, units, buildings) are named upfront.

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?

Explicitly declares 'STRATEGY MODE (preferred)' and explains the strategy/overrides mechanism, then routes the agent elsewhere when appropriate: sourcing_owners 'to resolve a specific set afterwards' and sourcing_live_listings 'for what is on the market now'. It also names when filters are ignored or rejected, which is exactly the routing information an agent needs.

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