UKDataAPI

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

Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds valuable context: companies below thresholds are scored neutrally (not penalised), and lists all data sources. No contradiction with annotations.

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

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

The description is a single well-structured paragraph that front-loads the purpose, then covers return values, usage guidelines, exclusions, and sources. Every sentence adds value without redundancies.

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?

No output schema exists, so the description fully covers return values (Compliance Score, rating categories, per-domain signals). It also explains threshold behavior and lists all six domains and sources. Complete for the tool's complexity.

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 schema already documents both parameters. The description adds a bit of extra context for the 'depth' parameter by mentioning credit costs and default value, providing additional semantics beyond 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 the tool's purpose: assessing a UK company's regulatory compliance across multiple domains. It lists specific domains and differentiates from sibling tools by naming alternatives for financial risk (uk_entity_intelligence) and director-level risk (uk_director_intelligence).

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?

Explicitly states when to use (pre-acquisition due diligence, supplier checks, ESG) and when not to (financial risk → use uk_entity_intelligence; director risk → use uk_director_intelligence), providing clear guidance for 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.

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

No annotations are provided, so the description must cover behavioral aspects. The description mentions data sources (Ofcom Connected Nations) and score range (0-100) but does not disclose critical traits: Are queries cached? Is the data updated monthly? Are there usage limits or API key requirements? For a data intelligence tool, such behavioral details are important for proper invocation.

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 highly concise: two sentences that efficiently communicate the tool's purpose, key data points, and data source. No extraneous information, and key details are front-loaded. Every sentence earns its place.

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

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

