英国の不動産データを1つのパッケージにまとめました。Land Registryの売買記録、EPC証明書、Rightmoveのリスティング、賃貸利回り、印紙税計算、計画ポータルリンク、Companies Houseの記録を取得します。
Pythonライブラリ、CLI、HTTP API、またはMCPサーバーとして使用できます。
データソース | 返される内容 |
Land Registry PPD | 売買価格、日付、物件タイプ、中央値/パーセンタイル付きのエリア比較 |
EPC (GOV.UK) | エネルギー評価、床面積、暖房費。イングランドとウェールズのみ。証明書検索と概要検索 — 下記のEPCに関する注意を参照 |
Rightmove | 現在のリスティング（売買+賃貸）、価格、エージェント、リスティング詳細 |
Yield Analysis | PPD売買とRightmove賃貸を組み合わせた総利回り |
Stamp Duty | 2025年4月の税率帯、BTL追加税、FTB軽減を考慮したSDLT計算 |
Block Analyzer | 建物ごとにフラット売買をグループ化して投資家の出口を特定 |
Planning | 地方自治体の計画ポータル検索（検証済み99自治体、stdioのみ） |
Companies House | 会社名または番号による会社検索と照会 |
Related MCP server: UK Due Diligence
PropertyパックとLegalパックは近日公開予定です。英国の不動産投資、英国の不動産エージェント、不動産および権利移転に関する実務経験や専門知識をお持ちで、このプロジェクトの形成に協力したい方は、paul@bouch.devまでご連絡ください。
インストール不要 — MCPクライアントの設定にURLを貼り付けるだけです。
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]、HTTPサーバー用の[api]、テスト用の[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 with { "address": "10 Downing Street, SW1A 2AA" }
完全なエンドポイント一覧はUSER_GUIDE.mdにあります。
EPCサービスはGOV.UKのBearer APIに移行しました。EPC_API_TOKENを設定してください。以前のEPC_API_EMAIL/EPC_API_KEYのペアは廃止されたホストに対して認証されており、サポートされているフォールバックではありません。
新しいアップストリームがサポートするものと、サポートしないもの:
証明書検索 — 証明書番号による検索で、1リクエストで完全な詳細を取得。
概要検索 — 郵便番号による検索で、住所、UPRN（多くの場合欠落）、エネルギー帯、登録日、スキーマタイプを返します。エネルギースコア、床面積、物件タイプは返しません。これらは完全な証明書にのみ存在します。
郵便番号はエリアを選択し、物件を選択することはありません。 1つの物件を特定するには、UPRNまたは証明書と完全に一致する住所（大文字小文字、句読点、先頭のFlat/Apartment指定子を除く）が必要です。それ以外（住所なし、一致なし、複数一致）は、最良の推測に解決されるのではなく拒否されます。CLIおよびRESTの表面についてはUSER_GUIDE.mdを参照してください。
エリア統計は、レコード数と、制限されたレスポンスにすべての一致する概要が含まれている場合の評価分布に限定されます。物件タイプの内訳と床面積の統計はNoneとして報告されます — ゼロではなく利用不可 — なぜなら、それらを生成するには証明書ごとに1リクエストが必要になるからです。
対象はイングランドとウェールズです。 スコットランド、北アイルランド、チャンネル諸島では「証明書が見つかりません」が返されます。これは対象範囲の境界であり、物件に関する記述ではありません。
ページネーションは安定したスナップショットではありません。 レスポンスには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 dataからの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 -vhttps://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,
