ukdatapi

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

Annotations already declare the tool read-only and idempotent. The description adds value by detailing the output (score, rating, per-domain signals) and listing data sources, providing transparency beyond the annotations. No contradictions.

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

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

The description is front-loaded with the main purpose and domains, then provides usage guidelines and exclusions. At ~150 words, it is thorough but not overly long. Minor redundancy in listing sources could be trimmed, but overall 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?

Despite lacking an output schema, the description fully explains the return format (score and rating) and per-domain signals. It covers purpose, usage, exclusions, threshold handling, and sources. No gaps remain for an agent to correctly select and invoke 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 coverage is 100%, but the description adds meaningful context: it explains that company numbers give more precise results for 'identifier' and specifies credit costs for each 'depth' level ('summary' 5 credits, etc.). This goes beyond the enum values.

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 assesses UK company regulatory compliance across multiple specific domains (ICO, gender pay gap, etc.) and returns a Compliance Score with ratings. It distinguishes from siblings 'uk_entity_intelligence' and 'uk_director_intelligence' by specifying alternative tools for financial and director-level 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?

Explicitly states when to use (pre-acquisition due diligence, supplier checks, ESG) and when not to use (financial risk -> uk_entity_intelligence, director risk -> uk_director_intelligence). Also notes that companies below regulatory thresholds are scored neutrally, avoiding misuse.

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 exist, so the description carries the full burden. It describes the tool as providing intelligence, implying read-only behavior. However, it does not mention authorization needs, rate limits, or any side effects. The description is adequate but lacks depth.

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

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

The description is a single, well-structured sentence that front-loads the tool's purpose and lists key data points. No redundant information. It uses a dash to separate the main function 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 tool's moderate complexity (2 parameters, no output schema, no nested objects), the description covers the essential inputs and data types. However, it lacks details about the output format (e.g., whether results are structured or text) and any limitations (e.g., postcode format validation).

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 meaning by explaining the 'depth' parameter's levels (summary, standard, full) and their data categories. This goes beyond the schema's brief enum description, helping the agent understand what data each level includes.

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

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

The description clearly states it provides 'UK Digital Connectivity Intelligence' with specific data types (broadband speeds, superfast/ultrafast availability, mobile 4G coverage by operator, Digital Readiness Score). This distinguishes it from sibling tools like uk_demographics_intelligence or uk_location_intelligence, which focus on 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?

The description mentions sources (Ofcom Connected Nations) and lists the data provided, implying use cases for connectivity analysis. However, it does not explicitly state when not to use it or compare it to alternatives like uk_location_intelligence for location-based insights.

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 behavioral disclosure burden. It lists key data sources and the summary/standard/full depth levels, giving a sense of scope. However, it does not disclose potential data lag, update frequency, or any restrictions (e.g., valid postcode formats or rate limits).

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, dense paragraph that efficiently conveys the tool's scope, data sources, and a brief note on depth levels. It is front-loaded with the purpose and uses a dash for structure. Only minor excess: the full list of data types could be more structured but is still concise.

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

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

