GetMovely

Price trends by factor

price_trends

Read-onlyIdempotent

What freehold or leasehold, new build or resale, energy rating and floor area are worth per square metre in one postcode district, for one property type (D detached, S semi-detached, T terraced, F flat), by whole calendar year, against the national picture. Property type is always held constant because it is the confounder that makes the naive comparison lie. Every figure is a median of at least a minimum number of sales; no per-address data. For a plain summary of a district across all its property types use area_overview.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "outcode": "<outcode>"
    },
    "name": "price_trends"
  }
}

Input Schema

Name	Required	Description	Default
`factor`	No		all
`outcode`	Yes	Postcode district (outcode) such as 'SW19', 'BS7', 'M6'. A full postcode is accepted; only the district is used.
`property_type`	No		T

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The annotations already establish that this is a safe, read-only, idempotent lookup. The description adds meaningful behavioral context by stating that figures are medians based on a minimum number of sales, that no per-address data is returned, and that property type is held constant to avoid confounding.

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

Conciseness3/5

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

The purpose is front-loaded, but the first sentence is a long, hard-to-parse construction and the rationale about property type being the confounder that makes naive comparisons lie is wordier than necessary. The routing sentence is useful, yet the description would benefit from tighter phrasing.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers aggregation, privacy, and the key comparison discipline well. However, with no output schema, it does not clearly describe the return shape, and the phrase 'by whole calendar year' leaves ambiguity about whether year is an input dimension or only part of the output.

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?

With only 33% schema description coverage, the description compensates substantially by mapping the factor values to tenure, new-build status, EPC, and floor area, and by spelling out the D/S/T/F property-type codes. It does not explain the 'all' factor value or clarify whether time is an input or only an aggregation dimension.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource and scope precisely: per-square-metre values by postcode district, property type, factor, and calendar year, compared with the national picture. It distinguishes the tool from area_overview, though it does not differentiate it from other pricing siblings such as price_check or street_price_per_m2.

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 explicitly routes plain district summaries across all property types to area_overview, leaving price_trends for factor-specific analysis. That is clear when-to-use guidance, but it does not say when another pricing tool should be preferred instead.

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

All GetMovely 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?