GetMovely

Search addresses

search_addresses

Read-onlyIdempotent

Find homes in England and Wales by street, postcode, town or address. Each row has the home's last sale, freehold or leasehold, whether it is owner-occupied, whether it is listed for sale, and its response likelihood (High = listed for sale and owner-occupied, Medium = owner-occupied, Unknown = no record). Filter with response_likelihood to answer "which homes on this street are owner-occupied and for sale", or sort by it. Returns at most 60 per page, newest sale first by default. If the street name exists in several places the answer lists the places as streets instead of rows; ask the person which one, then search again with the town or postcode.

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": {
      "query": "<query>"
    },
    "name": "search_addresses"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	Page number; 60 addresses per page.
`sort`	No	'recent' newest sale first (default); 'likelihood' High first, then Medium, then the rest; 'price_desc' / 'price_asc' by last sale price; 'addr' by address.	recent
`query`	Yes	Street, postcode, outcode, town or full address, as a person would type it: 'Merton Road, SW19', 'BS7 8', 'Ash Street, Salford M6', '41 Denning Road NW3'.
`sale_pairs`	No	Filter to homes whose sale history contains these sales, each as 'price:year', e.g. ['450000:2019']. This is how to find the exact address behind a listing or an advert that shows past sales.
`response_likelihood`	No	Only homes with this response likelihood. 'High' = listed for sale and owner-occupied (the homes where a letter reaches an owner who is selling). 'Medium' = owner-occupied, not listed for sale. 'Unknown' = no public record that the owner lives there. 'Owner on GetMovely' = the owner has claimed the address. Leave out for all homes.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The annotations only declare read-only/idempotent/non-destructive; the description adds the non-obvious behavior that matters: a 60-row page cap, newest-sale-first default ordering, and the unusual fallback where an ambiguous street name returns a `streets` list instead of rows and requires a follow-up call. That last point is exactly the kind of surprise behavior an agent cannot get from annotations or schema.

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?

Purpose and returned fields are front-loaded, and the disambiguation rule is placed last where it reads as an edge case. The long field enumeration is justified because no output schema exists, though the stray line break and duplicated explanation of response_likelihood (repeated in the schema) cost a little.

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 no output schema, the description carries the return-shape burden and does so by naming each row field plus the alternative `streets` shape. Pagination limit, default ordering, and the multi-street recovery workflow are all covered, so nothing an agent needs to call this 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 100%, so every parameter is already documented, including the `response_likelihood` enum meanings and the `sale_pairs` format. The description mostly restates the likelihood semantics and adds a task framing for filtering/sorting rather than new parameter detail. Baseline 3 is appropriate.

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 opening sentence states a specific verb and resource with geographic scope: 'Find homes in England and Wales by street, postcode, town or address.' It then enumerates the row fields returned, which makes the resource concrete. It stops short of naming a sibling, so the agent must infer the boundary with find_address_from_sale_history on its own.

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 concrete worked use case ('Filter with `response_likelihood` to answer "which homes on this street are owner-occupied and for sale", or sort by it') and a procedural rule for the ambiguous-street case: list the candidate places, ask the person, then re-search with town or postcode. There are no explicit when-not-to-use statements or named alternatives, which keeps it below a 5.

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?