SIC Codes UK

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds behavioral detail: returns child entries at next level, specifies hierarchy depth (22 sections, etc.) for SIC 2026, enhancing transparency beyond 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?

Three concise sentences: first states purpose and systems, second explains parent_code usage, third gives concrete hierarchy sizes. Every sentence adds essential information without redundancy.

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

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

For a browse tool with readOnly and idempotent annotations, description covers key aspects: what it does, how to navigate, and specific system details. Could mention return format (list of entries) but lacks output schema, so not required.

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 has 100% coverage and describes both parameters. Description adds value by explaining omit parent_code for top-level and giving concrete examples of top-level entries (SIC sections, GICS sectors, ICB industries), plus hierarchy counts for SIC 2026.

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 'Browse the hierarchy tree' with specific classification systems (UK SIC 2007, UK SIC 2026, GICS, ICB), differentiating it from sibling tools like lookup_sic_code and convert_between_classifications.

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 clear usage context: 'Use this to explore what codes exist' and explains behavior of omitting parent_code for top-level. Could explicitly state when not to use (e.g., for single code lookup) but adequately guides typical use.

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, idempotentHint, destructiveHint. The description adds behavioral details such as returning equivalent codes with confidence levels and relationship types, plus specific behavior for SIC<->SIC2026 conversions (unchanged, renamed, split, merged, retired, new).

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 total, front-loaded with purpose, no extraneous 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?

No output schema exists, but the description mentions return values (equivalent codes, confidence levels, relationship types). Inputs are fully covered. Could include error handling details, but adequate for a conversion tool.

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

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

Schema description coverage is 100% with each parameter described (enums for from/to, example for code). The description adds overarching context but does not significantly enhance per-parameter 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 converts classification codes between specific systems (UK SIC 2007, UK SIC 2026, GICS, ICB) with a verb and resource. It distinguishes itself from sibling tools like browse_classification_hierarchy or search_sic_codes.

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 converting between the listed classification systems but does not explicitly state when not to use or provide alternatives. No exclusions or contextual 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the exact return contents: company counts (active vs dissolved), top geographic locations, company type distribution, and cross-classification mappings. This provides behavioral insight beyond what annotations indicate.

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: first states the action and target, second lists outputs and suggests use case. No unnecessary words; each sentence adds value. Perfectly 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 no output schema, the description adequately lists the types of information returned. It covers the key aspects of the profile. However, it omits mention of error handling (e.g., invalid code) or whether the tool works with partial codes. For a simple read tool, this is mostly complete.

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

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

Schema coverage is 100%, with descriptions for both code and system. The description adds context by mentioning the classification systems (SIC, GICS, ICB) and the cross-classification mappings, which implies the system parameter affects output. This goes beyond the schema's basic type and example.

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: 'Get an industry intelligence profile for a SIC, GICS, or ICB classification code.' It details what is returned (company counts, geographic locations, distribution, mappings) and distinguishes from siblings like lookup_sic_code or browse_classification_hierarchy by offering a comprehensive profile rather than a simple lookup or hierarchy navigation.

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 'Useful for market sizing and sector analysis,' implying a use case, but does not explicitly state when to use this tool versus siblings (e.g., if you need a simple code description, use lookup_sic_code instead). No when-not-to-use or alternative mentions, leaving the agent to infer context.

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 indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context: return fields (code name, hierarchy level, breadcrumb, children, cross-mappings) and a special note about SIC 2026 predecessor codes. 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?

Two sentences: first states core purpose and supported systems, second details returned data. No fluff, front-loaded, 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, the description fully specifies return fields (code name, hierarchy level, breadcrumb, children, cross-mappings, and SIC 2026 predecessors). The tool's behavior is completely described for its 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%, with both parameters (code and system) well-described in the input schema. The tool description adds no additional parameter details beyond the schema. 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?

