UK Property Data
Server Details
UK property data — Land Registry comps, EPC, Rightmove, rental yields, stamp duty, Companies House
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- paulieb89/property-shared
- GitHub Stars
- 10
- Server Listing
- UK Property Data
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 3.7/5 across 13 of 13 tools scored. Lowest: 2.7/5.
Each tool targets a distinct aspect of UK property data with clear separation of concerns. Tools like property_epc, property_epc_search, and epc_certificate are carefully differentiated by usage pattern (aggregate vs browse vs direct lookup), preventing ambiguity.
Tool names use snake_case with descriptive prefixes like 'property_' for many, but there are exceptions (e.g., 'ppd_transactions', 'rental_analysis', 'stamp_duty'). The pattern is mostly consistent and readable, with minor deviations that do not cause confusion.
13 tools is an ideal size for the domain. Each tool covers a specific data source or analysis, and none are redundant. The scope is well-balanced without being overwhelming or too sparse.
The tool set covers major UK property data needs: EPC, sales transactions, rental market, stamp duty, planning, and company search. Minor gaps like missing land registry title data are acceptable for a read-only data service, and the workflow guidance for EPC cross-referencing shows thoughtful coverage.
Available Tools
13 toolscompany_searchBRead-onlyInspect
Search Companies House for a company by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
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 annotation 'readOnlyHint: true' already indicates non-destructive behavior. The description adds no further behavioral context such as pagination, rate limits, or search specificity, but neither does it contradict the annotation.
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, concise sentence with no unnecessary words. It is front-loaded with the key action and resource.
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 tool is simple with one parameter and an output schema exists, so the description is minimally adequate. However, it lacks any search behavior hints that would help an agent use the tool effectively.
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 schema has 0% description coverage, and the description does not add any meaning beyond the parameter name 'name'. There is no detail on case sensitivity, exact match, or search algorithm, leaving the agent without guidance.
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 'Search' and the resource 'Companies House' with the object 'a company by name'. It is specific and distinguishes the tool from sibling tools like planning_search or property tools.
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 or when not to use it. The description does not mention any conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
epc_certificateARead-onlyInspect
Fetch a single EPC certificate by its lmk_key (certificate hash).
Use after property_epc_search has identified the correct cert — this is faster than property_epc(postcode, address) as it makes a direct lookup with no fuzzy matching or postcode re-fetch.
lmk_key is returned in every property_epc_search result.
Returns the full EPC certificate or None if not found.
| Name | Required | Description | Default |
|---|---|---|---|
| lmk_key | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it returns the full EPC certificate or None, and mentions performance characteristics (direct lookup, no fuzzy matching). No contradiction.
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 concise sentences, front-loaded with purpose, then usage, then parameter source, then return type. No redundancy.
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 1-param tool with output schema (present but not shown), the description covers purpose, usage, parameter sourcing, and return behavior. Fully complete given the context.
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?
Only parameter lmk_key is documented via schema; description adds context: 'lmk_key is returned in every property_epc_search result', aiding agent in sourcing the value. Does not detail format, but sufficient for a single string parameter.
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 'Fetch a single EPC certificate by its lmk_key', providing a specific verb (Fetch) and resource (EPC certificate). It distinguishes from sibling tools like property_epc by noting it is faster and a direct 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?
Clear guidance: 'Use after property_epc_search has identified the correct cert — this is faster than property_epc(postcode, address)'. It explains when to use and compares to an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
planning_searchARead-onlyInspect
Find the council planning portal URL for a postcode.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes |
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 adds context (output is a URL) beyond the readOnlyHint annotation, but lacks details on dependencies, rate limits, or error behavior. No contradiction 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?
The description is a single, efficient sentence with no redundant information, making it very concise.
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 required parameter and an output schema, the description provides enough context to understand the tool's basic function, though it could mention the output type explicitly.
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?
With 0% schema description coverage, the description only minimally adds meaning by linking the parameter to the tool's purpose, but fails to specify format, validation, or examples for the postcode.
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 a specific verb ('Find') and resource ('council planning portal URL') with a defined scope ('for a postcode'). It distinctively separates from sibling tools that focus on different property aspects.
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 retrieving a planning portal URL by postcode but provides no explicit guidance on when to use it vs alternatives or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ppd_transactionsCRead-onlyInspect
Raw Land Registry Price Paid transactions for a postcode.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| postcode | Yes | ||
| property_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds 'Raw Land Registry' which is helpful but does not disclose other behavioral traits like rate limits, pagination, 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 concise sentence with no fluff. It is appropriately sized but could be slightly more structured without adding length.
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 output schema exists, the description need not detail return values, but it lacks context about the tool's scope (e.g., how many transactions, date range). For a tool with 3 parameters and many siblings, this is inadequate.
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 0%, and the description provides no additional meaning for the parameters (postcode, limit, property_type). The schema has basic info (types, defaults) but the description does not clarify their 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 returns Raw Land Registry Price Paid transactions for a postcode. It's specific about the resource (transactions) and source (Land Registry), but does not differentiate from sibling tools like property_comps or 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?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_blocksCRead-onlyInspect
Property block analysis — identify buildings with multiple flat sales (block-buy opportunities).
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | ||
| postcode | Yes | ||
| search_level | No | sector |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description only needs to add context. The description uses 'analysis' which aligns with read-only behavior. However, it does not disclose additional behavioral traits like data freshness, pagination, 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, concise sentence with no wasted words. It is front-loaded with the tool's purpose. However, it could benefit from a brief parameter summary.
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?
Although an output schema exists (not shown), the description lacks details on parameter usage and return value format. For a tool with siblings and 3 parameters, the description is too minimal to be 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?
The schema has 0% description coverage, meaning parameters are undocumented. The description does not explain the meaning of 'postcode', 'months', or 'search_level'. This is insufficient for a tool with three 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 the tool identifies buildings with multiple flat sales for block-buy opportunities. It uses a specific verb ('identify') and resource ('buildings'). However, it does not explicitly differentiate from sibling tools like 'ppd_transactions' or 'property_comps'.
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. The description implies a use case (block-buy analysis) but does not mention prerequisites, exclusions, 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.
property_compsARead-onlyInspect
Comparable sales from Land Registry Price Paid Data.
Defaults return the standard residential set:
property_type=None means residential (F+D+S+T). Pass "F"/"D"/"S"/"T"/"O" for a single type, or "ALL" to disable type filtering (firehose).
transaction_category defaults to "A" (standard sales). Pass None to include category-B (bulk transfers, non-standard conveyances).
filter_outliers=False by default; set True for IQR-trimmed stats AND transaction list (1.5*IQR rule, needs >=4 prices).
limit caps returned transactions (max 200). enrich_epc attaches EPC floor area and price-per-sqft to each transaction — slower but richer.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| months | No | ||
| address | No | ||
| postcode | Yes | ||
| enrich_epc | No | ||
| search_level | No | sector | |
| property_type | No | ||
| filter_outliers | No | ||
| transaction_category | No | 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?
Annotations indicate readOnlyHint=true, and the description adds meaningful behavioral details: it describes default result sets, the effect of parameters like filter_outliers (IQR trimming), the limit cap at 200, and that enrich_epc is slower. This goes beyond what annotations alone provide.
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 well-structured with bullet points and defaults clearly called out. It is moderately concise but could be tightened by removing redundant notes (e.g., 'Defaults return the standard residential set' is clear from the bullet). Still effective.
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 9 parameters and an output schema, the description covers key behavioral aspects and return expectations, but omits explanations for months, address, and search_level. The presence of an output schema partially mitigates the need for return value details, but completeness is moderate.
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?
With 0% schema description coverage, the description must compensate. It explains property_type, transaction_category, filter_outliers, limit, and enrich_epc (5 out of 9 parameters). Missing explanations for months, address, postcode, and search_level, though postcode is required and self-explanatory. Partial compensation.
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 states it returns 'Comparable sales from Land Registry Price Paid Data,' which is clear about the output. However, it lacks an explicit verb like 'Get' or 'Retrieve', and does not differentiate it from sibling tools such as ppd_transactions which might also deal with Land Registry 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 explains default behaviors and parameter options (e.g., property_type, transaction_category, filter_outliers), aiding the agent in customization. However, it does not explicitly state when to use this tool versus alternatives like ppd_transactions or planning_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_epcARead-onlyInspect
Energy Performance Certificate data for a UK property or postcode area.
With address: returns the matched EPC certificate for that specific property. Without address: returns an aggregated summary of every certificate at the postcode — count, rating distribution, property-type breakdown, floor-area range — plus a hint to call again with an address for single-property detail.
Returns None if no certificates exist for the postcode at all.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | ||
| postcode | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: aggregated summary without address, specific certificate with address, and None return for no certificates. It aligns with readOnlyHint=true annotation and provides complete behavioral context beyond 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?
Four sentences efficiently cover purpose, two usage modes, and an edge case. No redundant information, and the structure is logical: intro, mode explanations, default case.
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 output schema exists, the description does not need to detail return values. It covers all relevant behaviors for the two parameters, edge cases, and provides complete guidance for an AI agent to 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?
With 0% schema description coverage, the description adds critical meaning to parameters: it explains how 'postcode' and 'address' interact to change the returned data (aggregated vs specific). This fully compensates for the schema's lack of 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 it provides EPC data for a UK property or postcode area, and distinguishes two modes: with address returns specific certificate, without returns aggregated summary. This is specific and differentiates from sibling tools like property_epc_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 explains when to use with address vs without, and what happens when no certificates exist. However, it does not explicitly compare to sibling tools or state when not to use, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_epc_searchARead-onlyInspect
Browse all EPC certificates at a postcode — use when you have no house number.
Returns a slim list of every certificate at the postcode. Each entry contains: address, rating, score, floor_area (sqm), property_type, floor_level, habitable_rooms, inspection_date, lmk_key.
Workflow for Rightmove listings where the house number is not shown:
Call rightmove_listing to obtain floor_area_sqm, property_type, and any floor-level signals in the description (e.g. "top floor", "ground floor").
Call property_epc_search(postcode) to retrieve the full cert list.
You MUST cross-reference each cert's floor_area against the listing's floor_area_sqm (accept within ±5 sqm) AND property_type must match. Also use floor_level and habitable_rooms where available.
If a single cert matches, call epc_certificate(lmk_key) for the full detail.
If multiple certs match equally, present all candidates — do not guess. If floor_area is unavailable on the listing, filter by property_type only and return all candidates.
Returns None if no certificates exist for the postcode.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent. The description adds value by explaining the output structure (slim list with specific fields) and behavior (returns None if no certificates). 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 lengthy and includes a detailed workflow, which is helpful but could be more concise. It is structured with numbered steps, aiding readability, but some redundancy exists (e.g., repeating the cross-referencing criteria).
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 role in a multi-step workflow and the presence of an output schema, the description provides complete guidance on return fields and usage context. It covers when to use, what to do with results, and error cases.
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?
Only one parameter (postcode) with 0% schema coverage. The description does not add format or constraints (e.g., UK postcode format, case sensitivity). The meaning is somewhat inferred from the tool name, but the description should explicitly clarify usage.
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 'Browse all EPC certificates at a postcode' and specifies the use case ('when you have no house number'). It also distinguishes from sibling tool epc_certificate by implying that epc_certificate retrieves a single certificate.
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 a detailed step-by-step workflow for when and how to use this tool in conjunction with rightmove_listing. It explicitly states when to use it (when no house number), how to cross-reference results, and when to return None.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_yieldARead-onlyInspect
Gross rental yield for a UK postcode.
Combines Land Registry sale comps (median sale price) with Rightmove rental listings (median monthly rent) to produce a gross yield percentage.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | PPD sale lookback period (default 24). | |
| postcode | Yes | UK postcode (e.g. "NG1 2NS"). | |
| search_level | No | PPD search granularity — "postcode", "sector" (default), or "district". | sector |
| auto_escalate | No | Widen the PPD search area on thin markets — postcode→ sector→district. Default True. Set False for strict-locality only. | |
| property_type | No | Filter sales by type. None (default) = residential set (F+D+S+T). Pass "F"/"D"/"S"/"T"/"O" for one type, "ALL" for firehose. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with a data computation tool. The description adds behavioral context by noting the combination of two data sources (Land Registry and Rightmove) and the median aggregation, which is helpful beyond 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?
The description is two sentences, front-loaded with the main purpose. It is efficient but could be slightly improved by adding a brief usage hint. Still, it earns its place 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?
Given the output schema exists, the description is complete enough. It explains what the tool yields and the data sources. The mention of handling thin markets via auto_escalate is implied in the schema but not in the description; minor gap.
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 the schema already documents all parameters. The description does not add new semantics beyond naming the data sources. Baseline 3 is appropriate as the description does not compensate for any schema gaps.
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 computes gross rental yield for a UK postcode using Land Registry and Rightmove data. The verb 'yield' and resource 'postcode' are specific, and it distinguishes from siblings like ppd_transactions and 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?
The description explains the tool's function but does not explicitly state when to use it versus sibling tools. However, given the unique yield computation, the usage context is reasonably clear without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_analysisBRead-onlyInspect
Rental market analysis and achievable rent estimate.
auto_escalate widens the search area when fewer than 5 listings are found (thin market). Response includes thin_market, escalated_from, escalated_to fields when escalation occurs.
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | ||
| postcode | Yes | ||
| auto_escalate | No | ||
| purchase_price | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable context about the auto_escalate mechanism (widens search when fewer than 5 listings) and response fields (thin_market, escalated_from, escalated_to). 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?
The description is two concise sentences with no fluff. It front-loads the purpose and then provides key behavioral detail. However, it could be more structured by listing parameters explicitly.
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 4 parameters and an output schema, the description lacks context on prerequisites, data sources, or use cases compared to sibling tools. The output schema exists but the description doesn't hint at its structure for normal cases.
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 0%. The description only explains the auto_escalate parameter's behavior. Other parameters (radius, postcode, purchase_price) are not described, though postcode is implicitly clear. Radius default and purchase_price purpose are left unspecified.
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 performs 'Rental market analysis and achievable rent estimate,' which is a specific verb+resource combination. It distinguishes from sibling tools like property_yield and property_comps by focusing on rent estimation, though it doesn't explicitly name alternatives.
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 versus alternatives such as property_yield or property_comps. It only describes internal behavior (auto_escalate) but not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rightmove_listingARead-onlyInspect
Full detail for a single Rightmove listing (URL or numeric ID).
include_images fetches and embeds photos and floorplans as MCP image content. max_images caps the number of property photos (default 3); floorplans always included.
| Name | Required | Description | Default |
|---|---|---|---|
| max_images | No | ||
| include_images | No | ||
| property_url_or_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals that include_images embeds photos as MCP image content and max_images caps property photos. This adds valuable behavioral context about image 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?
Three focused sentences: first states core purpose, second details optional image features. No wasted words, front-loaded with essential information.
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?
Covers all parameters and image behavior. While it doesn't detail the full return structure (e.g., price, description), the tool name implies comprehensive detail, and no output schema shifts the burden. Minor gap for a complete picture.
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?
With 0% schema description coverage, the description fully compensates by explaining the purpose and behavior of each parameter: property_url_or_id (required), include_images (fetches images), max_images (caps photos, default 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 it retrieves full details for a single Rightmove listing, accepts URL or numeric ID, and optionally includes images. This distinguishes it from sibling tools like 'rightmove_search' which handles multiple listings.
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 implicitly indicates usage for single listing details, but does not explicitly provide when-to-use or when-not-to-use guidance relative to siblings. It is clear enough, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rightmove_searchARead-onlyInspect
Fetch Rightmove listings for a postcode.
listing_type: "sale" or "rent". sort_by: "newest", "most_reduced", "price_asc", "price_desc". keywords filters by description text (e.g. "church conversion", "barn", "factory"). Images are excluded from results.
| Name | Required | Description | Default |
|---|---|---|---|
| radius | No | ||
| sort_by | No | ||
| keywords | No | ||
| postcode | Yes | ||
| max_pages | No | ||
| max_price | No | ||
| listing_type | No | sale | |
| min_bedrooms | No | ||
| property_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that images are excluded from results, which is a useful behavioral trait. However, it does not mention pagination behavior (despite max_pages parameter) or other potential side effects, so transparency 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 concise at 4 sentences, with no fluff. It lists some parameter values in a semi-structured format. However, it could be more organized by listing all parameters or using bullet points. Still, it is efficient and 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?
Given the tool has 9 parameters, 0% schema coverage, and an output schema (which reduces the need to explain return values), the description covers only a subset of parameters and does not explain pagination or default behaviors. It provides basic context but leaves gaps in completeness.
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?
With 0% schema description coverage, the description must compensate. It explains listing_type, sort_by, and keywords, but fails to describe radius, max_pages, max_price, min_bedrooms, and property_type. This leaves 6 out of 9 parameters undocumented, providing insufficient semantic guidance for the agent.
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 states 'Fetch Rightmove listings for a postcode', which is a specific verb+resource. It clearly differentiates from sibling tools like 'rightmove_listing' (likely for a single listing) and other search tools. The mention of image exclusion adds specificity.
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 the tool is for searching listings by postcode, but does not explicitly state when to use it versus alternatives (e.g., 'rightmove_listing' for individual listing details). No exclusions or direct comparisons are provided, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stamp_dutyBRead-onlyInspect
UK Stamp Duty Land Tax (SDLT) calculation with full breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | ||
| non_resident | No | ||
| first_time_buyer | No | ||
| additional_property | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'calculation' which aligns with readOnlyHint annotation, confirming it's a read operation. However, it does not disclose any limitations, assumptions, or what 'full breakdown' entails beyond the basic purpose.
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 main action. Could be slightly more informative without losing conciseness.
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 complexity of UK SDLT calculation and presence of an output schema, the description is minimal but adequate. It does not mention rate bands, thresholds, or other key details that might help an agent understand tool boundaries.
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 has 0% description coverage for parameters. Description does not explain the boolean flags (non_resident, first_time_buyer, additional_property) or the price parameter, relying entirely on parameter names which are self-explanatory but benefit from explicit documentation.
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 calculates UK Stamp Duty Land Tax with a full breakdown. It uses specific verb 'calculation' and resource 'SDLT', distinguishing it from sibling tools which are searches or property 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?
No guidance on when to use this tool versus alternatives. Sibling tools are listed but no comparison or conditions are provided, leaving the agent to infer usage context.
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!
Your Connectors
Sign in to create a connector for this server.