Skip to main content
Glama

Rank areas on a market metric

market_ranking
Read-onlyIdempotent
Rank areas AGAINST EACH OTHER on a market metric — one row per area,
AGGREGATED over a trailing window of whole months.

This is the comparison tool. `market_facts` answers for one geography;
calling it in a loop to build a league table is slower, costs more and
gives you rows from different periods. Use this for "which districts in
Greater Manchester turn over fastest", "rank these twelve postcodes by
price per sqm", "cheapest LADs in the North West by price_psm".

ALWAYS report the `window` block from the response alongside the ranking.
It names the months aggregated, and it matters: a 12-month turnover and a
3-month one differ by roughly 4x. `lag_months` (default 3) deliberately
drops the most recent months because HM Land Registry registers sales
long after completion — the newest month looks near-dead and would rank
registration lag rather than liquidity.

turnover_rate is exact — it is sales over stock, recomputed at this grain.
Price, rent and yield are weighted means of the underlying medians, so
describe them as indicative, not as medians.

`min_stock` (default 50) skips areas with too few dwellings for a rate to
mean anything: one sale in a 2-dwelling district is a turnover of 0.5,
which otherwise tops the table. Where a returned area still has a small
`stock_count`, say so rather than presenting its rate as comparable.

Scope it EITHER by `parent_area_code` (every child of that area, e.g.
every district in a county) OR by an explicit `area_codes` allowlist.
`area_type` is the grain: "Postcode District" (default) or an
administrative type such as "Local Authority District".

`sort` defaults to turnover_rate, the liquidity measure — sales as a
share of the stock that could have sold. Do NOT sort on gross_yield or
days_on_market: they are 0% populated, so every row ties as NULL and the
"ranking" is arbitrary order. Populated metrics are sales_price,
price_psm and turnover_rate. Whatever you sort on is always returned,
and anything empty is named in `metrics_with_no_data`.

Distinct from `market_volume_ranking`, which ranks on raw transaction
COUNT — that is market size, not liquidity.

UK only. Free.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hmoNo
sortNo
limitNo
orderNo
metricsNo
area_typeNo
min_stockNo
area_codesNo
lag_monthsNo
asset_classNo
bedroom_bandNo
window_monthsNo
parent_area_codeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavioral context beyond them: the need to report the `window` block, why `lag_months` exists (registration lag), which metrics are exact vs. weighted means, that `min_stock` guards against tiny-stock distortion, and that gross_yield/days_on_market are 0% populated so sorting on them yields arbitrary order.

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 and sibling routing before the caveats, and every paragraph carries non-redundant information (window reporting, metric caveats, sort warnings). It runs long and leans on capitalization for emphasis, but the density earns the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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-shape explanation is not needed, and the description instead covers the behavioral traps an agent would otherwise hit (lag, min_stock, unpopulated metrics, indicative vs. exact metrics). The gap is undocumented parameters like `hmo`, `limit`, and `order`, but for this complexity the description is nearly complete.

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 coverage is 0% across 13 parameters, so the description must carry the load. It meaningfully documents `sort` (defaults to turnover_rate), `min_stock` (default 50), `lag_months` (default 3), `area_type`, and the parent_area_code/area_codes scoping choice, but leaves `hmo`, `limit`, `order`, `metrics`, `asset_class`, and `bedroom_band` entirely unexplained. Partial compensation on a wide-param tool justifies a 3.

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 opening states a specific verb and resource with scope: 'Rank areas AGAINST EACH OTHER on a market metric — one row per area, AGGREGATED over a trailing window of whole months.' It then names the siblings it differs from (`market_facts`, `market_volume_ranking`), so an agent can distinguish it without opening any 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?

Explicit when-to-use with worked examples ('which districts in Greater Manchester turn over fastest'), an explicit alternative and why (`market_facts` in a loop is slower, costs more, mixes periods), and an explicit exclusion ('Distinct from `market_volume_ranking`, which ranks on raw transaction COUNT'). Nothing is left to inference.

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