MarketCode

What changed since your cursor

changes_since

Read-onlyIdempotent

What changed since you last looked — the portal change feed. Pass the
`next_cursor` from your previous call to get only what is new; on a first
call give a scope (`postcode_districts` or `uprns`) or a `since` date,
because an unbounded read of a 14.6-million-row feed is refused.

THE CURSOR IS AN EVENT ID, not a timestamp. Rows recorded late always take
higher ids, so nothing slips behind your watermark between polls. Each
event carries both `event_date` (when the portal says it happened) and
`observed_at` (when our sweep saw it) — a backfill has an old date and a
recent observation, which is exactly why the cursor is an id.

READ `coverage.event_types` BEFORE TRUSTING AN EMPTY PAGE. `added` and
`price_reduced` are live and daily. `price_increased` and `status_changed`
are sparse and only start in late August. **`delisted` has ONE row in the
whole table: withdrawal is NOT observed, so an empty result for it means we
cannot see it, not that nothing was withdrawn.** Five change kinds a user
may ask for — planning decisions, ownership changes, a lease crossing 80 or
60 years, a new EPC, an AVM move — have no feed at all and are listed under
`coverage.not_yet_fed`. Say which of these you cannot answer.

On a price change, `price.old_price_source` says whether the old price came
from the event itself or was derived from the listing's previous event; the
portal usually reports only the new price. Where neither is available the
change is null, never zero.
UK only. Costs 5 credits (5p). 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
`limit`	No
`since`	No
`uprns`	No
`cursor`	No
`channel`	No
`event_types`	No
`postcode_districts`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.4/5.0

Behavior4/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 substantive context: the cursor is an event id (so late rows never slip behind the watermark), a 14.6M-row feed rejects unbounded reads, cost is 5 credits, and the delisted event type is effectively invisible. Only the return shape of a page (besides event_date/observed_at) is left implicit.

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-loads the core instruction, then layers cursor semantics, coverage caveats, price-field caveats, and cost/prerequisites in a logical order. It is longer than typical but nearly every sentence carries non-obvious information; the bolded delisted warning is worth its space.

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, return values need not be explained, yet the description still clarifies event_date vs. observed_at and price.old_price_source — exactly the fields an agent would misread. Combined with the scope rules and prerequisites, nothing needed to call it correctly 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 compensate. It explains cursor (event id, not timestamp), since, postcode_districts, uprns, and even names the event_types values (added, price_reduced, price_increased, status_changed, delisted) — but leaves `limit` and `channel` (with its residential_sale/residential_rent enum) entirely undocumented.

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 — the portal change feed returning what changed since a cursor — and its scope (UK, UPRN-keyed) distinguishes it from siblings like listing_history or property_history. An agent can identify it without opening the schema.

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 prescribes the two call patterns (pass next_cursor vs. first call with scope or since), states that unbounded reads are refused, and routes the agent through address_autocomplete (free) then address_resolve to obtain a UPRN. It also names what cannot be answered via coverage.not_yet_fed.

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?