UK Property Data

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation readOnlyHint=true already conveys that this is a safe read operation. The description adds no additional behavioral context (e.g., return format, matching behavior, rate limits) but also does not contradict the annotation. Given the low bar with annotations present, a neutral score is appropriate.

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 sentence, front-loading the essential action and resource. It contains no filler or redundant information, making it highly concise and well-structured.

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 (one parameter) and has an output schema and a read-only annotation, so the description's minimalism is acceptable. It covers the basic purpose (search by name) and is complete for a simple lookup use case. However, it could have added a note on matching behavior or result limits, which prevents a perfect score.

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 only one parameter 'name' with 0% description coverage. The description, by saying 'by name,' clarifies that the parameter refers to the company name, which adds some semantic meaning beyond the schema. However, it doesn't specify expected format, partial/full match, or any constraints, so it only partially compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Search Companies House for a company by name.' It uses a specific verb ('Search'), a specific resource ('Companies House'), and a specific scope ('by name'), which distinguishes it from the sibling tools related to property, planning, and transactions.

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. It doesn't mention any exclusions or alternative tools, and the sibling tools have clearly distinct domains, so an agent must infer usage from the name alone. This lacks the explicit when/when-not guidance that a higher score would require.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, but the description adds critical behavior: returns null only when no certificate is lodged, and raises an error if the service is unreachable, explicitly warning not to treat errors as absence of a certificate. This is beyond the annotation and essential for correct interpretation.

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 focused and efficiently organized: purpose first, then usage context, then parameter explanation, then behavior. Every sentence adds value without redundancy or fluff, making it easy 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 has a single straightforward parameter and an output schema (which the description complements by explaining null vs error), the description fully covers what an agent needs to know to call it correctly and interpret results. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description fully explains the parameter: lmk_key is a compatibility alias for the certificate number, and it tells the agent that the value is available in every property_epc_summaries row. This compensates entirely for the schema's lack of description.

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 ('Fetch') and resource ('a single EPC certificate by its GOV.UK certificate number'). It also distinguishes itself from siblings like property_epc by explicitly noting the lookup avoids address matching and postcode re-fetch, making its niche obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: use after property_epc_summaries, faster than property_epc(postcode, address), and warns that property_epc_search is deprecated and raises. This gives an agent clear when-to-use and when-not-to-use instructions with alternatives named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already signals a safe read operation. The description adds the output type (URL) and the input context (postcode), but does not disclose additional behavioral details such as possible variations in output or service dependencies. This is adequate for a simple lookup tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. Every word contributes meaning, making it exemplary in 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?

For a simple one-parameter tool with an output schema present, the description covers the core functionality. It lacks explicit usage context or edge cases, but given the low complexity and the supporting annotations, it is mostly 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 0% for the postcode parameter. The description says 'for a postcode', which merely restates the parameter name and confirms its role as the lookup key. It does not add format or validity details, so it only partially compensates for the missing schema description.

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 'Find' and identifies the resource as 'council planning portal URL', scoped to a postcode. This clearly distinguishes it from sibling tools like property_epc or company_search, which target different data. It is a precise and complete statement of the tool's function.

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 should be used when a planning portal URL is needed for a postcode, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Since no sibling tool covers planning, this is a minor gap, but the guidance is still only 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses key behaviors: results are limited to snapshot coverage, bulk and commercial sales are included by default, provenance fields like older_records_exist and sample_complete must be checked, and empty results are coverage-limited. This rich context helps the agent avoid drawing incorrect conclusions about property history.

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 front-loads the core purpose and then adds only high-value operational details: coverage, unfiltered behavior, filtering options, and caveats. Each sentence contributes essential information, and the formatting with bold caveats makes the critical warnings stand out.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a read-only query tool: it explains ordering, coverage limits, default filtering behavior, how to restrict by property type, how to interpret empty results, and which alternative to use. Since an output schema exists, detailed return-value documentation is not needed, and the prose still references the key provenance fields.

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 carries the full burden for parameters. It defines property_type with all accepted letter values and explains that limit controls 'up to `limit` most recent transactions'. Postcode is understood from the tool's purpose, and requiredness is already in 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 opening sentence states a specific verb and resource: 'Land Registry Price Paid transactions for a postcode, most recent first.' It also differentiates itself from sibling tools by defining its scope and by explicitly naming property_comps as the alternative for clean comparable sales. This leaves no ambiguity about what the tool does.

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 states when to use the tool and when not to: it is unfiltered by default, property_type can restrict results, and 'For clean residential comparable sales, use property_comps.' It also warns not to interpret an empty result as 'never sold', providing concrete decision guidance for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

