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?

Beyond the readOnlyHint annotation, the description reveals important behavioral details: it is a direct lookup 'with no fuzzy matching or postcode re-fetch,' and it returns 'the full EPC certificate or None if not found.' This adds genuine behavioral context.

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 concise sentences, each earning its place: purpose, when to use, parameter source, and return value. No unnecessary words, and the most important information is front-loaded.

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

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

For a one-parameter lookup tool with an output schema present, the description covers all necessary context: purpose, relationship to sibling tools, parameter meaning, and return behavior. Nothing important is missing.

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

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

Although schema coverage is 0%, the description defines lmk_key as a 'certificate hash' and states that it is 'returned in every property_epc_search result.' This fully compensates for the schema's lack of description and tells the agent how to obtain the parameter.

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

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

The description states a specific action: 'Fetch a single EPC certificate by its lmk_key (certificate hash).' This clearly identifies the verb, resource, and unique identifier. It also distinguishes from sibling tools by explicitly contrasting with property_epc_search and property_epc.

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 usage guidance: 'Use after property_epc_search has identified the correct cert' and explains why it's faster than property_epc(postcode, address). Also explains where to obtain the lmk_key, giving the agent clear decision criteria.

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?

Annotations already declare readOnlyHint=true, so the description doesn't need to address safety. The word 'raw' adds context that the data is unprocessed or unfiltered, which is a small but useful behavioral disclosure 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 a single sentence with no wasted words, front-loading the core purpose. It is appropriately sized for such a simple tool, though it sacrifices detail for brevity.

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, zero schema description coverage, and no usage guidance, this single-sentence description is too terse. Even with an output schema present, the agent cannot understand parameter behavior or when to apply 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?

Schema description coverage is 0%, so the description must compensate. It only hints at the postcode parameter via 'for a postcode', but limit and property_type are entirely unexplained, leaving the agent without semantics for those parameters.

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

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

The description clearly identifies the resource (Land Registry Price Paid transactions) and scope (postcode). Although it lacks an explicit verb like 'get' or 'list', the noun phrase is unambiguous and distinguishes the tool from siblings by emphasizing 'raw' 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?

No guidance is given on when to use this tool versus alternatives such as property_comps or rental_analysis. There are no prerequisites, exclusions, or alternative mentions, leaving the agent without context for selection.

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 annotations already declare readOnlyHint=true, and the description does not contradict that. It adds useful context about the analytical focus, but it does not disclose how parameters like months or search_level affect the behavior or results.

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 with no filler, and the em-dash structure front-loads the core purpose. Every word contributes meaning.

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?

Despite having an output schema, the description omits parameter semantics and usage guidance, leaving the meaning of search_level and months ambiguous. For a tool with three parameters, the description is too thin to be fully operational.

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 never mentions postcode, months, or search_level. With no parameter explanations in the description, the agent must infer meanings entirely from schema names and defaults, which is insufficient.

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 a specific verb ('identify') and a clear resource ('buildings with multiple flat sales'), which clearly distinguishes it from sibling tools like property_yield or rental_analysis. The phrase 'block-buy opportunities' adds a unique analytical angle.

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 clearly implies when to use the tool: when analyzing a postcode for block-buy opportunities based on multiple flat sales. It does not explicitly name alternatives or provide exclusion criteria, but the context is sufficiently clear.

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 goes well beyond the readOnlyHint annotation by disclosing defaults for property_type, transaction_category, filter_outliers, limit, and enrich_epc, including performance implications ('slower but richer') and edge conditions ('needs >=4 prices'). This provides substantial operational detail that an agent needs.

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 a lead sentence followed by bulleted explanations and a final sentence with caveats. Every sentence adds value, and the formatting makes the information easily scannable. No redundant fluff.

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

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

Given the tool's complexity (9 parameters, output schema present, read-only annotation), the description covers the core functionality and key parameters but omits some (e.g., search_level, address). The presence of an output schema mitigates the lack of return-format details, but the description still leaves a few operational 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?

With schema description coverage at 0%, the description carries the burden of explaining parameters. It does well for property_type, transaction_category, filter_outliers, limit, and enrich_epc, but omits months, address, and search_level entirely. This partial coverage is helpful but leaves gaps for a few parameters.

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

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

The description opens with 'Comparable sales from Land Registry Price Paid Data,' clearly identifying the tool's domain and distinguishing it from raw transaction tools like ppd_transactions. However, it lacks an explicit verb like 'Get' or 'List'; the phrase 'Defaults return' implies the retrieval behavior but is not as direct as ideal.

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 context on defaults and options, implying it is used for comparable sales analysis. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage context is implied rather than explicitly guided.

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 goes beyond the readOnlyHint annotation by detailing the exact outputs for both modes, including the components of the aggregate summary and the None return case when no certificates exist. It is transparent about the tool's behavior, though it does not cover error cases beyond None.

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 a clear summary, distinct paragraphs for each mode, and a return note. It is concise, front-loaded, and every sentence adds value with no redundancy.

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

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

For a simple read-only tool with an output schema, the description is quite complete. It explains both usage modes, the contents of the aggregate summary, and the None case. It could mention edge cases like invalid postcodes, but overall it provides sufficient context for an agent to invoke and interpret results correctly.

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

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

With 0% schema description coverage, the description partially compensates by explaining the behavioral effect of the optional 'address' parameter and implying the postcode is a UK postcode. However, it does not explicitly describe postcode format or validation, leaving some semantic gaps for the required parameter.

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

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

