英国房产数据一应俱全。拉取土地注册局销售记录、EPC 证书、Rightmove 房源、租金收益率、印花税计算、规划门户链接以及 Companies House 记录。
可将其用作 Python 库、CLI、HTTP API 或 MCP 服务器。
数据源 | 返回内容 |
Land Registry PPD | 成交价、日期、房产类型、区域对比（含中位数/百分位数） |
EPC (GOV.UK) | 能效等级、建筑面积、供暖成本。仅限英格兰和威尔士。证书查询和摘要搜索——见下方 EPC 说明 |
Rightmove | 当前房源（出售 + 出租）、价格、中介、房源详情 |
收益率分析 | 结合 PPD 销售和 Rightmove 出租数据计算毛收益率 |
印花税 | 按 2025 年 4 月税率计算 SDLT，含 BTL 附加费、首次购房者减免 |
楼宇分析器 | 按建筑分组公寓销售，以发现投资者退出 |
规划 | 地方议会规划门户查询（99 个已验证议会，仅限 stdio） |
Companies House | 按名称或编号搜索和查询公司 |
Related MCP server: UK Due Diligence
Property 和 Legal 包即将推出。如果您在英国房产投资、英国房产中介、房产与产权转让方面有实际经验或专业知识，并希望帮助塑造此项目，请联系我们。 paul@bouch.dev
无需安装——将 URL 粘贴到您的 MCP 客户端配置中即可使用。
Claude Code、Cursor 以及任何 MCP 客户端：
{
"mcpServers": {
"property-shared": {
"type": "http",
"url": "https://property-shared.fly.dev/mcp"
}
}
}pip install property-shared
# or with uv
uv add property-shared附加项：[cli] 用于 CLI，[api] 用于 HTTP 服务器，[dev] 用于测试。
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}%)")所有模型都在顶层可用：
from property_core import (
PPDTransaction, PPDCompsResponse, EPCData,
RightmoveListing, RightmoveListingDetail,
PropertyReport, YieldAnalysis, RentalAnalysis,
BlockAnalysisResponse, CompanyRecord, StampDutyResult,
)解释辅助函数（核心返回数字，由您决定如何标注它们）：
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 F在任何命令中添加 --api-url http://localhost:8000 即可通过 HTTP API 路由，而不是直接调用核心。
pip install property-shared[api] # or: uv add property-shared --extra api
property-api # starts on port 8000交互式文档位于 http://localhost:8000/docs。
关键端点：
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 使用 { "address": "10 Downing Street, SW1A 2AA" }
EPC 服务已迁移到 GOV.UK Bearer API。设置 EPC_API_TOKEN；旧的 EPC_API_EMAIL/EPC_API_KEY 组合针对已退役的主机进行身份验证，不再作为受支持的备用方案。
新的上游服务支持什么，不支持什么：
证书查询：按证书编号查询——完整详情，一次请求。
摘要搜索：按邮政编码搜索——返回地址、UPRN（通常缺失）、能效等级、注册日期和模式类型。它不返回能效评分、建筑面积或房产类型；这些仅存在于完整证书中。
邮政编码选择的是区域，而不是房产。 识别单个房产需要 UPRN 或与证书完全匹配的地址（大小写、标点以及开头的 Flat/Apartment 标识符除外）。任何不完整的情况——无地址、无匹配或多个匹配——都会被拒绝，而不是解析为最佳猜测。CLI 和 REST 接口见 USER_GUIDE.md。
区域统计仅限于记录数，以及当有界响应包含所有匹配摘要时的评级分布。房产类型细分和建筑面积统计报告为 None——不可用，而非零——因为生成它们意味着每个证书一次请求。
覆盖范围是英格兰和威尔士。 苏格兰、北爱尔兰和海峡群岛返回“未找到证书”：这是覆盖边界，而非对房产的陈述。
分页不是稳定的快照。 响应包含 complete、duplicates_removed 和 unusable_rows；没有任何操作声称对某个区域进行了完整采集。
模糊的地址匹配会被拒绝，而不是解析为任意相邻证书。
不支持 search_all_by_postcode()——使用 search_summaries() 发现候选，然后使用 get_certificate() 获取您需要的那个。
在仓库根目录创建 .env 文件（已被 gitignore），包含您需要的变量。
完全省略可选变量，而不是将其赋为空值。
KEY=设置的是空字符串，这与未设置不同：os.getenv("KEY", "default")返回""，因此默认值永远不会生效。这影响了 EPC 实时测试，它们向上游发送了空邮政编码。
关键变量：
变量 | 用于 | 描述 |
| EPC 查询 | 来自 GOV.UK EPC 数据 的 Bearer 令牌 |
| （已弃用） | 已退役服务；仅解析以引发配置错误 |
| （已弃用） | 已退役服务；不是受支持的备用方案 |
| 公司搜索 | 来自 Companies House 的免费密钥 |
| 否（默认 0.6 秒） | Rightmove 抓取的速率限制延迟 |
| 规划抓取器 | 视觉引导的规划门户抓取器 |
Land Registry PPD 和 Rightmove 无需凭据即可工作。
# 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 -v部署在 https://property-shared.fly.dev，API 文档位于 /docs，MCP 端点位于 /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,
