A comprehensive UK property research tool aggregating data from Land Registry, EPC Register, Rightmove, Companies House, and more.
property_report: Full property report combining sales history, area comps, EPC rating, rental market, sales listings, yield, and price range — all in one call.
property_comps: Land Registry Price Paid Data for a postcode with optional EPC enrichment (floor area, price/sqft) and auto-escalation to wider area if results are sparse.
ppd_transactions: Search Land Registry sold price records by postcode, address, date range, or price filters.
property_yield: Calculate gross rental yield by combining Land Registry sales data with live Rightmove rental listings.
rental_analysis: Get median/average rent, listing count, and rent range for a postcode, with optional yield calculation from a given purchase price.
property_epc: Retrieve EPC data for a specific property (energy rating, floor area, construction age, heating costs) or area-level aggregation.
rightmove_search: Search current Rightmove listings for sale or rent, with filters for price, bedrooms, building type, and sort order.
rightmove_listing: Fetch full details for a specific listing including tenure, lease years, service charge, ground rent, council tax band, floor area, and floorplans.
property_blocks: Identify buildings with multiple recent flat sales to spot investor exits or bulk-buy opportunities.
stamp_duty: Calculate UK SDLT with support for additional property surcharge, first-time buyer relief, and non-resident surcharge.
planning_search: Find the local council planning portal URL for any UK postcode.
company_search: Search Companies House by company name.
company_profile: Retrieve a full Companies House record by company number, including address, status, incorporation date, officers, and filing history.
Environment configuration for API keys including EPC Register credentials, Companies House API key, Rightmove rate limiting, and OpenAI API key for planning portal scraping.
Provides HTTP API wrapper for property data services with endpoints for comparable sales, rental analysis, Rightmove searches, stamp duty calculations, and property reports.
Deployment platform for hosting the property data service with API endpoints and MCP server accessible via HTTP transport.
Source code repository hosting the property-shared project with MCP server implementation and deployment configuration.
Uses OpenAI's vision API for automated planning portal scraping to extract planning application data from UK local council websites.
Testing framework used for both mocked unit tests and live integration tests with real network calls to property data sources.
Core library implementation providing business logic for property data analysis including Land Registry PPD, EPC certificates, Rightmove listings, and yield calculations.
CLI interface for property data tools enabling command-line access to comparable sales, rental yield analysis, stamp duty calculations, and Rightmove searches.
UK property data in one package. Pulls Land Registry sales, EPC certificates, Rightmove listings, rental yields, stamp duty calculations, planning portal links, and Companies House records.
Use it as a Python library, CLI, HTTP API, or MCP server.
Data Source | What It Returns |
Land Registry PPD | Sold prices, dates, property types, area comps with median/percentiles |
EPC (GOV.UK) | Energy ratings, floor area, heating costs. England & Wales only. Certificate lookup and summary search — see EPC notes below |
Rightmove | Current listings (sale + rent), prices, agents, listing details |
Yield Analysis | Gross yield from PPD sales + Rightmove rentals combined |
Stamp Duty | SDLT calculation with April 2025 bands, BTL surcharge, FTB relief |
Block Analyzer | Groups flat sales by building to spot investor exits |
Planning | Local council planning portal lookup (99 verified councils, stdio only) |
Companies House | Company search and lookup by name or number |
Related MCP server: UK Due Diligence
Property and Legal packs coming soon. Please get in contact if you have working experiance or expert knowledge in UK property investing, UK Estate Agents, Property and Conveyencing and would like to help shape this. paul@bouch.dev
No install required — paste the URL into your MCP client config and go.
Claude Code, Cursor, any MCP client:
{
"mcpServers": {
"property-shared": {
"type": "http",
"url": "https://property-shared.fly.dev/mcp"
}
}
}pip install property-shared
# or with uv
uv add property-sharedExtras: [cli] for CLI, [api] for HTTP server.
pip install property-shared[cli]
# or
uv add property-shared --extra clifrom property_core import PPDService, calculate_yield, calculate_stamp_duty
# Get comparable sales for a postcode
comps = PPDService().comps("SW1A 1AA", months=24, property_type="F")
print(f"Median flat price: {comps.median:,}")
# Calculate rental yield
import asyncio
result = asyncio.run(calculate_yield("NG1 1AA", property_type="F"))
print(f"Gross yield: {result.gross_yield_pct}%")
# Stamp duty
sdlt = calculate_stamp_duty(250000, additional_property=True)
print(f"SDLT: {sdlt.total_sdlt:,.0f} ({sdlt.effective_rate}%)")All models are available at top level:
from property_core import (
PPDTransaction, PPDCompsResponse, EPCData,
RightmoveListing, RightmoveListingDetail,
PropertyReport, YieldAnalysis, RentalAnalysis,
BlockAnalysisResponse, CompanyRecord, StampDutyResult,
)Interpretation helpers (core returns numbers, you decide how to label them):
from property_core import classify_yield, classify_data_quality, generate_insightspip install property-shared[cli] # or: uv add property-shared --extra cli
# Comparable sales
property-cli ppd comps "SW1A 1AA" --months 24 --property-type F
# Rental yield
property-cli analysis yield "NG1 1AA" --property-type F
# Stamp duty
property-cli calc stamp-duty 300000
# Rightmove search (with sort)
property-cli rightmove search-url "NG1 1AA" --sort-by most_reduced
# Full property report
property-cli report generate "10 Downing Street, SW1A 2AA" --property-type FAdd --api-url http://localhost:8000 to any command to route through the HTTP API instead of calling core directly.
pip install property-shared[api] # or: uv add property-shared --extra api
property-api # starts on port 8000Interactive docs at http://localhost:8000/docs.
Key endpoints:
GET /v1/ppd/comps?postcode=SW1A+1AA&property_type=F&enrich_epc=true
GET /v1/analysis/yield?postcode=NG1+1AA&property_type=F
GET /v1/analysis/rental?postcode=NG1+1AA&purchase_price=200000
GET /v1/rightmove/search-url?postcode=NG1+1AA&sort_by=newest
GET /v1/calculators/stamp-duty?price=300000&additional_property=true
POST /v1/property/report with { "address": "10 Downing Street, SW1A 2AA" }
Full endpoint list in USER_GUIDE.md.
The EPC service moved to a GOV.UK Bearer API. Set EPC_API_TOKEN; the old
EPC_API_EMAIL/EPC_API_KEY pair authenticated against a retired host and is
not a supported fallback.
What the new upstream supports, and what it does not:
Certificate lookup by certificate number — full detail, one request.
Summary search by postcode — returns address, UPRN (often absent), energy band, registration date and schema type. It does not return energy score, floor area or property type; those exist only on a full certificate.
A postcode selects an area, never a property. Identifying one property
needs a UPRN or an address matching a certificate exactly (case, punctuation
and a leading Flat/Apartment designator aside). Anything less — no address,
no match, or several matches — is refused rather than resolved to a best guess.
See USER_GUIDE.md for the CLI and REST surfaces.
Area statistics are limited to the record count and, when the bounded
response contains every matching summary, the rating distribution.
Property-type breakdown and floor-area statistics are reported as None —
unavailable, not zero — because producing them would mean one request per
certificate.
Coverage is England and Wales. Scotland, Northern Ireland and the Channel Islands return "no certificates found": a coverage boundary, not a statement about a property.
Pagination is not a stable snapshot. Responses carry complete,
duplicates_removed and unusable_rows; no operation claims a complete
harvest of an area.
Ambiguous address matches are refused rather than resolved to an arbitrary neighbouring certificate.
search_all_by_postcode() is unsupported — use search_summaries() for
candidate discovery, then get_certificate() for the one you need.
Create a .env file in the repo root (it is gitignored) with the variables you need.
Leave optional variables out entirely rather than assigning them empty.
KEY=sets an empty string, which is not the same as unset:os.getenv("KEY", "default")returns"", so the default never applies. This bit the EPC live tests, which sent an empty postcode upstream.
Key variables:
Variable | Required For | Description |
| EPC lookups | Bearer token from GOV.UK EPC data |
| (deprecated) | Retired service; parsed only to raise a configuration error |
| (deprecated) | Retired service; not a supported fallback |
| Company search | Free key from Companies House |
| No (default 0.6s) | Rate limit delay for Rightmove scraping |
| Planning scraper | Vision-guided planning portal scraper |
Land Registry PPD and Rightmove work without credentials.
# Install dependencies (dev tooling installs by default via [dependency-groups])
uv sync
# Run API with reload
uv run --extra api uvicorn app.main:app --reload
# Full validation (lockfile check, pre-commit, all extras, full suite) —
# same entrypoint CI and the release gate use
./scripts/validate.sh
# + live integration tests (real network calls)
RUN_LIVE_TESTS=1 ./scripts/validate.shDeployed at https://property-shared.fly.dev with API docs at /docs and MCP endpoint at /mcp.
Get the full Companies House record for a company by number.
Returns registered address, status, incorporation date, officers, and filing history. Use company_search to find a company number by name.
| Name | Required | Description | Default |
|---|---|---|---|
| company_number | Yes | Companies House number (e.g. '00445790'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lists the returned fields but does not explicitly state that the operation is read-only or non-destructive. While the nature implies a safe read, the description could be more transparent about side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every sentence adds value. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single required parameter, no output schema, no nested objects), the description is sufficient. It lists key return fields, explains how to obtain the required input via a sibling tool, and covers the essential context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'company_number' has a description in the schema). The description does not add additional meaning beyond what the schema provides; it only restates that the tool retrieves records 'by number.' Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the full Companies House record for a company by number.' It specifies the action (get), resource (Companies House record), and how to identify the company (by number). It distinguishes from sibling 'company_search' by mentioning that search is for finding the number by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool versus the sibling: 'Use company_search to find a company number by name.' This provides clear guidance on prerequisites and alternative tool usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Companies House by company name. Returns a list of matches.
For a direct lookup by company number, use the company://{company_number} resource instead (e.g. read_resource("company://00445790")).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name to search (e.g. "Tesco", "Rightmove plc") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It clarifies the tool is a search that returns matches, implying read-only behavior. While it doesn't elaborate on rate limits or pagination, for a simple search this is sufficient and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no wasted words. The key action and alternative are front-loaded, making it easy for an agent to quickly understand and act.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is complete. It explains the search function, provides example inputs, and directs to an alternative for specific lookups. No additional details are needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' is described in the schema with a clear description and example values ('Tesco', 'Rightmove plc') in the tool description, adding concrete context beyond the schema's minimal description. This helps the agent form valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Companies House by company name' and specifies it returns a list of matches, making the purpose unambiguous. It also distinguishes from the sibling tool company_profile by hinting at an alternative resource lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (search by name) and provides a clear alternative for direct company number lookup via a resource, including an example. This guides the agent to choose correctly between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the planning portal URL for a UK postcode.
Returns the council name, planning system type, and a direct URL to open in a browser. Does NOT return planning application data — scraping is blocked by council portals. Use the returned search_urls.direct_search link to browse applications manually.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. "S1 1AA", "SW1A 2AA") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool does not return planning application data because scraping is blocked, and that the returned URL can be used to browse manually. This is good transparency about limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose. Every sentence adds value: purpose, outputs, limitations, usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is complete. It explains what it does, returns, limitations, and how to use the result. Sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'postcode' well-described in schema. The description adds no significant additional meaning beyond 'UK postcode' examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the planning portal URL for a UK postcode. It specifies the output (council name, planning system type, direct URL) and distinguishes from siblings by noting what it does NOT return (planning application data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: to find the planning portal URL for a postcode. It also states what not to use it for: does not return planning application data, and instead provides guidance to use the returned URL to browse manually. However, it doesn't explicitly name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Land Registry transactions by postcode, address, date range, or price.
Use for specific property history ("what has 10 Downing Street sold for?") or filtered market queries ("all sales over 500k in SW1 last year").
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | No | UK postcode (e.g. "SW1A 1AA") - required for postcode search | |
| street | No | Street name for address-based search | |
| town | No | Town name for address-based search | |
| paon | No | Primary address (house name/number) for address-based search | |
| from_date | No | Start date filter (ISO format, e.g. "2023-01-01") | |
| to_date | No | End date filter (ISO format) | |
| min_price | No | Minimum price filter in £ | |
| max_price | No | Maximum price filter in £ | |
| property_type | No | Filter by type: F=flat, D=detached, S=semi, T=terraced | |
| limit | No | Max results to return (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It implies a read-only search operation, but does not explicitly state safety, potential side effects, or limitations like rate limits or pagination. The read-only nature is inferred from 'search' but not guaranteed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no superfluous words. The purpose is stated first, followed by usage examples. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description is incomplete. It does not explain parameter interactions (e.g., whether at least one criterion is required), default behavior, or return format. Should clarify these for a complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no parameter-specific details beyond the schema. Baseline score of 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search Land Registry transactions' with specific search criteria (postcode, address, date range, price). It distinguishes from siblings like 'planning_search' and 'property_comps' by focusing on transaction data and providing concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides two clear use case examples: specific property history and filtered market queries. While it doesn't explicitly exclude scenarios or mention alternatives, the examples effectively communicate when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find buildings with multiple flat sales — block buying opportunities.
Groups Land Registry transactions by building to identify blocks being sold off, investor exits, and bulk-buy opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. "B1 1AA") | |
| months | No | Lookback period in months (default 24) | |
| min_transactions | No | Minimum sales per building to qualify (default 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It mentions grouping Land Registry transactions but omits details on data recency, limitations, or whether results are filtered, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the key purpose, and contains no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what the tool returns. It does not describe the response format or fields, leaving the agent unsure about the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds context on grouping but not enough to raise the score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and resource 'buildings with multiple flat sales', and distinguishes itself from siblings like 'ppd_transactions' by focusing on block-buying opportunities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying bulk-buy opportunities and investor exits but does not explicitly state when to use this tool versus alternatives like 'property_comps' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comparable property sales from Land Registry Price Paid Data.
Auto-escalates to wider search area if fewer than 5 results found. EPC enrichment adds floor area, price/sqft, and EPC rating to each comp, plus area-level median price/sqft and EPC match rate.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. "SW1A 1AA", "NG11 9HD") | |
| months | No | Lookback period in months (default 24) | |
| limit | No | Max transactions to return (default 30) | |
| search_level | No | Search area granularity - usually leave as default | sector |
| address | No | Optional street address to identify subject property and show percentile rank | |
| property_type | No | Filter by type: F=flat, D=detached, S=semi, T=terraced (default all) | |
| enrich_epc | No | Add floor area, price/sqft, and EPC rating to each comp (default true) | |
| auto_escalate | No | Widen search area if fewer than 5 results (default true). Set false to keep results local — useful when district-level escalation would include irrelevant areas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses two key behaviors: auto-escalation and EPC enrichment. However, it does not mention any potential destructive actions, rate limits, or response format. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two short sentences. The first sentence states the core purpose, and the second details key behaviors. No unnecessary words or redundancy. Ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description covers the main behaviors but lacks details on return format, pagination, or how to interpret results. It explains EPC enrichment fields but not base transaction fields. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for the 'auto_escalate' and 'enrich_epc' parameters by explaining their default effects. However, it does not significantly deepen understanding of other parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides comparable property sales from Land Registry Price Paid Data. It mentions auto-escalation and EPC enrichment, which adds specificity. However, it does not explicitly differentiate from sibling tools like ppd_transactions or property_report, which could also involve sales data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It does not mention when not to use it, nor does it reference sibling tools. The context of 'comparable sales' is implied but not reinforced with decision rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EPC certificate data for a UK property or postcode area.
With address: returns the matched certificate for that property — energy rating, score, floor area, construction age, heating costs.
Without address: returns all certificates at the postcode with area-level aggregation (rating distribution, floor area range, property type breakdown). Use this for area analysis rather than a single-property lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. "SW1A 1AA") | |
| address | No | Street address for exact match (omit for area view) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes return values for both modes (energy rating, score, floor area, etc.) but does not explicitly state it is a read-only query or mention any potential side effects, rate limits, or authentication. Implicitly safe but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states general purpose, then two bullet-like sentences for each mode. No wasted words, front-loaded with core function. Excellent structure for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's two-mode complexity and lack of output schema, the description covers both modes and specifies returned fields for each. Could mention expected output structure or error cases, but is largely sufficient for an agent to decide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value: explains the behavioral difference when address is provided vs omitted, and lists the output fields for both cases. Provides context beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves EPC certificate data for UK property or postcode area, with two distinct modes: with address returns specific certificate details, without address returns area-level aggregation. Distinguishes from sibling tools by specifying its exact resource and behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use each mode: 'Use this for area analysis rather than a single-property lookup.' Clearly indicates that omitting the address gives area aggregation. Does not explicitly exclude sibling tools but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full data pull for a UK property in one call.
Returns sale history, area comps, EPC rating, rental market listings, current sales market listings, rental yield calculation, and price range from area median.
Requires a street address + postcode for subject property identification. Postcode-only (e.g. "NG1 2NS") returns area-level data without a subject property — use property_comps or property_yield for postcode-only queries.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Street address with postcode, e.g. "10 Downing Street, SW1A 2AA" | |
| include_rentals | No | Include Rightmove rental market analysis (default true) | |
| include_sales_market | No | Include Rightmove sales market (default true) | |
| ppd_months | No | Lookback period for comparable sales (default 24) | |
| search_radius | No | Radius in miles for Rightmove searches (default 0.5) | |
| property_type | No | Filter comparable sales by type: F=flat, D=detached, S=semi, T=terraced (default all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by name and returns data, but does not explicitly state behavioral traits (e.g., external API calls, potential latency, rate limits, or permission requirements). A score of 3 reflects adequate but not fully transparent behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no redundancy. The main purpose is front-loaded in the first sentence, and subsequent sentences add necessary context about requirements and alternatives. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description lists key return data types (sale history, area comps, EPC, rental yield, etc.), providing a solid overview. However, it does not describe output structure, pagination, or how to interpret results, which would make it more complete. Still, it is adequate for an agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description does not add significant meaning beyond what the schema already provides (e.g., it mentions 'street address + postcode' but that matches the required parameter's description). No extra context for optional parameters like include_rentals or search_radius.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Full data pull for a UK property in one call' and enumerates specific data categories (sale history, area comps, EPC, rental yield, etc.), clearly defining the tool's function. It also contrasts with siblings by noting postcode-only queries should use property_comps or property_yield, distinguishing it effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use full address vs. postcode-only, and directs to alternative tools: 'Postcode-only... use property_comps or property_yield for postcode-only queries.' This provides clear guidance on appropriate usage scenarios and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate rental yield for a UK postcode.
Combines Land Registry sales data with Rightmove rental listings to produce a gross yield figure.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. "NG11", "SW1A 1AA") | |
| months | No | Sales lookback period in months (default 24) | |
| search_level | No | "sector" (recommended), "district", or "postcode" | sector |
| property_type | No | Filter comparable sales by type: F=flat, D=detached, S=semi, T=terraced (default all) | |
| radius | No | Rental search radius in miles (default 0.5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully inform about behavior. It mentions combining data sources but not limitations, data freshness, or error cases. The tool appears safe (read-only), but this is implied rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and method. No redundant or filler words, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions a gross yield figure. Parameters are documented in schema. However, it omits details like return format or handling of missing data, making it marginally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is documented. The description adds no extra nuance beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates rental yield for a UK postcode using specific data sources. It distinguishes from sibling tools like 'rental_analysis' by focusing on a single gross yield figure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives such as 'rental_analysis' or 'property_comps'. No when-not or context of use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rental market analysis for a UK postcode.
Returns median/average rent, listing count, and rent range. Optionally calculates gross yield from a given purchase price. Auto-escalates search radius if local listings are sparse (thin market).
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. "NG1 1AA") | |
| radius | No | Search radius in miles (default 0.5) | |
| purchase_price | No | Optional purchase price to calculate gross yield | |
| auto_escalate | No | Widen radius if fewer than 3 listings found (default true) | |
| building_type | No | Filter by building type: F=flat, D=detached, S=semi, T=terraced (default all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses auto-escalation of search radius when listings are sparse, which is important. However, it lacks details on data sources, freshness, accuracy, or any side effects. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Efficiently conveys core functionality and key behaviors.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers the main outputs and behaviors (yield calculation, auto-escalation). It could mention the yield formula or output format, but overall it provides sufficient context for an agent to understand what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 5 parameters documented). The description adds slight contextual reinforcement (e.g., 'optionally calculates gross yield' for purchase_price, 'auto-escalates' for auto_escalate) but largely echoes the schema definitions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs rental market analysis for a UK postcode, returns specific metrics (median/average rent, listing count, rent range), and optionally calculates gross yield. It is distinct from sibling tools like 'property_yield' (which focuses on yield) or 'ppd_transactions' (sales data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for rental analysis in a UK postcode but does not explicitly compare to alternatives or state when not to use it. The auto-escalation and yield calculation are mentioned but no direct guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for a Rightmove listing by ID or URL.
Returns price, tenure, lease years remaining, service charge, ground rent, council tax band, floor area, key features, nearest stations, and floorplan URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes | Rightmove property URL (e.g. "https://www.rightmove.co.uk/properties/12345678") or numeric ID (e.g. "12345678") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose side effects, auth requirements, error handling, or rate limits. It only describes return fields, which is insufficient for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficiently communicates core functionality and returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema but description lists all return fields. Lacks error handling details and use-case guidance, but for a simple retrieval tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already explains it accepts URL or numeric ID. The description does not add meaningful extra detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch full details for a Rightmove listing by ID or URL' listing the returned fields, and is distinct from sibling tools like rightmove_search which is for searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, but context implies usage after finding a listing. Could be improved by mentioning relationship to rightmove_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Rightmove property listings for sale or rent near a postcode.
Returns prices, addresses, bedrooms, agent details, and listing URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. "NG1 1AA", "SW1A 2AA") | |
| property_type | No | "sale" or "rent" (default "sale") | sale |
| building_type | No | Filter by building type: F=flat, D=detached, S=semi, T=terraced (default all) | |
| min_price | No | Minimum price/rent filter in £ | |
| max_price | No | Maximum price/rent filter in £ | |
| min_bedrooms | No | Minimum bedrooms filter | |
| max_bedrooms | No | Maximum bedrooms filter | |
| radius | No | Search radius in miles (default varies by area) | |
| max_pages | No | Max pages to fetch (default 1, ~25 listings per page) | |
| sort_by | No | Sort order: "newest", "oldest", "price_low", "price_high", "most_reduced" (default: Rightmove default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions return fields (prices, addresses, etc.) but omits behavioral traits such as rate limits, pagination behavior (beyond max_pages), or any side effects. The safety profile (read-only) is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core function, and contains no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is brief. While it explains the main output, it lacks details on error handling, output structure, or caveats for optional filters. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions; it only lists return types. No extra context for filters or default values is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Rightmove property listings for sale or rent near a postcode, specifying the verb 'search' and the resource 'Rightmove property listings' with modifiers. This distinguishes it from sibling tools like 'rightmove_listing' which likely retrieves a single listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for property search but does not provide explicit guidance on when to use this tool versus alternatives like company_search or planning_search. No exclusion criteria or recommended contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate UK Stamp Duty Land Tax (SDLT) for a residential property.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Purchase price in £ | |
| additional_property | No | True if buying additional property (+5% surcharge) | |
| first_time_buyer | No | True for first-time buyer relief (up to £300k nil rate) | |
| non_resident | No | True if buyer not UK resident (+2% surcharge) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only states 'Calculate', which is obvious. It does not disclose any behavioral traits like output format, rate sources, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words, efficiently communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple calculation tool but lacks mention of output format (e.g., returns tax amount as integer) or behavior with invalid inputs, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 parameters with descriptions (100% coverage), so the description adds no additional meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Calculate' and the resource 'UK Stamp Duty Land Tax (SDLT) for a residential property', making the tool's purpose explicit and distinct from siblings like company_search or property_yield.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other property calculators or general search tools. There are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.6.0company_profilecompany_searchplanning_searchppd_transactionsproperty_blocksproperty_compsproperty_epcproperty_reportproperty_yieldrental_analysisrightmove_listingrightmove_searchstamp_dutyv1.5.2company_profilecompany_searchplanning_searchppd_transactionsproperty_blocksproperty_compsproperty_epcproperty_reportproperty_yieldrental_analysisrightmove_listingrightmove_searchstamp_dutycompany_profilelist_resourcesread_resourcev1.5.1company_searchlist_resourcesplanning_searchppd_transactionsproperty_blocksproperty_compsproperty_epcproperty_reportproperty_yieldread_resourcerental_analysisrightmove_listingrightmove_searchstamp_dutyEach tool targets a distinct aspect of UK property data: company records, planning portals, transactions, blocks, comps, EPC, full reports, yield, rental analysis, Rightmove listings, and stamp duty. No two tools have overlapping purposes.
All tool names use a consistent snake_case pattern with descriptive noun_verb or adjective_noun structure (e.g., company_profile, rightmove_search, stamp_duty). No mixing of conventions.
With 13 tools covering the full spectrum of UK property data (companies, planning, transactions, EPC, rental, yield, stamp duty), the count is well-scoped and neither too sparse nor too heavy.
The tool surface covers the major needs for UK property analysis: company info, planning, transactional data, comparables, EPC, rental market, yields, listings, and stamp duty. The aggregate property_report tool fills gaps by combining multiple data sources.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
UK property MCP: Land Registry prices, company charges, House Price Index. x402 USDC on Base.
UK property research tools - crime stats, schools, demographics, valuations for AI.
UK area & property intelligence for AI agents: reports, EPC, comparables, with source provenance.
Property Records MCP — address-level US property records (sales history,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/paulieb89/property-shared'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
