Skip to main content
Glama
Sign In

GetMovely

by uk.co.getmovely
OverviewDiscussionsAdmin

Research figures for a local authority district

district_statistics
Read-onlyIdempotent

GetMovely's published research for one local authority district, with England and Wales alongside: the share of homes that are leasehold (houses and flats separately), how many years pass between sales of the same home and the share not sold for 20 years or more, the share of purchases resold within two years, and how big homes are (median floor area, by property type and built form). Districts are named as HM Land Registry and the EPC register name them; an unclear name returns the candidates. For prices use area_overview, which works by postcode district.

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": {
      "district": "<district>"
    },
    "name": "district_statistics"
  }
}

Input Schema

NameRequiredDescriptionDefault
districtYesA local authority district in England or Wales by name: 'Bristol', 'Camden', 'Merton', 'Leeds', 'Cardiff'. 'London' gives Greater London as a whole and 'England and Wales' the national figures.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world behavior, so the bar is lower, and the description still adds real context: the naming convention (HM Land Registry and EPC register names), the England-and-Wales coverage boundary, the special-case inputs 'London' and 'England and Wales', and the fallback of returning candidates for an unclear name. It does not discuss freshness of the underlying research data or result size, which is the main remaining gap.

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?

Two sentences, front-loaded with the resource and scope, then the metric list, then the alternative routing. The metric enumeration is dense with parentheticals and takes effort to parse, but every clause carries substantive information and nothing reads as filler.

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?

There is no output schema, and the description compensates by spelling out the figures the caller will receive. With a single fully documented parameter and annotations covering the safety profile, an agent has everything needed to select and invoke it correctly.

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 description coverage is 100%, so the baseline is 3, and the description earns an increment by explaining the naming authority behind the district value and what happens when the supplied name is unclear. The 'London' and 'England and Wales' special cases are already in the schema, so this is added meaning rather than repetition of everything.

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 names a specific verb+resource ('GetMovely's published research for one local authority district') and then enumerates the exact metrics returned: leasehold share split by houses/flats, years between sales, share unsold after 20 years, resale within two years, and median floor area by property type and built form. It explicitly separates itself from area_overview, which handles prices by postcode district, so an agent can distinguish it from siblings without opening a schema.

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 a clear routing rule ('For prices use area_overview, which works by postcode district') and explains the resolution behavior when a district name is ambiguous ('an unclear name returns the candidates'). What is missing is any statement about when not to use it, or which sibling covers overlapping tenure/age questions, but the primary alternative and its distinguishing scope are stated outright.

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

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