The description clearly identifies the tool as providing Energy Performance Certificate data for a UK property or postcode area, and explains the two modes (with/without address). It does not explicitly differentiate from sibling tools like property_epc_search or epc_certificate, but the resource and scope are well-defined.

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 provides clear guidance on how the address parameter changes behavior (with address returns a specific certificate, without returns an aggregate summary). However, it does not state when to prefer this tool over its siblings or mention exclusions, so the usage guidance is limited to parameter context rather than tool selection.

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 marks the tool as read-only, but the description adds valuable behavioral context: it returns a 'slim list' of fields, returns None when no certificates exist, and discloses the matching logic (e.g., accepting within ±5 sqm). It also handles edge cases like missing floor_area, which 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: a concise purpose sentence, a bulleted list of return fields, a numbered workflow, and a final note on the None return. Every sentence serves a clear functional purpose, with no redundant or vague 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 a single required parameter, a read-only annotation, and an output schema, the description fully covers the return fields, the no-result case, multi-match disambiguation, and integration with sibling tools. It is complete enough that an agent could execute the entire workflow without additional assumptions.

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 sole parameter 'postcode' has zero schema description coverage, but the description demonstrates its use ('Call property_epc_search(postcode)') and clarifies that it refers to a UK-style postcode. It does not add explicit format or validation details, but the parameter name and usage in the workflow are sufficiently self-explanatory for this simple string type.

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 opens with 'Browse all EPC certificates at a postcode — use when you have no house number,' which clearly states a specific verb, resource, and scope. It distinguishes itself from siblings by explicitly mentioning the house-number-less scenario and by referencing epc_certificate as the follow-up for full detail (suggesting this tool is the list version).

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

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

The description provides a detailed 5-step workflow that specifies when to call rightmove_listing first, when to call property_epc_search, how to cross-reference fields with a ±5 sqm threshold, and when to escalate to epc_certificate. It also explicitly says 'do not guess' and instructs to present all candidates if multiple matches exist, covering both typical and ambiguous cases.

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 marks this as safe; the description adds methodology context (median sale price & median monthly rent) without contradiction. It does not mention limitations like data availability or edge cases, but the annotation lowers the burden.

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

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

Two terse sentences that front-load the purpose and methodology. No filler, every word earns its place.

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

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

The description explains the core yield calculation and data sources. With output schema and full parameter coverage, it's nearly complete, though it doesn't mention default residential-only filtering or edge cases (e.g., auto_escalate behavior).

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

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

All 5 parameters have schema descriptions with 100% coverage, so the description needn't add param detail. It doesn't, earning the 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 opens with 'Gross rental yield for a UK postcode' and then details the exact computation (Land Registry sale comps + Rightmove rental listings). This clearly distinguishes it from siblings like property_comps (comps only) and rental_analysis (rental data only).

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 yield calculation and explains the two data sources, giving clear context for when to use. However, it does not explicitly name alternatives or exclusion criteria, so it stops short of a 5.

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 adds valuable context beyond the readOnlyHint annotation by explaining the auto_escalate parameter's effect (widening the search area) and the conditional thin_market response fields. This is a meaningful behavioral disclosure not present in 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?

Two sentences front-load the purpose and then concisely explain the auto_escalate behavior and response fields. 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?

The description covers the core purpose and a key behavior, but with 4 parameters and no schema descriptions, the lack of explanation for radius and purchase_price leaves gaps. The output schema may cover return values, but input semantics are incomplete.

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

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

Only auto_escalate is explained (widens search area in thin markets). With 0% schema description coverage, radius and purchase_price are undocumented, and the description fails to compensate for the missing parameter semantics.

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

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

The description states 'Rental market analysis and achievable rent estimate' which clearly identifies the tool's function with a specific resource and action. It does not explicitly distinguish from the sibling property_yield tool, so it's clear but not fully differentiated.

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

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

No explicit when-to-use or alternative guidance is provided. The description explains auto_escalate behavior but does not tell users when to choose rental_analysis over siblings like property_yield, property_comps, or rightmove_search.

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 description adds value by explaining that include_images fetches and embeds photos/floorplans as MCP image content, and that max_images caps photos while floorplans are always included. This is useful behavioral detail beyond the annotation, though it doesn't cover rate limits or other potential 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 two sentences, front-loaded with the main purpose, followed by parameter details. Every sentence earns its place without waste 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?

The description provides enough context for a simple single-listing tool: it explains the input format and optional image behavior. However, there is no output schema and the description does not enumerate what fields are included in 'full detail', which is a minor gap given the tool exists alongside specialized ones like epc_certificate.

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?

All three parameters are explained in the description: property_url_or_id is described in the main sentence, include_images and max_images are explicitly defined. The schema has 0% description coverage, so the description fully compensates by providing meaning beyond the raw parameter names.

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: 'Full detail for a single Rightmove listing (URL or numeric ID)'. This uses a specific verb ('get' implied) and resource ('single Rightmove listing'), distinguishing it from sibling tools like rightmove_search which presumably handles searches.

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

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

The description clearly implies when to use this tool (for full detail on a specific listing), and parameter hints (include_images, max_images) provide additional usage context. However, it does not explicitly mention alternatives or exclusions, though the purpose makes this mostly unnecessary.

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.