Given no output schema and no annotations, the description provides a reasonable overview of the data included and the depth levels. For a demographics intelligence tool, this level of detail is largely sufficient to inform agent usage, though return structure details could help 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 coverage is 100%, and the description does not add much beyond what the schema provides for parameters. The 'depth' parameter is described in the schema with enum values and defaults, and the description only summarizes the depth options. For a tool with good schema coverage, this is acceptable.

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 specific sources (ONS Census 2021, Nomis, MHCLG IMD) and includes a proprietary Consumer Spending Power Index. It effectively distinguishes itself from sibling tools which cover different domains (connectivity, education, 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 usage for demographic queries but lacks explicit guidelines on when to use this tool versus alternatives. It does not specify prerequisites or limitations, but the context of sibling tools covering different domains provides implicit differentiation.

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 carries full burden. It states data sources (Companies House, The Gazette) and lists output components. However, it doesn't disclose if this is a read-only operation, if it returns cached vs live data, or any rate limits. With no annotations, this is a moderate disclosure 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?

Description is concise (3 sentences) with front-loaded purpose and structured detail. Every sentence adds value. Could be slightly improved by a briefer second sentence, but overall 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 2 params, no output schema, and no annotations, the description provides adequate coverage: input semantics (name_or_id), depth variants, and output components. It explains what the tool returns but does not specify return format or response structure. However, for a search/info tool without output schema, this is reasonably complete.

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

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

Schema coverage is 100% with detailed descriptions for both parameters. Description adds context about what each depth level returns ('summary', 'standard', 'full'), which significantly complements the enum options in schema. However, description doesn't elaborate beyond what's already in schema param 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 it provides UK Director Network Intelligence, specifying search by name or officer ID. It lists all returned data types including disqualifications, portfolio analysis, Gazette notices, and risk score. This is highly specific and distinguishes it from sibling tools which focus on different UK intelligence 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?

Description implies when to use (searching directors), but provides no explicit guidance on when not to use or how it differs from sibling tools like uk_entity_intelligence. The depth parameter gives usage variants, but no advice on selecting between them.

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 key behavioral traits: the tool generates an opinionated verdict, includes specific metrics (Corporate Distress Score, red/green flags), and sources data from listed authorities. However, it lacks details on rate limits, authentication needs, or error handling, leaving gaps in 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 and structured efficiently in two sentences, covering verdicts, components, cost replacement, and sources. It avoids unnecessary details, though it could be slightly more concise by integrating some elements more tightly.

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 (synthesizing reports from multiple sources) and lack of annotations or output schema, the description is moderately complete. It outlines the report's components and sources but does not detail the output structure, potential limitations, or integration specifics, leaving room for improvement in guiding the 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%, with the parameter 'identifier' documented as 'Company number or company name'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules, so it meets the baseline 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 a specific verdict system (PROCEED, PROCEED_WITH_CAUTION, ENHANCED_DUE_DILIGENCE, DO_NOT_ENGAGE). It distinguishes itself from sibling tools by focusing on due diligence rather than education, energy, legal, or other intelligence domains, and specifies it replaces specific CreditSafe reports.

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 stating it synthesizes due diligence reports for UK companies, but does not explicitly state when to use this tool versus alternatives or provide exclusions. It mentions sources (Companies House, FCA, etc.), which suggests applicability to UK entities, but lacks direct guidance on tool selection among siblings.

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 source (DfE GIAS + Ofsted), which adds context about reliability and scope, but lacks details on rate limits, authentication needs, error handling, or response format. The description doesn't contradict annotations, but could be more informative about behavioral traits.

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 concise, using a single sentence that efficiently conveys the tool's purpose, scope, and data sources without unnecessary details. Every word earns its place, making it easy to understand 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 adequate but has gaps. It covers the purpose and data sources but lacks information on output format, error cases, or usage constraints. Without annotations or output schema, more behavioral context would improve 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 parameters well. The description adds value by clarifying the tool's focus on schools and data sources, but doesn't provide additional parameter semantics beyond what's in the schema. With 3 parameters and high schema coverage, a baseline of 3 is appropriate, but the description's context 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 ('schools near any postcode') and resources (Ofsted ratings, type, phase, pupil numbers), and distinguishes itself from siblings by focusing on education intelligence rather than other domains like property, transport, or health.

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 by mentioning 'schools near any postcode,' suggesting it's for location-based queries, but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. It doesn't reference sibling tools or specify scenarios where other tools might be more appropriate.

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. While it lists the types of data returned and sources, it doesn't describe important behavioral aspects like whether this is a read-only operation, rate limits, authentication requirements, data freshness, or error conditions. The description provides content scope 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 extremely efficient - a single sentence packed with essential information: tool scope, specific data types, and data sources. Every element earns its place with zero wasted words. The structure is front-loaded with the core purpose followed by implementation details.

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

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

For a tool with 2 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate context about what data is returned and sources. However, it lacks information about return format, error handling, and operational constraints that would be important for an AI agent to use this tool effectively. The completeness is minimal but viable.

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 100% schema description coverage, the baseline is 3. The description adds value by implicitly explaining what data corresponds to each depth level: carbon intensity (summary), generation mix and EPC (standard), wholesale prices and ESG score (full). This provides semantic context beyond the schema's technical descriptions, though it doesn't fully explain the 'postcode' parameter's role 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 provides UK energy and ESG intelligence including specific data types like grid carbon intensity, generation mix, wholesale prices, local EPC efficiency, and ESG scores. It distinguishes itself from siblings by focusing specifically on energy/ESG data rather than other domains like education, health, or transport. However, it doesn't explicitly state the action verb (e.g., 'retrieve' or 'get') that the tool performs.

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 sibling tools. While it's clear this tool focuses on energy/ESG data, there's no explicit comparison to alternatives like 'uk_environmental_risk' or 'uk_property_intelligence' that might overlap in some domains. No prerequisites, limitations, or specific use cases 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?

With no annotations provided, the description carries the full burden. It discloses data sources (Companies House, FCA, etc.) and output types (profile, officers, risk signals), but lacks details on rate limits, authentication needs, error handling, or pagination. It adequately describes what the tool returns but misses 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 front-loaded with the core purpose and efficiently lists returned data and sources in two sentences. Every sentence adds value, though it could be slightly more structured (e.g., separating data points from sources). 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 no annotations and no output schema, the description provides good coverage of what the tool does and returns. However, for a tool with rich data outputs and multiple parameters, it lacks details on response format, error cases, or limitations, leaving gaps in completeness for an AI 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 clarifying that 'identifier' accepts company numbers, charity numbers, or company names, which enriches the schema's generic description. However, it does not explain the semantic impact of 'depth' levels beyond what the schema already details.

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'), the target resources ('UK company, charity, or regulated entity'), and provides a comprehensive list of returned data points. It distinguishes itself from siblings by focusing on entity intelligence rather than due diligence, education, energy, etc., which are domain-specific.

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 entity lookup but does not explicitly state when to use this tool versus alternatives like 'uk_due_diligence_report' or other sibling tools. No guidance on exclusions or prerequisites is provided, leaving usage context inferred rather than defined.

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 what the tool calculates and its data sources, but doesn't disclose important behavioral traits like rate limits, authentication requirements, response format, error handling, or whether it's a read-only operation. The description doesn't contradict any annotations since none exist.

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 perfectly concise and well-structured - a single sentence that efficiently communicates the core functionality, scoring range, geographic scope, specific factors, and data sources. Every element earns its place with no wasted words, and the information is front-loaded with the most important details first.

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 (2 parameters, no output schema, no annotations), the description provides a solid foundation but has gaps. It explains what the tool does and its data sources well, but doesn't describe the output format, error conditions, or operational constraints. Without annotations or output schema, the agent lacks complete information about what to expect from this 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?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining what factors are included at each depth level ('summary = flood + geology. standard = adds water quality. full = adds carbon intensity'), which provides important context beyond the schema's enum values. However, it doesn't elaborate on the postcode parameter beyond what the schema already 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: calculating a multi-factor environmental risk score (0-100) for UK postcodes, specifying the exact factors included (flood risk, ground stability, shrink-swell clay, radon potential, water quality, carbon intensity) and data sources. It distinguishes itself from sibling tools by focusing specifically on environmental risk assessment rather than education, health, legal, or other intelligence 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?

The description implies usage context through the listed data sources and factors, suggesting it's for environmental risk assessment in the UK. However, it doesn't explicitly state when to use this tool versus alternatives or provide any exclusion criteria. The depth parameter description offers some implicit guidance on output detail levels but no explicit usage rules.

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 the description must convey behavior. It mentions the data sources and scoring, but does not disclose if the tool creates or modifies data, if there are rate limits, or what the output format looks like. The description is adequate for a search tool but lacks depth.

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) with key information front-loaded, but could be slightly more structured (e.g., bullet points for depth levels). No wordiness.

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 simple two-parameter schema and no output schema, the description adequately covers what the tool does and its inputs. However, absence of output format hints reduces completeness slightly.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context by explaining the depth levels and giving example queries, providing additional meaning 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: searching UK grants, funding, and related opportunities from multiple sources (360Giving, UKRI, Contracts Finder). It mentions key features like a Funding Opportunity Score and search dimensions (sector, topic, keyword), and distinguishes it from sibling tools that focus on other UK-specific 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?

