Skip to main content
Glama
Sign In

Landregistry Uk

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Search Transactions

search_transactions
Read-onlyIdempotent

Search HM Land Registry Price Paid records — individual residential property sales in England & Wales since 1995. Filter by postcode, town, district, county, price range and sale-date range; sort and page through results. Each record returns price paid (£GBP), sale date, full address, property type, tenure (freehold/leasehold) and new-build flag. Postcodes must be UPPERCASE with a space (e.g. "SW1A 1AA").

Input Schema

NameRequiredDescriptionDefault
dateNoExact sale date, YYYY-MM-DD. Overrides minDate/maxDate.
pageNo0-indexed page number. Default 0.
sortNoSort field. Prefix with "-" for descending. Common: "-transactionDate" (newest first), "transactionDate", "-pricePaid", "pricePaid". Default newest first.
townNoPost town, exact match (case-insensitive in practice), e.g. "WARRINGTON".
countyNoCounty, exact match, e.g. "GREATER MANCHESTER".
maxDateNoLatest sale date, YYYY-MM-DD (inclusive).
minDateNoEarliest sale date, YYYY-MM-DD (inclusive). Data starts 1995.
districtNoLocal district, exact match, e.g. "MANCHESTER".
maxPriceNoMaximum price paid in whole GBP (inclusive).
minPriceNoMinimum price paid in whole GBP (inclusive).
pageSizeNoResults per page, 1-500. Default 25.
postcodeNoUK postcode, UPPERCASE with a space, e.g. "WA2 8SN". Exact match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "maxPrice": 2000000,
+    "minDate": "2020-01-01",
+    "minPrice": 500000,
+    "pageSize": 25,
+    "postcode": "SW1A 1AA",
+    "sort": "-transactionDate"
+  },
+  {
+    "county": "GREATER MANCHESTER",
+    "maxDate": "2024-12-31",
+    "minDate": "2023-01-01",
+    "page": 0,
+    "sort": "-pricePaid",
+    "town": "MANCHESTER"
+  }
+]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context such as postcode format requirements (uppercase with space) and data start year (1995). No contradictions.

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?

The description is 4 sentences, front-loading the core purpose. It is concise without waste, though could be slightly more compact by merging some sentences.

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?

Given 12 parameters, no output schema, and rich annotations, the description covers the main aspects: data source, filters, return content, and format rules. It lacks pagination details but schema covers that.

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 the parameters are fully documented. The description adds overall context (e.g., filters, return fields) but does not significantly elaborate on individual parameters beyond the schema.

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 clearly states the tool searches HM Land Registry Price Paid records for residential property sales in England & Wales since 1995, with specific filters and return fields. It is distinct from sibling tools like lookup_postcode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use the tool (filters, sorting, pagination) but does not explicitly state when to use this tool versus alternatives like lookup_postcode or when not to use it. It lacks exclusions or prerequisites.

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

All Landregistry Uk 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