readOnlyHint=true already covers the read-only nature, so the description doesn't need to restate that. The description adds a bit of behavioral context by indicating the tool identifies buildings with multiple flat sales, but it doesn't disclose important operational traits like data coverage, required postcode format, or the meaning of 'block-buy opportunities' in the output.

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, well-structured sentence that front-loads the tool's domain ('Property block analysis') and then clearly states the objective. Every word earns its place; there is no filler 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?

With three parameters and an ambiguous search_level, the description leaves out essential input semantics and any usage context. Although an output schema exists, the agent still needs to understand what a block-buy opportunity looks like and how the parameters shape the analysis, none of which is explained.

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 only 33%, so all three parameters are not adequately documented in the schema. The description provides no additional meaning for 'postcode,' 'months,' or especially 'search_level' (a non-obvious parameter with default 'sector'). This fails to compensate for the low schema coverage.

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 names a specific verb ('identify') and a specific resource ('buildings with multiple flat sales'), and frames the purpose as 'block-buy opportunities.' This clearly separates it from sibling tools like property_comps or property_yield, which focus on valuation and yield rather than block-buy identification.

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 when to use the tool — when the user needs to spot buildings with multiple flat sales for block buying. However, it gives no explicit exclusions or guidance about when to prefer an alternative tool, so the agent must infer the appropriate context from the purpose alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, so the description carries the behavioral burden and does so thoroughly. It discloses default property filtering, category handling, IQR outlier trimming with a minimum-price requirement, a max limit of 200, and the performance tradeoff of enrich_epc.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then uses a tightly scoped bullet list for parameter defaults. Every sentence carries meaningful configuration detail without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 9 parameters and very low schema coverage, the description covers most critical behavior and even notes performance implications. It is not fully complete because address and search_level are left undefined, and no explicit guidance is given for choosing this instead of the related ppd_transactions 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 only 11%, and the description compensates for most key parameters: property_type values, transaction_category defaults, filter_outliers behavior, limit cap, and enrich_epc meaning. However, address and search_level remain semantically unexplained in both schema and description, leaving a gap.

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 sales from Land Registry Price Paid Data, which is a specific resource and function. It lacks an explicit contrast with sibling tools like ppd_transactions, but the 'comparable sales' framing and residential defaults make the core purpose unambiguous.

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 operational context by explaining defaults for property_type, transaction_category, filter_outliers, limit, and enrich_epc. It does not explicitly say when to prefer this tool over a sibling, but the usage behavior is concrete and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds substantial behavioral guidance: the distinction between null (no certificate) and error (service unreachable), the warning never to treat an error as evidence of no certificate, and the note that property-type/floor-area stats are not exposable via this endpoint. This goes well beyond 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 well-structured with front-loaded purpose and method, then behavior nuances. It is somewhat long but every sentence adds value, and the blank line separates major ideas. It is appropriately detailed without being redundant.

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 an output schema (not shown) and two parameters, the description thoroughly explains return behaviors in both modes, the null case, and the error case. It also discloses limitations (unavailable statistics) that an agent needs to know. Nothing critical is missing for correct invocation and interpretation.

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 0%, so the description carries the full burden. It explains that postcode is the primary lookup key and that address is optional, and clarifies what each mode returns. This adds meaning beyond the bare schema, though it does not specify format constraints or validation rules (e.g., UK postcode format), leaving some ambiguity for edge cases.

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 EPC data for a UK property or postcode area and differentiates two modes: with an address (matched certificate) vs without (record count and rating distribution). It also distinguishes itself from siblings by explicitly stating what is NOT available (property-type breakdown, floor-area statistics) and by clarifying null vs error behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage conditions: with an address for a specific certificate, without for aggregate stats. It also explains when null is returned and that errors indicate service failure, not absence of data. However, it does not directly compare to sibling tools like property_epc_search or property_epc_summaries, leaving some selection inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses why the tool is unsupported: reproducing the old response would require one upstream request per certificate, making it silently expensive. This goes beyond the readOnlyHint annotation (which confirms it's read-only) and explains the behavioral trade-off. 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?

The description is concise and well-structured. The deprecation notice is front-loaded, the old purpose is stated in one sentence, and the rationale is given in a short final sentence. Every sentence earns its place 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?

For a deprecated tool, this is complete: it explains what it did, why it's unsupported, and what to use instead. The output schema exists but is not needed since the tool should not be invoked. An agent has all the information required to route correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage and the description does not elaborate on the postcode parameter beyond mentioning 'every certificate at a postcode'. However, the sole parameter is self-explanatory and the tool is deprecated. The description minimally compensates, but not fully—hence a baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is deprecated and explains exactly what it used to do (returned score, floor_area, property_type, habitable_rooms, inspection_date for every certificate at a postcode). It also explicitly names the recommended alternatives, distinguishing it from them. An agent immediately knows this tool should not be called and what to use instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'DEPRECATED — use property_epc_summaries then epc_certificate', giving a direct replacement and the correct ordering. It also explains why (unsupported rather than silently degraded or expensive), which helps the agent understand the context and avoid wasting calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnlyHint annotation, disclosing that it returns a bounded page, lists only certain fields, indicates 'complete' semantics, warns about snapshot instability, distinguishes empty results from errors, and clarifies that errors are not evidence of absence. This fully informs the agent about runtime behavior.

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 dense but efficiently organized, front-loading the purpose, then detailing return contents, workflow, and caveats in a logical order. Every sentence contributes unique information; nothing is redundant 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?

For a tool with an output schema and a single required parameter, the description covers all necessary operational details: return content, pagination limitations, error handling, and decision guidance for ambiguous results. No critical information is missing for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description compensates for 0% schema coverage by explaining the postcode's role and the page's bounded nature and instability, effectively conveying the meaning of both parameters. It doesn't give format details but provides functional understanding sufficient for correct invocation.

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?

States a specific verb (List), resource (EPC certificate summaries), and scope (at a postcode), and explicitly frames it as 'for candidate selection.' It clearly distinguishes from siblings like epc_certificate by describing the workflow step that fetches a specific certificate, making the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit 4-step workflow starting with this tool when a Rightmove listing lacks a house number, naming the alternative (epc_certificate) and the condition for switching. Also instructs on handling multiple candidates (present all, not guess), which is critical for correct usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful methodology context by naming the two data sources and the calculation, but it does not disclose coverage limitations, fallback behavior, or any caveats about data availability beyond what the schema's parameter descriptions already mention.

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 compact and front-loaded with the core purpose, followed by one sentence explaining the methodology. Every sentence earns its place, and there is no redundant or filler content.

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 detailed input schema, the readOnly annotation, and the presence of an output schema, the description provides enough context for an agent to understand what the tool computes and how to invoke it. It lacks only minor guidance on data coverage edge cases, which is partially addressed in schema parameter descriptions.

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 every parameter is already documented in the schema. The description does not add much parameter-level meaning, but it doesn't need to because the schema descriptions are already detailed enough.

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 a specific operation: computing gross rental yield for a UK postcode by combining Land Registry sale comps with Rightmove rental listings. This clearly identifies the resource and output, and the mention of both data sources helps distinguish it from siblings like ppd_transactions, property_comps, or rental_analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use case is implied: when you need gross rental yield for a UK postcode. However, the description does not explicitly state when to prefer this tool over sibling tools, nor does it provide exclusion criteria or alternative routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already indicates a safe read operation, and the description does not contradict it. The description adds valuable behavioral detail beyond the annotation by explaining how auto_escalate widens the search radius, how it differs from PPD auto-widening, and which response fields appear during escalation.

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 compact and front-loads the main purpose, then dedicates a tight paragraph to the auto_escalate edge case. The PPD comparison is jargon-heavy and could be simplified, but it earns its place by clarifying a potentially confusing behavioral nuance.

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 presence of an output schema reduces the need to explain return values, and the description already discloses escalation-related response fields. However, a required conceptual parameter, purchase_price, is left unexplained, and no guidance is given about radius units or how purchase_price affects the estimate, so completeness is acceptable but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It explains auto_escalate in depth and touches on radius, and postcode is contextually obvious, but purchase_price is never mentioned or connected to the tool's purpose. This partial coverage is useful but leaves a real gap.

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 the tool produces a 'Rental market analysis and achievable rent estimate', which is a specific resource and outcome. It is clear what the tool does, though it uses noun phrases rather than an imperative verb and does not explicitly distinguish it from siblings like property_yield 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?

The opening sentence implies the tool is for rental market analysis and rent estimation, giving a clear general context. However, there is no explicit guidance about when to choose this tool over related siblings, nor any 'when not to use' conditions; the rest of the description focuses on the auto_escalate parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already covers the safety profile, and the description adds meaningful behavior context: include_images fetches and embeds photos/floorplans, and max_images limits photos but not floorplans. However, it does not disclose potential response size, fetching cost, rate limits, or what 'full detail' contains beyond images.

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 compact and every sentence earns its place. The primary purpose is front-loaded, and parameter details are separated cleanly into bullet-style lines. There is no unproductive fluff or repeated schema 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 there is no output schema, the description covers what an agent needs to invoke the tool correctly: the input format, constraints, and optional behavior around images. It remains slightly vague about the exact return payload beyond calling it 'Full detail,' but as a single-listing fetch tool with read-only annotations, there is no critical missing selection or invocation 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?

Schema description coverage is 0%, so the description bears full responsibility for explaining parameters. It does this well: property_id is defined as a numeric Rightmove ID with URL examples, a 12-digit maximum, and rejection of full URLs; include_images is tied to MCP image content; max_images nuances are clear (photos only, default 3, floorplans always included). This is excellent compensation for a bare 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 it returns 'Full detail for a single Rightmove listing,' which is a specific resource and scope. It is not a formal verb phrase, but the intent is unambiguous. It differentiates itself from a list/search tool by emphasizing a single listing, though it does not name sibling 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?

The description implies usage: to get full detail for one specific Rightmove listing using a numeric property ID. However, it does not explicitly say when to use this tool over rightmove_search or other siblings, nor does it mention that property_id would typically come from a search result. Usage context is present but mostly implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safe-read characteristic is covered. The description adds useful behavioral context beyond annotations, notably that images are excluded from results and the supported values for listing_type and sort_by. This goes beyond what the read-only annotation conveys.

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 compact and front-loaded, with a clear main sentence, then two concise clarifications about param values and image exclusion. No redundant wording or filler; every segment contributes a distinct fact.

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?

An output schema exists, so return-shape details are not required. However, with 8 parameters and sibling tools, the description omits important operational details such as pagination behavior, radius units, and how this tool differs from rightmove_listing. It suffices for basic calls but not for full contextual coverage.

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 8 parameters with 0% description coverage, so the description must carry the explanatory burden. It only clarifies listing_type and sort_by; radius, max_pages, max_price, min_bedrooms, and property_type are left to their names and defaults. This leaves meaningful gaps in parameter understanding.

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 'Fetch' and the resource 'Rightmove listings' scoped to a postcode. It does not explicitly name sibling rightmove_listing as the alternative for individual property details, but the plural 'listings' and postcode focus make the search purpose reasonably distinct.

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: provide a postcode and optionally set listing_type or sort_by. It provides no explicit when-not guidance or mention of alternatives, although the sibling list suggests rightmove_listing may serve a complementary role for single-property lookups.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already indicates a safe, non-mutating operation, so the description does not need to repeat that. The phrase 'full breakdown' hints at detailed output, but no further behavioral traits (e.g., rate basis, jurisdiction limits) are disclosed. There is no contradiction with 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, front-loaded sentence that efficiently conveys the tool's purpose without unnecessary words. It is appropriately concise for a tool with a straightforward function.

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 four parameters with zero schema descriptions, the description is under-specified. It does not explain the input parameters or any regional nuances (e.g., SDLT applies to England/NI only). While an output schema exists and covers return values, the lack of parameter context makes the description incomplete for accurate invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not compensate by explaining any parameters. While parameter names like 'non_resident' and 'first_time_buyer' are somewhat self-explanatory, the description provides no additional meaning, such as expected units or how booleans affect the calculation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calculates UK Stamp Duty Land Tax with a full breakdown, using a specific verb ('calculation') and a distinct resource. This differentiates it from sibling tools that perform searches or comparisons.

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 SDLT calculations but provides no explicit guidance on when to use this tool over alternatives, nor does it mention any exclusions or prerequisite conditions. The context of sibling tools (all UK property-related) makes the purpose somewhat clear, but explicit usage direction is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.