The description clearly states the tool looks up classification codes across four specific systems (UK SIC 2007, UK SIC 2026, GICS, ICB), and lists the returned data (code name, hierarchy level, breadcrumb, children, cross-mappings). This distinguishes it from siblings like search_sic_codes (fuzzy search) and browse_classification_hierarchy (tree navigation).

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 exact code lookup by specifying 'look up a classification code' and listing supported systems. It does not explicitly exclude alternative tools or provide when-not-to-use guidance, but the sibling tool names suggest other use cases (e.g., search, browse). The context is clear enough for an AI to infer proper 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, and destructiveHint false. The description adds useful context by stating the coverage (5.6 million UK companies) and listing the returned fields, but does not disclose rate limits or potential behavior for partial name matches.

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 with no wasted words. The first sentence front-loads the core action, and the second sentence adds scope and return details efficiently.

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

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

The description covers the main behavior, scope, and return fields. However, it does not clarify behavior for name searches that might return multiple matches (e.g., partial matches). No output schema exists, so the description could have benefited from more structural detail.

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. The description clarifies that the tool accepts either a name or registration number, but this adds minimal value beyond the schema. 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?

The description clearly states the tool looks up a UK company by name or registration number, but does not explicitly differentiate from sibling tools like search_companies or search_uk_companies_by_industry, which might also perform company lookups.

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 such as search_companies or search_uk_companies_by_industry. The description lacks any when-to-use or when-not-to-use information.

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 indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by disclosing that results are enriched with SIC codes, GICS/ICB mappings, address details, and that cursor pagination is used for large sets, going beyond 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 sentences with no wasted words: first states purpose and lists filters, second describes output. Front-loaded and scannable.

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 12 parameters and no output schema, the description covers the core functionality, enriched output, and pagination. Minor gaps like query length minimum are left to schema, but overall 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 each parameter is documented. The description lists filters at a high level but does not add per-parameter meaning beyond what the schema already provides, hence baseline score of 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 starts with 'Search UK companies with flexible filters,' clearly stating the verb (search) and resource (UK companies). It lists specific filters (name, postcode, status, etc.), distinguishing it from sibling tools like lookup_uk_company which likely retrieves a single company, and search_uk_companies_by_industry which is more 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 flexible filtering but does not explicitly state when to use this tool versus siblings like lookup_uk_company or search_uk_companies_by_industry. No when-not or alternative details are provided, leaving the agent to infer context from sibling names.

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 indicate readOnly, non-destructive, idempotent behavior. The description adds that results include ranked recommendations with relevance scores, hierarchy breadcrumbs, and cross-classifications, which is useful but not extensive. 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?

Two sentences with no wasted words. The first sentence clearly states the purpose, and the second adds concrete details about output and use case. Highly efficient and front-loaded.

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

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

Despite no output schema, the description explains what the tool returns (ranked codes, relevance scores, breadcrumbs, cross-classifications). This is sufficient for an agent to understand expected output. Parameter count is low and well-documented in schema.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds examples but essentially reiterates the schema's guidance. Since coverage is high, baseline 3 is appropriate; the description does not significantly 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 uses a specific verb ('Search') and resource ('UK SIC 2007 codes'), and clearly states the tool's function: finding codes by business activity. It distinguishes from siblings like lookup_sic_code (single lookup) and browse_classification_hierarchy (tree navigation) by specifying ranked recommendations with relevance scores and cross-classifications.

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 advises to describe a business in plain English and notes the tool is useful for Companies House registration. However, it does not explicitly state when not to use it or mention alternatives like lookup_sic_code for exact code lookups, though context from sibling names provides implicit 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?

Discloses return content (enriched data), filtering, cursor pagination with error handling for invalid/expired cursors, adding value beyond annotations that only indicate read-only and idempotent.

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: 1st states purpose, 2nd lists features and pagination; no wasted words, front-loaded.

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

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

Covers return fields and pagination; missing details like rate limits or other error conditions, but sufficient for a search tool with good schema and annotations.

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%; description provides no additional per-parameter meaning beyond schema, but lists overall filtering capabilities. 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?

Clearly states the tool finds UK companies by classification code, distinguishes from siblings like search_companies (name-based) and classification browsing 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?

Implies usage for industry-based search but does not explicitly guide when to use this vs. siblings like search_companies or lookup_uk_company; no when-not-to or alternatives mentioned.

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