UK Property Intelligence
Server Details
UK property data MCP server. Wraps Land Registry, Rightmove, EPC, rental yields, stamp duty, and Companies House into 13 tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 13 of 13 tools scored. Lowest: 3.3/5.
Most tools have distinct purposes, though property_yield and rental_analysis both touch on yield calculation, which could cause minor confusion. Otherwise, each tool is clearly scoped.
All tool names follow a consistent snake_case pattern, typically object_action (e.g., company_profile, property_blocks, rightmove_search), making them predictable and easy to understand.
With 13 tools covering company data, planning, transactions, EPC, rentals, listings, and stamp duty, the count is well-suited to the domain without being overwhelming or incomplete.
The toolset covers core property intelligence areas comprehensively, though a direct planning application data tool is missing (only URL provided) and no demographics or school data are included, which are minor gaps.
Available Tools
13 toolscompany_profileAInspect
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'). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It describes the tool as retrieving a full record, implying a read-only operation with no destructive side effects. It could be more explicit about safety (e.g., 'This is a read-only operation'), but the verb 'Get' and the listing of returned data sufficiently indicate transparency.
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 consists of two short sentences with no wasted words. It front-loads the core purpose and immediately provides useful output details. Every sentence 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?
For a simple tool with a single parameter and an existing output schema, the description is fully complete. It tells the user what to expect (full record with specific fields) and how to obtain the needed input (company_search). No gaps remain.
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 input schema covers 100% of parameters with a description for company_number. The tool description does not add any additional meaning beyond what the schema already provides. Per the scoring guide, when schema coverage is high, a baseline of 3 is appropriate without extra param info.
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 resource (company by number) and lists the types of data returned (address, status, incorporation date, officers, filing history). It also distinguishes from the sibling tool company_search by explaining when to use that instead.
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 this tool (when you have a company number) and directs the user to use company_search to find the number by name. This provides clear contextual guidance and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_searchAInspect
Search Companies House by company name. Returns a list of matches.
For a direct lookup by company number, use company_profile(company_number="00445790").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name to search (e.g. "Tesco", "Rightmove plc") |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adequately describes the read-only, non-destructive behavior of searching and returning matches. However, it lacks details about result limits, pagination, or authorization requirements, which are minor 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 long with no wasted words. It is front-loaded with the main purpose and immediately provides alternative usage. 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?
For a simple search tool with one parameter and an output schema (implied from context signals), the description is complete. It explains what the tool does, how to use it, and when to use a sibling tool. No critical information is missing.
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 input schema has 100% description coverage for the single parameter 'query', with examples provided. The description does not add significant meaning beyond the schema, placing it at 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 explicitly states 'Search Companies House by company name' and 'Returns a list of matches', providing a specific verb and resource. It distinguishes from sibling tool company_profile by noting that for direct lookup by company number, the other tool should be used.
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 clearly tells when to use this tool (search by name) and when to use an alternative ('For a direct lookup by company number, use company_profile(company_number="00445790")'). This provides explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
planning_searchAInspect
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") |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly discloses that the tool does NOT return planning application data and that scraping is blocked by council portals, which is essential behavioral context for an agent.
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 concise (4 sentences) and front-loaded with the primary action. Every sentence adds value, with 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?
For a simple tool with one parameter and existing output schema, the description covers purpose, limitations, and usage guidance completely. No additional info needed.
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 input schema has 100% coverage for the single parameter 'postcode'. The description does not add meaning beyond what the schema provides; it merely states the tool is for UK postcodes. 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 verb 'Find' and the resource 'planning portal URL for a UK postcode'. It distinguishes from sibling tools that return property data, such as property_report or rightmove_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 provides clear context: returns council name, system type, and direct URL; states what it does NOT return (planning application data) and why scraping is blocked. It also provides guidance on using the returned URL. However, it does not explicitly mention when not to use this tool or compare to specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ppd_transactionsAInspect
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 |
|---|---|---|---|
| paon | No | Primary address (house name/number) for address-based search | |
| town | No | Town name for address-based search | |
| limit | No | Max results to return (default 25) | |
| street | No | Street name for address-based search | |
| to_date | No | End date filter (ISO format) | |
| postcode | No | UK postcode (e.g. "SW1A 1AA") - required for postcode search | |
| from_date | No | Start date filter (ISO format, e.g. "2023-01-01") | |
| max_price | No | Maximum price filter in £ | |
| min_price | No | Minimum price filter in £ | |
| property_type | No | Filter by type: F=flat, D=detached, S=semi, T=terraced |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 describes the search behavior but omits details like result limits beyond default, pagination, error handling, or response format. Adding such details would improve transparency.
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: two sentences plus examples, no wasted words. The purpose is front-loaded, and every sentence adds meaningful guidance.
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 optional parameters and an output schema exists, the description covers the high-level search modes. It could note that at least one search criterion is expected (since no required params) and briefly mention typical data fields returned, but overall it is fairly 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?
The input schema has 100% description coverage, so the description adds only marginal value (e.g., grouping parameters into search types). It does not elaborate on parameter interactions or formatting beyond schema 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?
The description clearly states the tool searches Land Registry transactions by multiple criteria and provides concrete examples (e.g., specific property history, filtered market queries), effectively distinguishing it from sibling tools focused on reports, yields, or company 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 advises when to use the tool ('specific property history' or 'filtered market queries'), offering clear context. However, it does not explicitly mention when not to use it or name specific alternatives, though the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_blocksAInspect
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 |
|---|---|---|---|
| limit | No | Maximum number of blocks to return (default 50) | |
| months | No | Lookback period in months (default 24) | |
| postcode | Yes | UK postcode (e.g. "B1 1AA") | |
| search_level | No | Search granularity — "postcode", "sector", or "district" (default "sector") | sector |
| property_type | No | PPD property type filter — "F" for flats, None for all types (default "F") | F |
| min_transactions | No | Minimum sales per building to qualify (default 2) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It explains grouping by building and filtering by minimum transactions, which is adequate. However, it omits side effects, permissions, or data freshness. A bit more detail on output nature would improve transparency.
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 concise sentences with no wasted words. The first sentence front-loads the core purpose ('Find buildings with multiple flat sales'). Ideal structure 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?
The description covers the tool's grouping logic and target use cases. With an output schema present, return values are documented. Minor gap: the description says 'flat sales' but the property_type default is 'F' (flats), and can be changed to null for all types, which is not highlighted.
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 provides full descriptions for all 6 parameters (100% coverage). The tool description adds no additional parameter meaning beyond the schema, so baseline score 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 tool finds buildings with multiple flat sales for bulk-buy opportunities, using specific verbs like 'group' and 'identify'. It distinguishes from siblings like ppd_transactions (individual transactions) and property_comps (comparables).
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 clear context for use-case (block buying, investor exits), but does not explicitly state when not to use it or compare with alternatives. The sibling tool list provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_compsAInspect
Comparable property sales from Land Registry Price Paid Data.
Returns clean residential standard sales by default. Bulk transfers (transaction_category "B") and commercial units are excluded unless you opt back in. Auto-escalates to wider search area if fewer than 5 results found.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max transactions to return (default 30) | |
| months | No | Lookback period in months (default 24) | |
| address | No | Optional street address to identify subject property and show percentile rank | |
| postcode | Yes | UK postcode (e.g. "SW1A 1AA", "NG11 9HD") | |
| enrich_epc | No | Add floor area, price/sqft, and EPC rating to each comp (default true) | |
| search_level | No | Search area granularity - usually leave as default | sector |
| 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. | |
| property_type | No | Residential filter. None (default) = residential set (F+D+S+T). "F"=flat, "D"=detached, "S"=semi, "T"=terraced, "O"=commercial-only. Pass "ALL" for the raw firehose including commercial. | |
| filter_outliers | No | When True, applies a 1.5×IQR price filter (needs ≥4 prices). Default False — median is naturally robust; opt in for a cleaner mean. | |
| transaction_category | No | "A" (default) = standard residential sales only. Pass None to include category-B (bulk transfers, intra-group conveyances). | A |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: default exclusion of bulk transfers and commercial units, and auto-escalation of search area. Since no annotations are provided, the description carries the full burden and adequately covers the main behavioral traits. It does not mention read-only status but that is implicit. No contradictions.
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 three sentences, front-loaded with the tool's purpose, followed by core behavioral details. Every sentence adds essential information with no redundancy or fluff.
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 complexity (10 parameters, output schema exists), the description covers the most important aspects: default filtering, auto-escalation, and the exclusion of certain transaction categories. It omits mention of the address percentile rank feature, but the schema description for that parameter covers it. Overall sufficient for an agent to understand core behavior.
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 value by explaining the rationale behind defaults (e.g., why bulk transfers are excluded by default) and how auto_escalate interacts with search_level. This narrative ties parameters together beyond the schema's individual 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?
The description clearly states the tool returns comparable property sales from Land Registry Price Paid Data. It specifies that by default it returns clean residential standard sales, excluding bulk transfers and commercial units, and mentions auto-escalation. This distinguishes it from sibling tools like ppd_transactions which likely provide raw transaction 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 indicates when to use the default behavior (residential comps) and when to opt in for bulk/commercial. It explains the auto-escalation feature and provides guidance on setting auto_escalate to false for local results. However, it does not explicitly compare to sibling tools or state when not 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.
property_epcAInspect
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 |
|---|---|---|---|
| address | No | Street address for exact match (omit for area view) | |
| postcode | Yes | UK postcode (e.g. "SW1A 1AA") |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It thoroughly describes what happens in both modes: returning matched certificate details for a property or area-level aggregates. It does not mention error handling, idempotency, or rate limits, but for a read-only lookup tool, the described behavior is sufficient. The output schema (present but not detailed) covers the return structure.
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 concise: two short paragraphs and a bullet-like list. It front-loads the purpose, then immediately presents the two distinct cases. Every sentence adds value, with no redundancy or fluff. The structure is logical and easy to parse.
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 simple input schema (2 parameters) and the presence of an output schema (handling return structure), the description covers the necessary information. It explains the dual-mode behavior, the data fields returned in each case, and when to use each. This is complete for an agent to select and invoke the tool 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?
The input schema already describes both parameters ('postcode' and 'address') adequately (100% coverage). The description adds value by explaining how the 'address' parameter modifies the tool's behavior: exact match when provided, area view when omitted. This goes beyond the schema's description and clarifies usage semantics.
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 provides EPC certificate data for UK properties. It distinguishes two modes: with an address for a single property (returning specific energy details) and without an address for area-level aggregation (returning distribution, range, breakdown). This specificity and differentiation from sibling tools like 'property_report' or 'property_yield' earns a top score.
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 explains when to use each mode: 'Use this for area analysis rather than a single-property lookup' for the without-address case. It implies the with-address mode for exact property lookup. While it doesn't list alternatives or explicit when-not-to-use scenarios, the context is clear enough. A minor gap is not addressing prerequisites beyond the required postcode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_reportAInspect
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" | |
| ppd_months | No | Lookback period for comparable sales (default 24) | |
| property_type | No | Filter comparable sales by type: F=flat, D=detached, S=semi, T=terraced (default all) | |
| search_radius | No | Radius in miles for Rightmove searches (default 0.5) | |
| include_rentals | No | Include Rightmove rental market analysis (default true) | |
| include_sales_market | No | Include Rightmove sales market (default true) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It indicates a read operation ('data pull') but does not explicitly state non-destructive nature, rate limits, or potential costs. The list of returned data partially signals behavior, but lacks explicit safety or performance notes.
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 concise and front-loaded with the core purpose. It lists returned data in a readable format, though slightly verbose; could be tighter with bullet points.
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 (multiple return sections) and presence of an output schema, the description fully covers what the tool returns and its usage constraints, making it complete for an agent.
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 description adds minimal value beyond what the schema already describes. It reinforces the address requirement but doesn't introduce new parameter semantics.
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 it is a 'Full data pull for a UK property in one call' and enumerates the returned data types. It explicitly distinguishes from siblings by noting that for postcode-only queries, property_comps or property_yield should be used instead.
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 instructions: requires a street address + postcode for subject property; postcode-only yields area-level data; directs to specific sibling tools for such queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_yieldBInspect
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 |
|---|---|---|---|
| months | No | Sales lookback period in months (default 24) | |
| radius | No | Rental search radius in miles (default 0.5) | |
| postcode | Yes | UK postcode (e.g. "NG11", "SW1A 1AA") | |
| 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) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must shoulder the burden. It mentions the tool combines data sources but lacks details on side effects, limitations, or output format. Vague wording like 'produce a gross yield figure' could be more precise.
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?
Extremely concise: two sentences front-loading the main purpose. No unnecessary words or repetition.
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?
Output schema exists but description is minimal for a financial calculation tool. No mention of calculation method, data recency, or edge cases. Adequate for a straightforward tool but could be more informative.
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 5 parameters with good descriptions (100% coverage). The tool description adds no additional parameter meaning beyond what the schema already provides, so baseline score 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 calculates rental yield for a UK postcode, using specific data sources. However, it does not explicitly differentiate from sibling tools like rental_analysis, though the combination of sales and rental data is unique.
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 on when to use this tool versus alternatives, no prerequisites or constraints mentioned. The description only states what it does, not when 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.
rental_analysisAInspect
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 |
|---|---|---|---|
| radius | No | Search radius in miles (default 0.5) | |
| postcode | Yes | UK postcode (e.g. "NG1 1AA") | |
| 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) | |
| purchase_price | No | Optional purchase price to calculate gross yield |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: auto-escalation of search radius for thin markets and optional yield calculation. This is useful context beyond the schema, though additional details like data freshness or rate limits are omitted.
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, followed by outputs and notable features. No wasted words; each 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 5 parameters, the description covers core purpose, outputs, and key behavior (auto-escalation). Lacks detail on radius escalation step size or handling of missing data, but overall adequate for tool selection.
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 description complements it by explaining how parameters relate to outputs (e.g., purchase_price for yield). However, it does not add significant new meaning beyond the schema's own 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?
The description clearly states the tool is for rental market analysis in a UK postcode, listing specific outputs (median/average rent, listing count, rent range) and optional yield calculation. It distinguishes itself from sibling tools like property_yield and rightmove_search.
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 context (UK postcode, rent analysis) but does not explicitly guide when to use this vs. alternatives like property_yield for yield-focused queries or rightmove_search for listings. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rightmove_listingAInspect
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. Set include_images=True to also fetch and return image URLs (use rightmove_listing without include_images for basic detail, check image_urls field for photos).
| Name | Required | Description | Default |
|---|---|---|---|
| max_images | No | Max image URLs to include when include_images=True (default 8) | |
| property_id | Yes | Rightmove property URL (e.g. "https://www.rightmove.co.uk/properties/12345678") or numeric ID (e.g. "12345678") | |
| include_images | No | Include image URLs in the response (default False) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool fetches data and lists returned fields, but it does not explicitly state read-only behavior, authentication requirements, or potential rate limits. The behavioral disclosure is adequate but not thorough.
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 front-loaded with the main purpose, then lists return fields concisely, and ends with a usage note. It is efficient but could be shorter by omitting redundant details already in the schema. Still, it is well-structured and easy to parse.
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 presence of an output schema, the description does not need to explain return values. It covers the tool's capabilities (fetching details, optionally images) and mentions default behavior. It is reasonably complete for a data retrieval tool, though missing error handling or fallback behavior.
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 adds context by explaining the effect of include_images and providing an example for property_id, but these add little beyond the schema's own descriptions. The description does not provide additional semantic value for the parameters.
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 it fetches full details for a Rightmove listing by ID or URL, with a specific verb and resource. It distinguishes itself from sibling tools (e.g., rightmove_search searches listings, others provide specific subsets) by focusing on a single listing's comprehensive details.
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 internal guidance on setting include_images for image URLs but offers no guidance on when to use this tool versus sibling tools like property_report or property_epc. It does not specify alternatives or exclusion conditions, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rightmove_searchAInspect
Search Rightmove property listings for sale or rent near a postcode.
Returns prices, addresses, bedrooms, agent details, and listing URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | Search radius in miles (default varies by area) | |
| sort_by | No | Sort order: "newest", "oldest", "price_low", "price_high", "most_reduced" (default: Rightmove default) | |
| postcode | Yes | UK postcode (e.g. "NG1 1AA", "SW1A 2AA") | |
| max_pages | No | Max pages to fetch (default 1, ~25 listings per page) | |
| max_price | No | Maximum price/rent filter in £ | |
| min_price | No | Minimum price/rent filter in £ | |
| max_bedrooms | No | Maximum bedrooms filter | |
| min_bedrooms | No | Minimum bedrooms filter | |
| building_type | No | Filter by building type: F=flat, D=detached, S=semi, T=terraced (default all) | |
| property_type | No | "sale" or "rent" (default "sale") | sale |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose if the tool is read-only, any authentication needs, rate limits, or side effects. Being a search tool implies read-only, but it should be explicit.
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 action and resource, followed by output summary. No unnecessary 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 10 parameters and an output schema, the description is minimal. It does not mention filtering capabilities (building type, price range, etc.) which are defined in the schema. As a search tool, it covers the basics, but could be richer.
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 mentions 'near a postcode' which relates to the postcode parameter, but adds no substantive meaning beyond the schema's existing 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?
The description clearly states the tool searches Rightmove property listings for sale or rent near a postcode. This specific verb and resource scope differentiates it from siblings like rightmove_listing (single listing detail) and property_blocks.
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 clear context that this tool is for searching listings, but lacks explicit when-not-to-use guidance or alternatives. The sibling tool names imply differentiation, but the description does not directly state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stamp_dutyBInspect
Calculate UK Stamp Duty Land Tax (SDLT) for a residential property.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Purchase price in £ | |
| non_resident | No | True if buyer not UK resident (+2% surcharge) | |
| first_time_buyer | No | True for first-time buyer relief (up to £300k nil rate) | |
| additional_property | No | True if buying additional property (+5% surcharge) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations to supplement behavioral details. The description only says 'calculate', implying a read operation, but lacks disclosure of authentication needs, rate limits, or whether it uses current tax rates. Minimal transparency beyond the basic function.
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?
Single sentence, no wasted words. Front-loaded with core purpose. Concise and to the point.
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 presence of an output schema, the description need not detail return values. However, it could mention that it uses current SDLT rates or handles reliefs. Overall adequate for a calculator 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 description coverage is 100% with each parameter having clear descriptions (e.g., price in £, surcharges). The tool description adds no extra parameter information beyond what the schema already provides, so baseline score 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 it calculates UK Stamp Duty Land Tax for residential properties. The verb 'calculate' and specific resource 'SDLT' make the purpose unambiguous and distinguish it from sibling tools like property_comps or rental_analysis.
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 on when to use this tool versus siblings. It does not mention alternaive tools for non-residential property or other tax calculators. The description provides no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!