Datos de propiedades del Reino Unido en un solo paquete. Obtiene ventas del Land Registry, certificados EPC, listados de Rightmove, rendimientos de alquiler, cálculos de impuesto de timbre, enlaces al portal de planificación y registros de Companies House.
Úsalo como biblioteca de Python, CLI, API HTTP o servidor MCP.
Fuente de datos | Qué devuelve |
Land Registry PPD | Precios de venta, fechas, tipos de propiedad, comparativas de zona con mediana/percentiles |
EPC (GOV.UK) | Calificaciones energéticas, superficie, costes de calefacción. Solo Inglaterra y Gales. Búsqueda de certificados y resumen — ver notas de EPC más abajo |
Rightmove | Listados actuales (venta + alquiler), precios, agentes, detalles del listado |
Análisis de rendimiento | Rendimiento bruto combinando ventas de PPD y alquileres de Rightmove |
Impuesto de timbre | Cálculo de SDLT con tramos de abril de 2025, recargo BTL, exención para compradores primerizos |
Analizador de bloques | Agrupa ventas de pisos por edificio para detectar salidas de inversores |
Planificación | Búsqueda en el portal de planificación del ayuntamiento local (99 ayuntamientos verificados, solo stdio) |
Companies House | Búsqueda y consulta de empresas por nombre o número |
Related MCP server: UK Due Diligence
Paquetes de propiedades y legales próximamente. Ponte en contacto si tienes experiencia práctica o conocimiento experto en inversión inmobiliaria en el Reino Unido, agencias inmobiliarias británicas, propiedades y transmisiones, y te gustaría ayudar a dar forma a esto. paul@bouch.dev
No requiere instalación: pega la URL en la configuración de tu cliente MCP y listo.
Claude Code, Cursor, cualquier cliente MCP:
{
"mcpServers": {
"property-shared": {
"type": "http",
"url": "https://property-shared.fly.dev/mcp"
}
}
}pip install property-shared
# or with uv
uv add property-sharedExtras: [cli] para CLI, [api] para servidor HTTP, [dev] para pruebas.
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}%)")Todos los modelos están disponibles en el nivel superior:
from property_core import (
PPDTransaction, PPDCompsResponse, EPCData,
RightmoveListing, RightmoveListingDetail,
PropertyReport, YieldAnalysis, RentalAnalysis,
BlockAnalysisResponse, CompanyRecord, StampDutyResult,
)Ayudantes de interpretación (el núcleo devuelve números, tú decides cómo etiquetarlos):
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 FAñade --api-url http://localhost:8000 a cualquier comando para enrutar a través de la API HTTP en lugar de llamar directamente al núcleo.
pip install property-shared[api] # or: uv add property-shared --extra api
property-api # starts on port 8000Documentación interactiva en http://localhost:8000/docs.
Puntos finales clave:
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 con { "address": "10 Downing Street, SW1A 2AA" }
Lista completa de puntos finales en USER_GUIDE.md.
El servicio de EPC se trasladó a una API Bearer de GOV.UK. Configura EPC_API_TOKEN; el antiguo par EPC_API_EMAIL/EPC_API_KEY autenticaba contra un host retirado y no es un respaldo compatible.
Lo que admite el nuevo proveedor y lo que no:
Búsqueda de certificado por número de certificado: detalle completo, una solicitud.
Búsqueda de resumen por código postal: devuelve dirección, UPRN (a menudo ausente), banda energética, fecha de registro y tipo de esquema. No devuelve puntuación energética, superficie ni tipo de propiedad; esos datos solo existen en un certificado completo.
Un código postal selecciona un área, nunca una propiedad. Identificar una propiedad requiere un UPRN o una dirección que coincida exactamente con un certificado (salvo mayúsculas, puntuación y un designador inicial Flat/Apartment). Cualquier cosa menos — sin dirección, sin coincidencia o varias coincidencias — se rechaza en lugar de resolverse a una suposición. Consulta USER_GUIDE.md para las superficies CLI y REST.
Las estadísticas de área se limitan al recuento de registros y, cuando la respuesta acotada contiene todos los resúmenes coincidentes, a la distribución de calificaciones. El desglose por tipo de propiedad y las estadísticas de superficie se informan como None — no disponibles, no cero — porque producirlos implicaría una solicitud por certificado.
La cobertura es Inglaterra y Gales. Escocia, Irlanda del Norte y las Islas del Canal devuelven "no se encontraron certificados": un límite de cobertura, no una declaración sobre una propiedad.
La paginación no es una instantánea estable. Las respuestas incluyen complete, duplicates_removed y unusable_rows; ninguna operación afirma una recolección completa de un área.
Las coincidencias de dirección ambiguas se rechazan en lugar de resolverse a un certificado vecino arbitrario.
search_all_by_postcode() no es compatible: usa search_summaries() para descubrir candidatos y luego get_certificate() para el que necesites.
Crea un archivo .env en la raíz del repositorio (está en gitignore) con las variables que necesites.
Deja las variables opcionales completamente fuera en lugar de asignarlas vacías.
KEY=establece una cadena vacía, que no es lo mismo que no estar definida:os.getenv("KEY", "default")devuelve"", por lo que el valor predeterminado nunca se aplica. Esto afectó a las pruebas en vivo de EPC, que enviaron un código postal vacío al proveedor.
Variables clave:
Variable | Requerida para | Descripción |
| Búsquedas de EPC | Token Bearer de GOV.UK EPC data |
| (obsoleta) | Servicio retirado; se analiza solo para generar un error de configuración |
| (obsoleta) | Servicio retirado; no es un respaldo compatible |
| Búsqueda de empresas | Clave gratuita de Companies House |
| No (por defecto 0.6s) | Retardo de límite de velocidad para el scraping de Rightmove |
| Scraper de planificación | Scraper del portal de planificación guiado por visión |
Land Registry PPD y Rightmove funcionan sin credenciales.
# Install with dev extras
uv sync --extra dev
# Run API with reload
uv run uvicorn app.main:app --reload
# Run tests (mocked, no network)
uv run --extra dev pytest -v
# Run live integration tests (real network calls)
RUN_LIVE_TESTS=1 uv run --extra dev pytest -vDesplegado en https://property-shared.fly.dev con documentación de API en /docs y punto final MCP en /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.
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_dutyScored across 13 tools
Each 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.
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,
