영국 부동산 데이터를 하나의 패키지로 제공합니다. 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 팩이 곧 제공될 예정입니다. 영국 부동산 투자, 영국 부동산 중개, 부동산 및 권리 이전(Conveyencing)에 대한 실무 경험 또는 전문 지식이 있고 이 프로젝트를 함께 만들어 가고 싶다면 연락해 주세요. 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], 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 쌍은 폐기된 호스트에 대해 인증되었으며 지원되는 대체 수단이 아닙니다.
새 업스트림이 지원하는 것과 지원하지 않는 것:
인증서 조회 — 인증서 번호로 전체 상세 정보를 한 번의 요청으로 조회합니다.
요약 검색 — 우편번호로 주소, UPRN(종종 없음), 에너지 등급, 등록 날짜 및 스키마 유형을 반환합니다. 에너지 점수, 바닥 면적 또는 주택 유형은 반환하지 않습니다. 이러한 정보는 전체 인증서에만 존재합니다.
우편번호는 지역을 선택하며, 특정 주택을 선택하지 않습니다. 특정 주택을 식별하려면 UPRN 또는 인증서와 정확히 일치하는 주소가 필요합니다(대소문자, 구두점, 앞의 Flat/Apartment 지정자는 제외). 주소가 없거나, 일치하지 않거나, 여러 개가 일치하는 경우에는 최선의 추측으로 해결하지 않고 거부됩니다. CLI 및 REST 인터페이스는 USER_GUIDE.md를 참조하세요.
지역 통계는 레코드 수와, 제한된 응답에 모든 일치하는 요약이 포함된 경우 등급 분포로 제한됩니다. 주택 유형별 분석 및 바닥 면적 통계는 None으로 보고됩니다. 이는 0이 아니라 사용 불가를 의미하며, 이를 생성하려면 인증서당 하나의 요청이 필요하기 때문입니다.
적용 범위는 잉글랜드와 웨일스입니다. 스코틀랜드, 북아일랜드 및 채널 제도는 "인증서를 찾을 수 없음"을 반환합니다. 이는 특정 주택에 대한 진술이 아니라 적용 범위 경계입니다.
페이지네이션은 안정적인 스냅샷이 아닙니다. 응답에는 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 -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,
