UK property data MCP server. Wraps Land Registry, Rightmove, EPC, rental yields, stamp duty, and Companies House into 13 tools.
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.
Average 4.1/5 across 13 of 13 tools scored.
Most tools have clear, distinct purposes (company records, planning URLs, transactions, EPC, rentals, listings). The main overlap is between property_yield, rental_analysis, and property_comps, which all touch rental/comparable calculations, but descriptions clarify their focus. property_report aggregates many data points but is distinct as a one-stop pull.
Tool names use lowercase with underscores but mix action-style names (company_search, rightmove_listing) with noun-style names (property_blocks, property_report). Some abbreviations like 'ppd' and 'comps' are inconsistent with longer names. The pattern is readable but not uniform.
13 tools is well-scoped for a comprehensive property intelligence server. Each tool covers a distinct data source or workflow, and the count is not overwhelming.
The surface covers company data, planning portal access, transactions, comparables, EPC, rental analysis, listings, and stamp duty. It lacks planning application data (only URLs) and some niche property checks, but core residential and investment workflows are supported.
company_profileAInspectGet 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'). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return contents (registered address, status, incorporation date, officers, filing history), which gives some behavioral insight. However, it does not explicitly state read-only nature, potential side effects, or any required authentication, leaving a moderate gap.
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 core purpose, and every sentence contributes value—the first states what the tool does, the second specifies return items and gives cross-reference to the sibling tool. 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 one-parameter retrieval tool with an output schema and clear sibling guidance, the description is complete. It covers what the tool returns, how to use it, and how to find the required input, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a clear description of 'company_number' and an example. The description adds extra context by explaining the purpose of the parameter and how to obtain it if missing ('Use company_search to find a company number by name'), which goes beyond the basic schema definition.
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's function: 'Get the full Companies House record for a company by number.' It names the specific resource (Companies House record) and the input method (by number), and distinguishes itself from the sibling company_search by directing users to that tool for finding a company number by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by referencing the alternative: 'Use company_search to find a company number by name.' This tells the agent when to use this tool (when the number is known) and when to use the sibling tool, offering clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_searchAInspectSearch 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") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states the operation (search) and the return type (list of matches), but does not mention potential quirks such as result limits, sorting, or empty results. While this is a low-risk read operation, the lack of annotation context leaves some behavioral ambiguity, earning a middle score.
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 primary purpose and followed by a direct pointer to the sibling tool. There is no wasted wording; 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 one-parameter tool with an output schema and clear sibling differentiation, the description is complete. It covers what the tool does, when to use it, and where to go for the alternative case. No significant gaps exist.
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 already provides full coverage (100%) for the single parameter 'query', including examples. The description adds no new semantic information beyond what the schema provides, so the 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 searches Companies House by company name and returns a list of matches. It explicitly distinguishes itself from company_profile by noting that direct lookup by company number should use that sibling tool, making the purpose unmistakable.
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 gives explicit guidance on when to use this tool (search by name) versus the alternative company_profile for lookup by company number. It names the alternative tool and provides a concrete example, fulfilling the 'alternatives' criterion well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
planning_searchAInspectFind 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") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains the tool's limitation ('scraping is blocked by council portals'), the nature of the output (URL, not data), and implies a safe read-only operation. No side effects or rate limits are mentioned, but for a simple lookup this is adequate.
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, each serving a purpose: main action, return value, explicit exclusion, and usage instruction. Front-loaded and free of padding.
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 purpose, output fields, limitations, and next steps. Even though the output schema exists, the description mentions the key field (search_urls.direct_search) and provides enough context for a 1-parameter tool. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the postcode parameter already described as a UK postcode with examples. The description's first sentence repeats this (UK postcode) but adds no new parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find the planning portal URL for a UK postcode.' It specifies what it returns (council name, planning system type, direct URL) and explicitly distinguishes itself from data-returning tools with 'Does NOT return planning application data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-not guidance ('Does NOT return planning application data') and provides a concrete next step ('Use the returned search_urls.direct_search link to browse applications manually'). It doesn't name alternative tools, but the context is sufficient for a single-purpose lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ppd_transactionsAInspectSearch 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It only says 'Search,' which implies a read-only operation, but it does not explain result ordering, pagination, how the limit parameter interacts with results, or any constraints on combining filters. This is a significant gap for a tool with no annotation safety profile.
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 short sentences with illustrative examples. It front-loads the core function and then adds practical usage context. Every sentence earns its place with no redundancy or filler.
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 and 100% schema description coverage, the description is largely complete for tool selection and invocation. It adds usage examples and filter-grouping context. It could mention that at least one search criterion is needed, but this is not a critical omission given the schema's optional-parameter default of null.
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 documents all 10 parameters (100% coverage), so baseline is 3. The description adds value by grouping these parameters into search modes: postcode, address, date range, and price. This helps the agent understand which parameters to use together, which the schema descriptions do not convey as directly.
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's purpose: 'Search Land Registry transactions by postcode, address, date range, or price.' The verb 'search' plus the resource 'Land Registry transactions' is specific, and the examples further clarify the scope, distinguishing it from sibling tools like rightmove_search and property_* tools which target other data sources or 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 provides explicit use cases: 'Use for specific property history... or filtered market queries...' This gives clear context on when to employ the tool. However, it does not mention alternatives or when not to use it, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_blocksAInspectFind 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) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the key behavioral trait of grouping transactions by building and identifying patterns like blocks being sold off. While it doesn't state permissions or limitations, the read-only nature is implicit, and the description adds meaningful context beyond the schema.
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 primary purpose ('Find buildings with multiple flat sales') and followed by a concise explanation. Every word earns its place, 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?
The tool has 6 parameters, an output schema, and no annotations. The description covers the core purpose and grouping behavior, which is sufficient for an agent to select and invoke it. The output schema likely handles return value details, so the description doesn't need to explain those. Minor gap: no explicit alternative references, but overall adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'flat sales' which aligns with the default property_type='F', but it doesn't add significant parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Find buildings with multiple flat sales' and elaborates by saying it 'Groups Land Registry transactions by building to identify blocks being sold off, investor exits, and bulk-buy opportunities.' This specific verb+resource combination distinguishes it from siblings like ppd_transactions (raw transaction lookup) and property_comps (comparison 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 suggestion of 'block buying opportunities' implies a use case, but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions. The relationship to siblings is not mentioned, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_compsAInspectComparable 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively reveals non-obvious behaviors: default filtering to residential standard sales, exclusion of bulk transfers and commercial units unless opted in, and auto-escalation when fewer than 5 results are found. These details substantially help an agent understand side effects and defaults, though it does not cover all aspects like error behavior or output format.
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 exceptionally concise and front-loaded: the opening sentence states the purpose, and the next two sentences summarize key behaviors. Every word earns its place, with no redundant 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?
Given the high schema coverage and presence of an output schema, the description doesn't need to explain every parameter or return field. It captures the essential context—data source, default filters, and escalation behavior—which is sufficient for an agent to select and invoke the tool correctly. It falls short only in not mentioning edge behaviors like address-based percentile ranking, but those are well-documented in the schema.
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% parameter description coverage, so per the rubric the baseline is 3. The tool description adds minimal extra semantic value—it repeats the transaction_category and auto_escalate defaults already captured in the schema. It does not provide new meaning beyond what structured fields already offer.
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, immediately conveying its core function. It distinguishes itself from sibling tools like ppd_transactions by focusing on 'comparable' sales rather than raw transaction data, though it does not 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 some implied usage context—it's for property comps, and it mentions default behavior like excluding bulk transfers and auto-escalation. However, it lacks explicit 'when to use vs. alternatives' guidance or exclusions, so an agent must infer when to prefer this over ppd_transactions or property_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_epcAInspectEPC 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") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains what happens in both modes: returns a matched certificate with specific fields when an address is given, and returns all certificates with aggregated statistics when no address is given. It does not mention edge cases like invalid postcodes or no match, but for a read-only data retrieval tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by two clear bullet-like paragraphs for each mode. Every sentence serves a purpose, with no redundancy or filler. The front-loaded main clause immediately states what the tool does, making it easy for an agent to parse quickly.
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 moderate complexity (two modes, two parameters) and the presence of an output schema, the description is sufficiently complete. It explains the return values for both modes, covers the parameter interactions, and provides usage guidance. There are no significant gaps that would prevent an agent from correctly invoking the 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?
The input schema already includes full descriptions for both postcode and address, so baseline is 3. However, the description adds meaningful context beyond the schema by explaining how the address parameter conditionally changes the tool's behavior (exact match vs area aggregation) and how the postcode is used in both modes. This elevates the parameter semantics beyond mere field definitions.
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 a UK property or postcode area, and distinguishes two distinct modes (with/without address) with specific return details. The verb 'returns' and resource 'EPC certificate data' make the purpose specific and distinct from sibling tools like property_report or planning_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 gives clear context on when to use each mode: with address for single-property exact match, without address for area-level aggregation and analysis. It explicitly states 'Use this for area analysis rather than a single-property lookup,' which provides directional guidance, though it does not name alternative sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_reportAInspectFull 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) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the fallback behavior for postcode-only inputs (returns area-level data without a subject property), the requirement for address+postcode, and the scope of returned data. However, it does not mention potential limitations like data source freshness, cost, or whether the call can be slow or rate-limited.
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 core purpose, followed by a concise list of return data and then usage requirements/alternatives. Every sentence earns its place, with no filler or 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?
Given the tool's complexity (six parameters, multiple data sources, output schema present), the description is complete: it names the required input, the return components, the fallback behavior, and the relevant sibling tools. The presence of an output schema means return-value details need not be duplicated, and the description already covers them at a high level.
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 explains all six parameters. The description adds meaningful semantic nuance for the address parameter by distinguishing between a full street address with postcode versus postcode-only, and clarifies the behavioral consequence of that distinction. This goes beyond simple restatement of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific purpose: 'Full data pull for a UK property in one call,' and enumerates the exact data returned (sale history, area comps, EPC, rental market, etc.). It distinguishes itself from siblings by emphasizing the 'one call' scope and explicitly naming property_comps/property_yield as alternatives for postcode-only queries.
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 gives explicit when-to-use guidance ('Full data pull for a UK property') and provides an exclusion: 'Postcode-only ... use property_comps or property_yield for postcode-only queries.' It also clearly states the required input format ('street address + postcode'), which is essential for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
property_yieldAInspectCalculate 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) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior—combining Land Registry sales and Rightmove rentals to produce a gross yield figure—but does not mention potential limitations (e.g., data availability, boundary cases, update frequency). It doesn't contradict any annotations (none exist) but also doesn't go beyond the basic method.
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: the first states the core purpose, the second adds the data sources and output. It is front-loaded, concise, and every word contributes value. No fluff 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?
Given the tool's moderate complexity (5 params, output schema present, no annotations), the description is adequate. It explains the calculation method and output, while parameter details are covered by the schema. It could mention data coverage or error scenarios, but the core purpose is well captured.
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 5 parameters with descriptions and defaults. The description adds no additional parameter-specific meaning beyond the schema, so a 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's purpose: 'Calculate rental yield for a UK postcode.' It specifies the verb (calculate), the resource (rental yield), the scope (UK postcode), and the method (combines Land Registry sales data with Rightmove rental listings). This clearly distinguishes it from siblings like rental_analysis (which likely provides broader rental analysis) and ppd_transactions (which is raw sales data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case—calculating gross yield using two specific data sources—but does not explicitly state when to choose this tool over siblings such as rental_analysis or rightmove_search. It lacks exclusions or alternative recommendations, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_analysisAInspectRental 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden for behavioral transparency. It discloses the auto-escalation of search radius for thin markets, a valuable behavioral trait. However, it omits other context such as data sources, failure modes, or potential variability in listings, leaving room for improvement.
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 purpose. The first sentence defines the tool, the second lists return values, and the third explains a key behavior. Every sentence is informative, with no 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?
With an output schema present, the description needn't detail return structures. It covers the core purpose, optional yield calculation, and auto-escalation behavior. For a moderate 5-parameter tool, this is largely complete, though it misses data source or recency context that would round it out.
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 minimal semantic value beyond the schema, merely restating purchase_price for gross yield and auto_escalate for thin markets, which the schema already covers in more detail.
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 starts with a specific verb+resource: 'Rental market analysis for a UK postcode'. It clearly defines the output (median/average rent, listing count, rent range) and distinguishes itself from sibling tools like property_yield by focusing on rental metrics.
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 gives clear context: use this tool for rental market analysis in a UK postcode. It does not explicitly name alternative tools, but the domain is obvious. No exclusions are stated, which aligns with a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rightmove_listingAInspectFetch 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) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It transparently lists the data fields returned and explains the include_images toggle. However, it does not mention error behavior (e.g., invalid ID, missing data), rate limits, or that the operation is read-only, leaving some behavioral uncertainty.
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, opening with a clear purpose statement. The first sentence is a long enumeration of return fields, but it is structured and information-dense; the second sentence concisely handles the optional parameter behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential return fields and optional behaviors. It lacks only minor details like error handling and explicit rate-limit notes, which are less critical for a single-item fetch 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 well-documented. The description adds value by linking include_images to the output field image_urls and reinforcing the default behavior without parameters, providing practical usage context beyond the schema's basic 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 uses the specific verb 'Fetch' with the resource 'Rightmove listing' and identifies the input as ID or URL. It explicitly enumerates the returned fields, distinguishing it from search tools like rightmove_search which find listings rather than fetch details for a known 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 guidance on when to use include_images (True for full details with photos, False for basic details). However, it does not explicitly compare against sibling tools like rightmove_search or property_report, so the agent lacks explicit instruction on selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rightmove_searchAInspectSearch 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden. It discloses the return fields (prices, addresses, bedrooms, agent details, listing URLs), which adds some behavioral context, but it does not mention rate limits, authentication, pagination behavior, or any other operational nuances.
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 tool's purpose followed by a concise summary of return data. Every sentence earns its place with no waste.
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 10-parameter tool with an output schema, the description adequately conveys the core purpose and return types. It would benefit from a brief note on how it differs from rightmove_listing, but overall it is sufficient for the agent to understand the tool's scope.
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 no additional parameter meaning beyond the schema; it only restates the postcode requirement and the sale/rent option, which the schema already covers.
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 'Search Rightmove property listings for sale or rent near a postcode' – a specific verb, resource, and scope. It also lists return fields, clearly distinguishing it from sibling tools like 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 gives clear context that this tool is for searching property listings by postcode, but it does not explicitly mention when to use it over alternatives or any exclusions. No differentiation from rightmove_listing is provided, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stamp_dutyAInspectCalculate 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) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. The verb 'calculate' implies a side-effect-free pure computation, but it does not disclose facts like whether rates are current, whether it provides a breakdown, or any caveats. This is minimal but arguably sufficient for a simple calculator.
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, front-loaded sentence with no filler. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculator with a well-documented schema and an output schema present, the description is adequate. It could mention rate jurisdiction or that it's for residential only, but that's in the description. The schema fills in parameter details, and the output schema presumably describes returns. A 4 is appropriate.
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 100% of parameters with descriptions, so baseline is 3. The tool description adds no additional parameter semantics beyond the schema, which already explains price, non_resident, first_time_buyer, and additional_property effects.
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 calculates UK Stamp Duty Land Tax for residential property, using a specific verb ('calculate') and resource ('SDLT'). This distinguishes it from sibling tools, which are all property search/analysis tools with no tax component.
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 residential property SDLT calculations but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives, though no siblings overlap in function. The context is clear but not fully explicit.
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.
No comments yet. Be the first to start the discussion!