The description implies use cases via examples ('clean energy', 'AI') and explains the depth parameter options, but does not explicitly state when to use this tool versus alternatives (e.g., uk_tenders_intelligence for contracts only). There is no 'when-not-to-use' guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what data is available (health indicators, CQC providers, prescribing patterns) but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or what format/scope the results will have. For a data query tool with no annotation coverage, this leaves significant 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 well-structured in a single sentence that packs substantial information: the tool's domain (UK healthcare intelligence), three specific data types it provides, the geographic scope (any postcode), and three data sources. Every element earns its place with zero wasted words.

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

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

For a data query tool with no annotations and no output schema, the description is incomplete. While it efficiently states what data is available, it doesn't address how results are structured, whether there are limitations (like postcode validation requirements), data freshness, or error conditions. Given the complexity of healthcare intelligence data and lack of structured metadata, more contextual information 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 schema already documents both parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it mentions postcodes and different data types but doesn't explain parameter interactions or provide additional context about how parameters affect results. 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 provides UK healthcare intelligence including health indicators, CQC-rated care providers, and GP prescribing patterns for any postcode, with specific data sources listed. It uses specific verbs ('provides') and resources (health indicators, CQC providers, prescribing patterns), though it doesn't explicitly differentiate from sibling tools beyond the healthcare 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. While it's clear this is for UK healthcare intelligence, there's no mention of when to choose this over other intelligence tools (like education_intelligence or environmental_risk) or what specific healthcare questions it addresses best. No exclusions or prerequisites are stated.

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 are absent, so the description carries the full burden. It discloses data sources and the Innovation Score range, but does not mention behavioral aspects such as data freshness, rate limits, or potential delays. This leaves some uncertainty about the tool's performance.

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 3 sentences long and front-loaded with the tool's purpose. It is concise, but the depth level details could be more integrated rather than appended as a separate 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 moderate complexity (2 params, no output schema), the description covers the key aspects: purpose, inputs, depth variations, and data sources. It does not describe return values, but without an output schema, the agent might need to infer what is returned.

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 100% schema description coverage, the baseline is 3. The description adds value by explaining the depth levels: 'summary = patents + SIC analysis', 'standard = adds UKRI research + full scoring', 'full = adds detailed patent analysis'. This clarifies the semantic differences beyond the enum labels.

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 innovation intelligence with specific data sources (EPO, UKRI, Companies House) and components (patents, grants, SIC analysis, Innovation Score). It also specifies the input required (company name or number), making it easy to understand the tool's purpose and distinguish it from siblings.

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: search by company name or number. However, it does not provide explicit guidance on when to use this tool versus alternatives like other intelligence tools, nor does it mention when not to use it.

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

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 sources but doesn't disclose behavioral traits like whether this is a read-only search, rate limits, authentication needs, or what the output format looks like. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it 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 appropriately sized with two sentences that efficiently convey purpose and sources. It's front-loaded with the main function and avoids unnecessary details, though it could be slightly more structured by separating usage hints.

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 (search with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers what the tool does and sources but lacks details on behavior, output, or error handling, leaving room for improvement 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?

The description doesn't add parameter-specific information beyond what the input schema provides. With 100% schema description coverage for the single 'query' parameter, the baseline is 3. The description generalizes about searching sectors/topics but doesn't elaborate on query syntax, examples beyond the schema, or constraints.

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 UK legislation, pending Parliamentary bills, and relevant acts for any sector or topic, specifying the verb 'search' and resources. It distinguishes from sibling tools by focusing on legal/policy intelligence rather than education, energy, property, etc., though it doesn't explicitly contrast with them.

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 legal/policy topics but doesn't explicitly state when to use this tool versus alternatives like uk_entity_intelligence or uk_due_diligence_report. It mentions sources (legislation.gov.uk, Parliament Bills API), which provides some context but no clear exclusions or comparative guidance.

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

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

No annotations are provided, so the description carries the full burden. It mentions data sources (ONS, Police.uk, EA, FSA, Nomis, Fingertips) which adds some context about reliability and scope, but it doesn't disclose behavioral traits like rate limits, authentication needs, response formats, error conditions, or whether the operation is read-only or has side effects. For a tool with no annotation coverage, this leaves significant 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 efficiently structured in two sentences: the first states the purpose and comprehensive return data, the second lists data sources. Every element adds value without redundancy, and it's front-loaded with the core functionality. No wasted words or unnecessary details.

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 (profiling tool with multiple data types), no annotations, and no output schema, the description is moderately complete. It covers what data is returned and sources, but lacks details on output format, error handling, or behavioral constraints. For a tool with rich data integration but no structured output documentation, this leaves room for improvement in guiding the agent 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 already documents all parameters well. The description doesn't add any parameter-specific information beyond what's in the schema, but since there are only 3 parameters and the schema is comprehensive, this is acceptable. The baseline would be 3, but the description's listing of returned data types implicitly reinforces the 'depth' parameter's purpose, earning a slightly higher score.

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 specific action ('Profile any UK postcode') and lists the comprehensive data returned (admin hierarchy, demographics, deprivation indices, crime statistics, flood risk, food hygiene, carbon intensity, labour market, and health indicators). It distinguishes itself from siblings by focusing on postcode-based profiling rather than entity intelligence, property intelligence, or other domain-specific 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 'UK postcode' and listing data sources, but it doesn't explicitly state when to use this tool versus alternatives like uk_property_intelligence or uk_environmental_risk. No guidance is provided about prerequisites, limitations, or specific scenarios where this tool is preferred over siblings.

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 data sources (ONS Census, Nomis, etc.) and output types, but fails to disclose critical behavioral traits such as rate limits, authentication needs, data freshness, error handling, or whether the analysis is cached or real-time. For a data-intensive tool with no annotation coverage, this is a significant gap.

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

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

The description is efficiently structured in two sentences: the first states the purpose and outputs, the second lists data sources. Every sentence adds essential information with zero waste, making it easy to parse and front-loaded with key details.

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 (market analysis with multiple data sources) and no output schema, the description is moderately complete. It outlines what the tool returns but lacks details on output format, structure, or example responses. With no annotations and rich functionality, it should provide more behavioral context to be fully adequate.

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 documents all parameters well. The description adds value by explaining the optional 'sector' parameter's purpose ('for competitor search') and providing examples ('62020' for IT consultancy, 'restaurant'), which enhances understanding beyond the schema's basic 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 purpose with specific verbs ('analysis', 'returns') and resources ('UK postcode', 'sector'), detailing the exact outputs (Market Opportunity Score, labour market data, property market context, competitor density). It distinguishes itself from siblings by focusing on market sizing rather than due diligence, education, energy, or other intelligence types.

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 market opportunity analysis in the UK, but provides no explicit guidance on when to use this tool versus alternatives like 'uk_location_intelligence' or 'uk_property_intelligence'. It mentions optional sector filtering but lacks context 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 provided, so description carries full burden. It discloses data sources and the output score range (0-100) and categories. However, it doesn't state whether the tool is read-only or any rate limits, which is a minor gap.

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

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

Description is efficient at 3 sentences, but the first sentence is a bit long listing many items. Still, it front-loads the purpose and provides comprehensive details without 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 no output schema, description adequately covers return values by listing the main categories. Depth parameter explanation compensates for the missing output schema. However, it could mention that results are for a single postcode and any pagination limits.

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 baseline is 3. Description adds value by detailing what each depth level returns (summary=constraints+score, standard=adds applications, designations, council stats, full=adds mining risk, brownfield, full history), going beyond the enum labels.

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 returns UK planning intelligence for any postcode, listing specific data types (planning applications, conservation areas, etc.) and the proprietary Planning Development Score. It distinguishes from siblings like uk_property_intelligence and uk_location_intelligence by focusing on planning-specific 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?

Description implies use for planning-related queries by listing relevant data sources (Planning Data Platform, Natural England). No explicit when-not-to-use or alternatives among siblings, but the scope is clear from the data types.

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 cites data sources (UK Parliament Members API, UK Parliament Petitions) which adds transparency, but does not disclose important behavioral traits such as authorization requirements, rate limiting, or whether the tool is read-only.

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

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

The description is three sentences, each with a clear purpose: first sentence states what the tool retrieves, second mentions data sources, and overall structure is efficient with no wasted words.

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

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

For a tool with no output schema, the description should ideally mention the return format or structure. It names the key outputs but gives no indication of whether results are paginated, or how to interpret the 'Political Engagement Index'. Coverage is adequate but not complete.

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

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

Schema coverage is 100% and the description clarifies the 'depth' enum beyond the schema, explaining what each level returns (summary/standard/full). The postcode parameter is briefly described. This adds meaningful context 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 specifies exactly what the tool retrieves: current MP with party and tenure, active parliamentary petitions with constituency-level signature counts, and Political Engagement Index. It clearly distinguishes from siblings by being UK-specific and focused on political 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 indicates the tool is for UK political intelligence, but does not explicitly state when to use it vs alternatives. Siblings cover other domains (connectivity, demographics, etc.), but no direct guidance is given.

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 discloses behavioral traits such as the comprehensive data returned (price history, EPC, planning, environmental risk) and sources (Land Registry, etc.), but it lacks details on rate limits, authentication needs, or error handling, which are important for a tool with such broad data aggregation.

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, followed by specific return data and context, all in a single, efficient sentence with no wasted words. Every part adds value, 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?

Given the tool's complexity (aggregating multiple data sources) and no output schema, the description provides a good overview of return values but lacks specifics on format, pagination, or error cases. With no annotations, it should do more to cover behavioral aspects like data freshness or limitations.

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 explaining the 'depth' parameter's impact on output (e.g., 'summary = prices + flood'), which clarifies semantics beyond the schema's enum descriptions, though it doesn't detail the 'postcode' parameter further.

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 ('Complete property due diligence') and resources ('UK postcode'), and it distinguishes from siblings by focusing on comprehensive property intelligence rather than specialized areas like education, energy, or transport covered by other 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 mentioning it 'Replaces £20-50 conveyancing searches,' suggesting it's for property assessment, but it doesn't explicitly state when to use this tool versus alternatives like 'uk_environmental_risk' or 'uk_location_intelligence,' which might overlap in some data areas.

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, idempotentHint=true, destructiveHint=false. Description adds important behavioral details: includes first-time buyer relief, additional property surcharge, 2025/26 rates, and HMRC source. No contradictions with annotations.

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

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

Four well-structured sentences with no waste. Front-loaded with purpose, followed by output details, usage guide, and alternative tool mention.

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, but description sufficiently explains return values (total tax, effective rate, breakdown). Covers tax year and source, providing complete context for a calculator 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 coverage is 100%, but description adds specific relief details (nil rate up to £425k for first-time buyers on properties up to £625k) and surcharge (+5%) that are not in schema parameter descriptions, enhancing meaning.

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

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

Description clearly states the tool calculates UK Stamp Duty Land Tax for England and Northern Ireland, specifying what it returns (total tax, effective rate, breakdown). It distinguishes from sibling uk_property_intelligence by mentioning it covers full property due diligence.

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 (when user asks about stamp duty, SDLT, property purchase tax) and when not to use (for full due diligence, use uk_property_intelligence), providing clear guidance and an alternative.

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 states the tool provides 'intelligence' but doesn't clarify whether this is a read-only search, requires authentication, has rate limits, returns structured data, or involves any destructive operations. The description is too vague about actual behavior, leaving significant gaps for agent understanding.

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: first stating the purpose and data types, second listing sources. Every element earns its place, with no redundant information. It could be slightly more front-loaded by specifying the action verb, but overall it's appropriately concise.

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

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

Given no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what format the intelligence comes in (e.g., reports, raw data, summaries), how results are structured, whether there are limitations, or what the agent can expect after invocation. For a tool with multiple siblings and no structured behavioral hints, more context 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?

Schema description coverage is 100%, with both parameters ('region' and 'sector') clearly documented in the schema. The description adds no parameter-specific information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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 provides intelligence on UK public procurement, listing specific data types (tenders, awarded contracts, buyer profiles, average values) and sources (Contracts Finder, Find a Tender). It distinguishes from siblings by focusing on procurement rather than education, energy, legal, or other domains. However, it doesn't specify the exact verb (e.g., 'search' or 'retrieve'), keeping it at 4 instead of 5.

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. It mentions data sources but doesn't explain how procurement intelligence differs from market sizing, trade intelligence, or other related tools. There's no mention of prerequisites, alternatives, or exclusions, leaving the agent with minimal 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It describes what data is returned (duty rates, preferential rates, quotas, trade volumes) but doesn't cover important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or response format. The description provides basic functionality 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 appropriately concise with two clear sentences. The first sentence efficiently lists the intelligence types provided, and the second sentence specifies the data source. There's no unnecessary verbiage, and information is front-loaded. It could potentially be slightly more structured but is generally 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?

For a single-parameter tool with no output schema and no annotations, the description provides adequate but minimal context. It explains what data the tool returns and the source, which covers basic functionality. However, it lacks information about response format, error handling, and operational constraints that would be helpful for an AI agent. The description meets minimum viable standards but has clear 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% for the single parameter 'commodity', which is well-documented in the schema. The description doesn't add any additional parameter semantics beyond what's in the schema. It doesn't provide examples of valid commodity codes beyond the schema's example, nor does it explain the relationship between code and description inputs. 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 provides UK trade and customs intelligence including duty rates, preferential rates, quotas, and trade volumes for commodities, with a specific source (HMRC Trade Tariff). It distinguishes from siblings by focusing on trade/customs data rather than education, energy, legal, or other intelligence domains. However, it doesn't explicitly contrast with all siblings beyond the trade 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 when this tool is appropriate, when other tools might be better suited, or any prerequisites for usage. The context is implied through the title but not explicitly stated.

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. While it mentions the data source (DfT NaPTAN), it doesn't describe response format, rate limits, authentication requirements, error handling, or whether this is a read-only operation. For a tool with no 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 - a single sentence that packs in the tool's purpose, key capabilities, and data source. It's front-loaded with the core functionality. However, it could be slightly more structured by separating the different intelligence types for better readability.

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

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

For a tool with 2 parameters (100% schema coverage) but no annotations and no output schema, the description provides adequate basic context about what intelligence is available. However, it doesn't compensate for the lack of output schema by describing what the return values look like or the format of the intelligence data, which leaves gaps in understanding the tool's complete 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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it doesn't explain the practical implications of choosing different depth levels or postcode formatting requirements. 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 what the tool does: provides intelligence on nearest stations, bus stops, traffic flow, and connectivity score for UK postcodes. It specifies the source (DfT NaPTAN) and distinguishes from siblings by focusing on transport/connectivity rather than education, health, property, etc. However, it doesn't explicitly contrast with a specific transport alternative tool.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, limitations, or comparison with other tools that might provide similar transport data. It simply states what the tool does without contextual usage advice.

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, idempotentHint=true, and destructiveHint=false. The description adds context about the official register and the return fields (validity, name, address), which goes beyond the annotations without contradiction.

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

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

Two well-structured sentences deliver purpose, usage, alternative, and source with zero waste. Every word serves a purpose.

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

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

With a single parameter, full schema coverage, no output schema, and annotations covering safety, the description provides all necessary context: purpose, usage guidance, alternative, return fields, and data source.

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

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

Input schema covers vat_number with 100% description coverage. The description adds the note about automatic stripping of spaces and hyphens, which is useful behavioral detail 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?

Description starts with a clear verb+resource ('Validate a UK VAT registration number') and specifies the source (HMRC's official register). It explicitly distinguishes from a sibling tool (uk_entity_intelligence) by stating when to use the alternative.

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 use cases ('verify a supplier or customer's VAT registration, confirm trading names match, or check VAT status before issuing invoices') and a clear when-not-to-use statement with a named alternative (uk_entity_intelligence).

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 for behavioral disclosure. It lists data types returned (MOT history, mileage trend, etc.) but doesn't mention critical behaviors like whether this is a read-only operation, rate limits, authentication needs, error handling, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding how it 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 front-loads key data points (MOT history, mileage trend, etc.) and includes the source. There's no wasted text, but it could be slightly more concise by integrating the source note more seamlessly. Every element serves a purpose, making it appropriately sized.

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 one parameter with full schema coverage and no output schema, the description is moderately complete. It outlines the types of data returned, which helps the agent understand the scope, but lacks details on output format, error cases, or behavioral constraints. For a simple lookup tool, this is adequate but leaves room for improvement in guiding the agent on what to expect.

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

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

Schema description coverage is 100%, with the single parameter 'registration' clearly documented in the schema as a UK vehicle registration number. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 from siblings by focusing on vehicle data rather than education, property, or other intelligence types. However, it doesn't explicitly name the 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. While it implicitly suggests usage for vehicle-related intelligence, there's no mention of when not to use it, prerequisites, or comparisons with sibling tools like 'uk_transport_intelligence' that might overlap. The agent must infer usage context from the title 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, but the description explicitly states input requirements (postcode) and output scope (water quality scores and data categories). It does not mention API limits or error cases, but given the absence of annotations, it provides sufficient behavioral detail.

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, front-loaded with the tool's purpose, and each sentence adds unique value: first sentence defines scope, second sentence lists sources. 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?

Given the tool has no output schema and two parameters, the description adequately explains input and output context. The depth parameter is well-documented with levels, though the return format is not specified. Still complete enough for correct 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?

The input schema covers both parameters with full descriptions. The description adds meaning by mapping depth levels to output components ('summary = WFD + overflow count', etc.), enhancing understanding 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 explicitly states the tool provides 'UK Water Quality Intelligence' and lists specific data types (storm overflow discharges, bathing water classifications, etc.) and sources, clearly distinguishing it from sibling tools that focus on connectivity, demographics, or 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?

The tool's purpose is clear for water quality queries, but no explicit guidance is given on when to prefer it over sibling tools or when not to use it. However, the sibling names indicate focus areas, and the description's specification of water-related data implicitly guides usage.

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