The tool has a simple schema (2 params, 1 postcode required) and no output schema. The description covers the data returned and depth levels. It is complete for basic usage, but lacks behavioral details (caching, update frequency). Given low complexity, the description is nearly sufficient.

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 schema already explains both parameters well. The description adds value by summarizing the depth levels (summary = broadband only, etc.) but does not add meaning beyond the schema. Given full schema coverage, a baseline 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 provides UK digital connectivity intelligence including broadband speeds, availability, mobile 4G coverage by operator, and a Digital Readiness Score. It distinguishes itself from sibling tools (other uk_*_intelligence tools) by specifying the domain of connectivity. However, it could be more precise about the action (e.g., 'retrieve' or 'get') and the specific resource (postcode-based connectivity 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 usage via the depth parameter, which controls the breadth of data returned, but provides no guidance on when to use this tool versus other uk_*_intelligence tools. No alternatives or exclusions are mentioned, but the context of sibling tools suggests domain-specific usage. A clear usage scenario (e.g., 'Use for site selection or property assessments') would improve this score.

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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention any destructive or read-only behavior, rate limits, or data update frequency. The tool likely reads data, but this is not explicit.

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

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

The description is concise (two sentences) and front-loaded with the tool's purpose. It lists data sources, which is helpful but could be integrated into the first sentence.

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 no output schema, the description could mention return format or example usage. It adequately covers the tool's scope and sources but leaves ambiguity about what the output looks like.

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

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

Schema coverage is 100%, and the description adds value by explaining the 'depth' enum values: summary, standard, and full with brief definitions. This clarifies the parameter beyond the schema's enumeration.

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 UK demographics data from Census 2021 and other official sources, listing specific data categories like population, housing, and economic activity. However, it does not differentiate from sibling tools such as uk_education_intelligence or uk_health_intelligence, which cover other domains.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools like uk_location_intelligence or uk_property_intelligence might overlap, but no exclusions or comparisons are mentioned.

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?

No annotations are provided, so the description carries full burden. It describes the output comprehensively but does not disclose behavioral traits like data freshness, rate limits, or authorization requirements. The description mentions sources but lacks operational details.

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, tightly packed with information. Each sentence adds value: first defines purpose and capability, second lists data sources and outputs. No wasted words.

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

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

Given there is no output schema, the description adequately explains all returned data types. However, it lacks details on pagination, response format details, and error conditions. Still, for a intelligence search tool, it covers key aspects well.

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 schema already documents both parameters well. The description adds value by explaining how the depth parameter controls the breadth of data (summary vs standard vs full) and gives concrete examples for name_or_id, which helps an agent formulate queries.

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 by name or officer ID for UK director intelligence, and lists all data returned (directorships, disqualifications, portfolio analysis, Gazette notices, risk score). It distinguishes itself from sibling tools, all of which serve different intelligence domains (connectivity, demographics, etc.).

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

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

The description implies the tool is for investigating UK directors, which is clear from the name and content. However, it does not explicitly state when to use this tool instead of others like uk_entity_intelligence, nor does it mention when not to use it or provide alternatives.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it synthesizes a report with specific verdict categories (PROCEED, etc.), includes components like Corporate Distress Score, red/green flags, governance assessment, and actionable recommendations. It also mentions cost implications (replacing Creditsafe reports) and data sources, adding valuable context beyond basic functionality.

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 appropriately sized and front-loaded, starting with the core purpose and verdict details, then listing report components, cost comparison, and sources. Every sentence adds essential information without redundancy, making it efficient and well-structured for quick comprehension.

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

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

Given the complexity of generating a due diligence report with multiple components and no output schema or annotations, the description is largely complete. It outlines the report's structure, verdict options, and data sources. However, it lacks details on output format or potential limitations, which could be helpful for an agent to understand what to expect from the tool's response.

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

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

The input schema has 100% description coverage, with the single parameter 'identifier' clearly documented as a company number or name. The description does not add any additional meaning or clarification about this parameter beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.

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: synthesizing a company due diligence report with an opinionated verdict. It specifies the verb 'synthesized' and resource 'company due diligence report', and distinguishes itself from sibling tools by focusing on due diligence rather than intelligence or risk assessments in other domains like education or transport.

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

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

The description implies usage context by mentioning it replaces £5-25 Creditsafe reports and lists sources (Companies House, FCA, etc.), suggesting it's for UK company due diligence. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusions, leaving the agent to infer appropriate scenarios.

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?

No annotations are provided, so the description carries the full burden. It mentions the data sources but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or what happens with invalid postcodes. For a tool with no annotations, this leaves significant gaps in understanding how it behaves operationally.

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 and efficient: it states the core function, key data points, and sources in a single, clear sentence. Every word earns its place, with no redundant information or unnecessary elaboration, making it easy to grasp 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 (3 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and sources well, but without annotations or output schema, it lacks details on behavioral traits and return values. This is adequate for basic understanding but not fully comprehensive.

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 schema already documents all parameters (postcode, depth, phase) with descriptions and enums. The description adds no additional meaning beyond what the schema provides, such as explaining how 'depth' affects results in practice or providing examples for 'phase'. Baseline 3 is appropriate when the schema does the heavy lifting.

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: it finds schools near any UK postcode and provides specific data points (Ofsted ratings, type, phase, pupil numbers). It distinguishes itself from sibling tools by focusing on education intelligence rather than due diligence, energy, property, etc., and specifies the data sources (DfE GIAS + Ofsted).

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

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

The description implies usage context (finding schools near postcodes with educational data) but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided on when not to use it or what other tools might be better for different needs, such as using uk_location_intelligence for general location data without educational details.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the types of data returned (carbon intensity, generation mix, etc.) but doesn't describe how the tool behaves: it doesn't mention whether it's a read-only operation, potential rate limits, authentication needs, error handling, or data freshness. For a tool with no annotations, this leaves significant gaps in understanding its operational characteristics.

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 efficiently structured in a single sentence that packs substantial information: it lists the key data outputs and sources without unnecessary words. It's front-loaded with the core purpose, and every element (data types, sources) earns its place by clarifying the tool's scope.

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 (energy/ESG data with multiple outputs), no annotations, and no output schema, the description is moderately complete. It covers what data is available and sources, but lacks details on return formats, error conditions, or behavioral traits. For a tool with rich potential outputs, it should do more to compensate for the missing structured fields, though it meets a minimum viable 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?

The input schema has 100% description coverage, so the baseline is 3. The description adds value by implicitly explaining the 'depth' parameter: it lists the data types (carbon intensity, generation mix, wholesale prices, etc.), which aligns with the schema's enum descriptions for summary/standard/full. This provides context for what each depth level includes, enhancing understanding beyond the schema alone.

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: provides UK energy and ESG intelligence including grid carbon intensity, generation mix, wholesale prices, local EPC efficiency, and ESG scores. It specifies the data sources (National Grid ESO, Elexon, EPC Register), which adds specificity. However, it doesn't explicitly distinguish this tool from its siblings (like uk_environmental_risk or uk_property_intelligence) beyond the domain focus.

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 sibling tools or suggest scenarios where this tool is preferred over others (e.g., uk_environmental_risk for broader environmental data). Usage is implied by the domain focus but lacks explicit context or exclusions.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It lists data sources and return fields but does not mention critical behavioral traits like rate limits, authentication requirements, error handling, or data freshness. This leaves significant gaps for an agent to understand operational constraints.

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 efficiently structured in two sentences: the first states the purpose and return data, the second lists sources. It is front-loaded with key information and avoids unnecessary details, though it could be slightly more concise by integrating sources into the first sentence.

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 (multiple data sources, rich return fields) and lack of annotations and output schema, the description is moderately complete. It outlines return data and sources but misses behavioral context and output structure details. This is adequate but has clear gaps for effective agent use.

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 schema already documents both parameters thoroughly. The description adds no additional meaning beyond what the schema provides, such as examples for identifier formats beyond 'Company number' or implications of depth choices. Baseline 3 is appropriate as the schema does the heavy lifting.

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 action ('Look up') and the target ('UK company, charity, or regulated entity'), distinguishing it from siblings that focus on specific domains like education, health, or transport. It specifies the comprehensive data returned, making the purpose explicit and 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?

The description provides no guidance on when to use this tool versus its siblings, such as uk_due_diligence_report or uk_legal_intelligence, which might overlap in risk or regulatory aspects. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer based on tool names 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?

No annotations are provided, so the description carries the full burden. It discloses the tool's behavior by listing the factors combined and data sources, but does not mention critical traits like rate limits, authentication needs, error handling, or whether the score is real-time or cached. The description adds some context but leaves gaps in behavioral disclosure.

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 in the first sentence, followed by specific factors and sources in a concise list. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.

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 (multi-factor risk score) and lack of annotations and output schema, the description is moderately complete. It covers the purpose, factors, and sources, but does not explain the return format, score interpretation, or potential limitations. For a tool with no output schema, more detail on the response would be beneficial, leaving some gaps in completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description does not add specific parameter semantics beyond what's in the schema, but it implicitly supports the 'depth' parameter by listing factors that align with the depth levels. Since there are only 2 parameters and schema coverage is high, a baseline of 3 is appropriate, but the description's factor list provides marginal additional context, warranting a 4.

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: it calculates a 'Multi-factor Environmental Risk Score (0-100) for any UK postcode' and lists the specific factors combined (flood risk, ground stability, shrink-swell clay, radon potential, water quality, carbon intensity). It distinguishes from siblings by focusing on environmental risk rather than education, health, legal, or other intelligence areas.

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 environmental risk assessment in the UK, but does not explicitly state when to use this tool versus alternatives (e.g., which sibling tools might overlap or when other tools are more appropriate). It provides context (UK postcode focus) but lacks explicit guidance on exclusions or specific scenarios.

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?

With no annotations provided, the description must fully disclose behavioral traits. It mentions data sources and a scoring system, which is good. However, it does not state if the tool is read-only or whether it makes external calls, nor does it describe any side effects or authorization requirements.

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, covering purpose, data sources, and search capabilities in two sentences. It is front-loaded with the core function. However, the parenthetical note on the 'Funding Opportunity Score' could be integrated more naturally.

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 absence of annotations, descriptions must compensate. While the description covers data sources and basic usage, it lacks details on output format (no output schema) and how the scoring works. For a tool with two simple params, it is adequate but could be more 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 coverage is 100% and both parameters have descriptions. The description adds value by explaining the 'depth' enum in detail, clarifying what each level includes. The 'query' parameter is also illustrated with examples, though the description could provide more nuance on expected input format.

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 provides UK grant and funding intelligence from multiple sources including 360Giving, UKRI, and Contracts Finder, with a proprietary score. The verb 'matching' and examples of search queries clarify its purpose. However, it could better distinguish from sibling tools like uk_tenders_intelligence, which likely also covers contracts.

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 says to search 'by sector, topic, or keyword' and provides example queries, which is helpful. However, it does not explain when to use this tool over siblings like uk_tenders_intelligence or uk_innovation_intelligence, nor does it mention any prerequisites or limitations.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions data sources but does not describe behavioral traits such as rate limits, authentication requirements, response formats, error handling, or whether the operation is read-only or has side effects. This leaves significant gaps for an agent to understand how to interact with the tool effectively.

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 highly concise and front-loaded, consisting of a single sentence that efficiently conveys the tool's purpose, scope, and data sources without any wasted words. Every element (e.g., 'health indicators', 'CQC-rated care providers', 'GP prescribing patterns', 'Sources') earns its place by adding critical 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 tool's complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and data sources well, but without annotations or an output schema, it lacks details on behavioral aspects (e.g., response format, errors) and does not fully compensate for the missing structured data, leaving the agent with gaps in understanding how to use the tool effectively.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add specific parameter semantics beyond what the schema provides, but it implicitly supports the parameters by mentioning the data types (health indicators, CQC providers, prescribing data) that align with the 'depth' enum values. With 2 parameters and high schema coverage, a baseline of 3 is appropriate, but the description's alignment with parameter values slightly enhances 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 tool's purpose with specific verbs ('health indicators', 'CQC-rated care providers', 'GP prescribing patterns') and resources ('UK Healthcare Intelligence'), and it distinguishes itself from siblings by focusing exclusively on healthcare data rather than education, energy, legal, or other domains covered by 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 context by specifying 'for any postcode' and listing data sources, but it does not explicitly state when to use this tool versus alternatives (e.g., other intelligence tools for different domains) or provide any exclusions. Usage is inferred from the purpose 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?

No annotations provided, so description must cover behavioral traits. It lists data sources and mentions depth variations but does not disclose any side effects, rate limits, or required permissions. The description is adequate but lacks depth on what 'full' depth entails beyond 'detailed patent analysis.'

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?

Description is two sentences and front-loaded with purpose. The first sentence provides a comprehensive overview and the second adds search and source context. Slightly more verbose than necessary for the enum explanation, but still efficient overall.

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

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

Given the complexity (multiple data sources, depth levels, no output schema), the description adequately covers the tool's purpose, inputs, and depth variations. However, it does not describe the output format or what the Innovation Score range means, which would be helpful for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that 'summary' includes patents+SIC, 'standard' adds UKRI+scoring, and 'full' adds detailed patent analysis. This semantic mapping enriches the enum options beyond the schema's terse 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?

Description clearly states the tool provides UK innovation intelligence combining four specific data sources (EPO patents, UKRI grants, SIC analysis, Innovation Score) with a specific search method (by company name or number). It is distinct from sibling tools which cover other domains like connectivity, demographics, etc.

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?

Description implies usage for searching UK companies innovation data, but does not explicitly state when to use this tool vs alternatives. While sibling tools cover different domains, there is no guidance on scenarios where this tool is preferred or when to use different depth settings.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions data sources but doesn't describe what the tool actually returns (full text, summaries, metadata), whether there are rate limits, authentication requirements, or how results are structured. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is appropriately concise with two sentences that efficiently convey purpose and sources. It's front-loaded with the core functionality. However, the second sentence about sources could be integrated more smoothly, and there's some room to eliminate redundancy between 'UK Legal & Policy Intelligence' and the subsequent explanation.

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 lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what format results come in, whether there's pagination, error handling, or what constitutes a successful search. For a tool that presumably returns complex legal/policy information, more context about output expectations is needed.

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

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

The schema description coverage is 100%, so the schema already documents the single 'query' parameter thoroughly. The description adds minimal value beyond what's in the schema - it provides example queries ('data protection', 'employment') which slightly enhance understanding, but doesn't add significant semantic context beyond the schema's 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 the tool's purpose with specific verbs ('search UK legislation, pending Parliamentary bills, relevant acts') and resources ('legislation.gov.uk, Parliament Bills API'). It distinguishes itself from sibling tools by focusing specifically on legal and policy intelligence rather than other domains like education, energy, or transport.

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 its siblings. While it implies usage for legal/policy searches, it doesn't explicitly state when to choose this over alternatives or what scenarios warrant its use. No exclusions or prerequisites are mentioned.

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?

No annotations are provided, so the description carries the full burden. It lists data sources but does not disclose behavioral traits such as rate limits, authentication needs, data freshness, or error handling. The description is informative about what data is returned but lacks operational 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?

The description is front-loaded with the core purpose in the first sentence, followed by a detailed but efficient list of data types and sources. Every sentence adds value without redundancy, making it appropriately sized for a complex tool.

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 (3 parameters, no output schema, no annotations), the description is moderately complete. It covers what data is returned and sources, but lacks details on output format, error cases, or performance characteristics, which are important for a data-rich 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%, so the baseline is 3. The description adds value by summarizing the data categories returned, which helps contextualize the 'depth' parameter's enum values (e.g., 'full' includes carbon, labour, health). However, it does not explain parameter interactions or provide examples beyond 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 the tool's purpose with a specific verb ('Profile') and resource ('UK postcode'), and lists the comprehensive data types returned. It distinguishes itself from siblings by focusing on location-based intelligence rather than specialized domains like education, health, or property.

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 profiling UK postcodes with various data types, but does not explicitly state when to use this tool versus alternatives like uk_property_intelligence or uk_environmental_risk. It mentions sources but lacks guidance on prerequisites or exclusions.

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?

No annotations are provided, so the description carries full burden. It discloses data sources (ONS Census, Nomis, Land Registry, Companies House) which adds useful context about reliability and scope. However, it doesn't mention behavioral traits like rate limits, authentication needs, response time, error conditions, or whether the analysis is cached/real-time. For a tool with no annotations, this leaves significant gaps in understanding how it behaves operationally.

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 appropriately sized with two sentences: the first states purpose and returns, the second lists sources. It's front-loaded with key information and avoids redundancy. However, the second sentence about sources could be integrated more smoothly, and there's minor room to tighten phrasing.

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 no annotations and no output schema, the description provides good purpose and data scope but lacks operational context. It covers what the tool does and sources, but doesn't explain return format, error handling, or usage constraints. For a 3-parameter tool with rich data returns, this is adequate but has clear gaps in guiding effective agent 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 100%, so the schema already documents all three parameters thoroughly. The description adds marginal value by mentioning 'optional sector' and implying the postcode is for geographic targeting, but doesn't provide additional semantics beyond what's in the schema (e.g., format examples for sector beyond SIC codes, practical implications of depth levels). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool performs 'Market opportunity analysis for any UK postcode and optional sector' and lists the specific data returned (Market Opportunity Score, labour market data, property market context, competitor density). It distinguishes from siblings by focusing on market sizing rather than due diligence, education, energy, etc. However, it doesn't explicitly contrast with the most similar sibling 'uk_location_intelligence' which might overlap in geographic 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 implies usage context through 'Market opportunity analysis' and mentions optional sector filtering, suggesting when to include the sector parameter. However, it provides no explicit guidance on when to use this tool versus alternatives like 'uk_location_intelligence' or other UK intelligence tools, nor does it mention prerequisites or exclusions.

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?

No annotations are provided, so the description must convey behavioral traits. It mentions data sources and includes a 'depth' parameter controlling output richness, but does not disclose whether the tool is read-only, any rate limits, or what happens if the postcode is invalid.

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 paragraph but packed with information. It is front-loaded with the core purpose. A bullet list might improve readability, but it remains efficient.

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 rich schema with the depth parameter and no output schema, the description provides sufficient context on what each depth level returns. It lacks details on error handling or response format, but the data sources list adds completeness.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description adds context about the data sources and score range, but the parameter semantics are already well covered by the schema. Hence 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 returns UK planning intelligence for any postcode, listing specific data types (planning applications, conservation areas, etc.) and a proprietary score. It distinguishes itself from siblings like uk_property_intelligence by focusing on planning-specific constraints and approvals.

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

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

The description implicitly suggests use for assessing development viability at a given postcode. It does not explicitly mention when not to use it or name alternative siblings, but the context of postcode-based planning intelligence is clear from the tool name and description.

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?

No annotations are provided, so the description carries the full burden. It names data sources (UK Parliament APIs), implying external dependencies. However, it does not disclose latency, rate limits, or whether petitions data is real-time. The 'full' depth hints at detailed analysis but lacks specifics.

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: first states what the tool does, second lists sources. Front-loaded with essential info, zero 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?

With no output schema, the description explains the return structure for each depth level. The tool is moderate in complexity; the description covers core outputs but omits optional details like petition count ranges or engagement index scale.

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

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

Schema coverage is 100%, and the description adds context by explaining the depth levels (summary, standard, full) with concrete outputs (MP profile, petitions, engagement, detailed analysis). This meaningfully supplements 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 specifies the tool provides MP details, parliamentary petitions, and a Political Engagement Index for a given UK postcode, naming the data sources. It is distinct from sibling tools like uk_demographics_intelligence or uk_entity_intelligence.

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

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

The description implies the tool is for querying political data by postcode, and the depth parameter allows narrowing scope. However, it does not explicitly state when to use this tool versus alternatives, though the unique set of data (MP, petitions, engagement index) differentiates it.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by mentioning data sources (Land Registry, EPC Register, etc.) and the tool's practical value (replaces conveyancing searches). However, it doesn't disclose important behavioral aspects like rate limits, authentication requirements, error handling, or response format details.

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 efficiently structured: it starts with the core purpose, lists specific outputs, explains practical value, and cites data sources. Every sentence adds value with no wasted words, and information is front-loaded appropriately for agent comprehension.

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

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

Given the tool's complexity (comprehensive property intelligence with multiple data sources) and no output schema, the description does a reasonable job but has gaps. It lists output categories but doesn't describe the return structure, format, or potential limitations. For a tool with such rich functionality, more detail about response organization would be helpful.

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 value by explaining what different depth levels return: 'summary = prices + flood. standard = adds EPC, planning, crime. full = adds geology, detailed risk scoring.' This provides meaningful context beyond the schema's enum values, though it doesn't fully explain the 'postcode' parameter beyond what the schema states.

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: 'Complete property due diligence for a UK postcode' with specific outputs listed (price history, EPC profile, planning constraints, Environmental Risk Score). It distinguishes from siblings by focusing on comprehensive property intelligence, unlike more specialized tools like uk_energy_intelligence or uk_environmental_risk.

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

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

The description provides clear context for when to use this tool: for property due diligence on UK postcodes, replacing conveyancing searches. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for comprehensive property assessment.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: includes first-time buyer relief and additional property surcharge details, and notes rates are for 2025/26. No contradictions.

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

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

Description is very concise: 4 sentences covering purpose, return values, reliefs, usage guidance, and source. No redundant words, 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?

For a calculator with 2 params and no output schema, the description explains what is returned (total tax, effective rate, breakdown) and key reliefs. It also states the source (HMRC). Could be more explicit about residential-only scope, but the reliefs imply residential. Overall sufficient.

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 baseline 3. The description adds extra meaning: price is in GBP, buyer_type options explained with thresholds (e.g., first-time: nil rate up to £425k on properties up to £625k, additional: +5% surcharge). This goes beyond the 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 clearly states the tool calculates UK Stamp Duty Land Tax (SDLT) for England and Northern Ireland, returns total tax, effective rate, and breakdown by band. It distinguishes from sibling 'uk_property_intelligence' by specifying that this tool is for tax calculation 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?

Explicitly tells when to use: when user asks about stamp duty, SDLT, property purchase tax, or tax on house purchase. Also tells when not to use: for full property due diligence, use uk_property_intelligence. This is clear and helpful.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions data sources (Contracts Finder, Find a Tender) which adds some context, but doesn't describe what the tool actually returns (e.g., format, structure, limitations), whether it requires authentication, rate limits, or how it handles the optional filtering parameters. For an intelligence tool with no output schema, this leaves significant behavioral gaps.

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

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

The description is extremely concise and front-loaded with all essential information in a single sentence. Every word earns its place by specifying the domain, data types, and sources without any fluff or redundancy. The structure efficiently communicates the tool's scope.

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 no annotations and no output schema, the description is incomplete for proper agent usage. While it specifies the domain and sources, it doesn't explain what kind of intelligence is returned (e.g., reports, lists, analytics), how results are structured, or any limitations. For a 2-parameter intelligence tool with no structured output documentation, this leaves too many 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?

Schema description coverage is 100%, so the schema already documents both optional parameters (region and sector) with examples. The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage and no parameters mentioned in the description, 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 provides intelligence on UK public procurement including open tenders, awarded contracts, buyer profiles, and average values, with specific data sources named. It uses specific verbs like 'intelligence' and identifies the resource domain. However, it doesn't explicitly distinguish this from sibling tools like 'uk_market_sizing' or 'uk_trade_intelligence' that might overlap in economic data 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 no guidance on when to use this tool versus the 13 sibling tools listed. It doesn't mention alternatives, exclusions, or specific contexts where this procurement intelligence tool is preferred over other UK intelligence tools. The user must infer usage from the title alone without explicit direction.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what data is retrieved (duty rates, preferential rates, quotas, trade volumes) and the source, but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 extremely concise and well-structured in a single sentence. It front-loads the core purpose ('UK Trade & Customs Intelligence'), lists key data types, specifies the target ('for any commodity'), and cites the source. Every word contributes meaning without redundancy, making it efficient and easy to parse.

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

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

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is minimally complete. It covers what the tool does and the data source, but lacks details on behavioral traits, usage context, and output expectations. Without annotations or an output schema, the description should ideally provide more context about the operation's nature and results to be fully helpful.

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

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

The input schema has 100% description coverage, with the single parameter 'commodity' documented as accepting commodity codes or product descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as examples beyond '0201' or formatting details. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance 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 tool's purpose: retrieving UK trade and customs intelligence including duty rates, preferential rates, quotas, and trade volumes for commodities. It specifies the source (HMRC Trade Tariff) and distinguishes itself from siblings by focusing on trade intelligence rather than due diligence, education, energy, or other domains. However, it doesn't explicitly contrast with a specific alternative tool for trade data, keeping it from a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for application. While it implies usage for commodity-related trade queries, it lacks explicit instructions on when to choose it over other tools or what scenarios it's best suited for.

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?

With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose rate limits, authentication needs, data freshness, error handling, or what 'connectivity score' means operationally. The source attribution (DfT NaPTAN) is helpful but insufficient for full transparency.

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

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

The description is appropriately sized and front-loaded, efficiently conveying the core purpose in one sentence with a source attribution. Every word earns its place without redundancy or unnecessary elaboration.

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 2 parameters with full schema coverage but no output schema or annotations, the description is minimally adequate. It covers the what but lacks details on return format, error cases, or practical usage context that would help an agent invoke it correctly without trial and error.

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 doesn't add meaningful parameter semantics beyond what's in the schema—it mentions data types but doesn't explain parameter interactions or provide examples beyond the schema's enum descriptions for 'depth'.

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 intelligence on transport and connectivity for UK postcodes, listing specific data types (nearest stations, bus stops, traffic flow, connectivity score). It distinguishes from siblings by focusing on transport, but doesn't explicitly contrast with similar tools like 'uk_location_intelligence' which might overlap.

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

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

No guidance on when to use this tool versus alternatives is provided. The description doesn't mention sibling tools or other contexts where this tool is preferred, nor does it specify prerequisites or exclusions for 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, openWorldHint, idempotentHint, destructiveHint. Description adds value by specifying data source (HMRC) and return fields (validity, company name, address). No contradiction with annotations.

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

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

Two concise, front-loaded sentences with a source citation. No redundant information. 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?

Despite no output schema, description lists return values (validity, company name, address). Single-parameter tool is fully covered with no 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?

Single parameter vat_number has full schema description covering format and auto-stripping. Description doesn't add new info beyond schema, so baseline 3 is appropriate.

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

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

Description clearly states the verb 'validate', the resource 'UK VAT registration number', and the data source 'HMRC's official register'. It lists specific return values (validity, company name, address) and distinguishes from sibling tool 'uk_entity_intelligence'.

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?

Explicitly states when to use: verify supplier/customer VAT registration, confirm trading names, check VAT status before invoicing. Also provides alternative: use uk_entity_intelligence for full due diligence.

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?

No annotations are provided, so the description carries full burden. It lists the types of data returned (MOT history, mileage trend, etc.) but doesn't disclose critical behavioral traits: whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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 efficiently structured in a single sentence that lists key data points and the source. It's appropriately sized for a single-parameter tool, though it could be slightly more front-loaded by starting with the action verb. There's no wasted text, and every element serves to inform the user about what data is available.

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 (retrieving multiple data points about vehicles), no annotations, and no output schema, the description is minimally complete. It outlines what data is returned but doesn't provide format details, error handling, or usage constraints. For a tool with richer data output, more context would be helpful, but it meets basic requirements.

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

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

The input schema has 100% description coverage, with the single parameter 'registration' clearly documented as a UK vehicle registration number with an example. The description doesn't add any parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate but minimal value addition from the 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 the tool retrieves UK vehicle intelligence data including MOT history, mileage trend, advisories, failures, and Vehicle Health Score. It specifies the source (DVSA MOT History) and distinguishes itself from sibling tools by focusing on vehicle data rather than education, energy, property, etc. However, it doesn't explicitly name the action verb (e.g., 'retrieve' or 'get'), slightly reducing specificity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, limitations, or comparison with sibling tools like 'uk_transport_intelligence' which might have overlapping functionality. The user must infer usage from the tool name and description 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?

With no annotations provided, the description carries the full burden. It clearly indicates data sources and the proprietary Water Quality Score, implying read-only behavior. However, it does not disclose if results are cached or if API rate limits apply.

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 relatively concise, listing key data types and sources in a single paragraph. However, it could be slightly more structured, e.g., separating usage from source attribution.

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 the data (multiple sources, scoring) and the lack of output schema, the description provides a good overview. It covers enough for an agent to understand the tool's scope, though it could mention result format or pagination.

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 schema already documents both parameters. The description adds context about what each depth level includes, which is helpful but partially redundant with the schema's enum 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 provides UK Water Quality Intelligence, listing specific data categories (storm overflow discharges, bathing water classifications, etc.) and data sources. This distinguishes it from sibling tools like uk_environmental_risk or uk_location_intelligence.

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

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

The description implies the tool is for water quality queries but does not explicitly state when to use this tool over alternatives. No guidance on when not to use it or prerequisites beyond a postcode.

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