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

Beyond the readOnly/openWorld annotations, the description discloses substantial behavior: multiple-testing correction raises the bar for a clear change, rows are in SIC order not size order, counts appear only for divisions with a clear change, rounded counts cannot be used for ranking, and formation-agent addresses are excluded from area answers. These are exactly the caveats an agent needs to interpret results correctly.

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 opening question front-loads the purpose and the caveats follow in a logical order. Sentences are long and dense, and the multiple-testing explanation is slightly convoluted, but nearly every clause carries actionable information.

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

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

With an output schema present, return values need not be explained, and the description covers the interpretive pitfalls (ordering, rounding, significance, excluded addresses) thoroughly. The only minor gap is that it does not explicitly contrast itself with the ranking and area-comparison siblings.

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 area, against, to_quarter, from_quarter, and include_closed in detail. The description only reinforces the default period length; it adds no new syntax or format meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific resource and operation: new company counts broken down by 2-digit SIC industry division, comparing a period against an earlier one with a significance test. It is clearly distinct from siblings like largest_industries or rank_areas_against_great_britain, though it never names those alternatives explicitly.

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

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

It gives clear usage context ('What's growing here?'), states the default comparison period, and issues an explicit directive not to rank divisions because rounded counts are unreliable. It stops short of naming which sibling to use instead for ranking or area comparison, so the routing guidance is implied rather than spelled out.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses substantive behavioral traits: formation-agent addresses are excluded on both sides, a significance test is applied to the area's share of GB, a location quotient is computed, and the meaning of include_closed is spelled out in the schema. It stops short of describing performance, rate limits, or responses, but the output schema already covers return shape. Strong but not exhaustive.

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?

Front-loaded with the question the tool answers, followed by what it returns, its exclusions, and delegation to siblings. No sentence is filler; the length is proportionate to a six-parameter analytical tool with several exclusions to communicate.

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 scope, default periods, data exclusions, and sibling routing, while the input schema (100% coverage) and output schema handle parameters and return values. Nothing an agent needs to select or correctly invoke this tool is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the against enum, SIC code formats, and quarter ranges. The description's only added semantic is the default comparison window and the caveat that the SIC code choice can change the answer, which is a useful but modest contribution over structured data.

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

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

The opening sentence states a specific analytical question with explicit verb+resource: it compares one industry's growth in one area against Great Britain. It also names what it is not (a ranking, or a two-area comparison), so an agent can distinguish it from rank_areas_against_great_britain and compare_two_areas immediately.

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?

Explicit routing rules are given: if the area came from rank_areas_against_great_britain, quote the ranking's verdict instead, and to compare two areas use compare_two_areas. It also discloses the default baseline (latest four quarters vs. same quarters a year before) and the alternative baseline, so the agent knows the selection conditions rather than inferring 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description appropriately spends its words on substance: the default period (latest four quarters), the two statistical tests, the rounding tolerance, and the exclusion of formation-agent addresses. These are non-obvious behavioral facts an agent could not get from the schema, though the response shape is also partially restated despite an output schema being present.

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 purpose is front-loaded in the first clause and the remaining content is dense but earned, covering periods, tests, and the formation-agent exclusion. The middle sentence is convoluted ('that is, one grew faster, or fell less if it fell') and could be tightened, but there is no filler.

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

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

For a seven-parameter read-only comparison tool with a full output schema and 100% schema coverage, the description supplies everything an agent needs to call it correctly: what is compared, the default and alternative baselines, the tests performed, and the population exclusion. Nothing material is left unstated.

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%, including detailed text for 'against', 'sic_codes', 'include_closed', and the quarter bounds, so the schema already carries parameter meaning. The description adds only the period default ('default the latest four quarters'), which largely duplicates what the schema states, so the baseline 3 applies.

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

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

The opening sentence gives a specific verb and resource ('Head to head: which of two places has more new companies in this industry, and which grew faster'), making the two-area comparison unambiguous. It does not, however, explicitly distinguish itself from the sibling compare_area_with_great_britain or rank_areas_against_great_britain, so the reader must infer the distinction from 'two places'.

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?

Usage is implied by the head-to-head framing: this is the tool for comparing two specific areas on new-company formation. There is no explicit statement of when to prefer it over compare_area_with_great_britain or rank_areas_against_great_britain, and no prerequisites (such as needing codes from find_area/find_sic) are stated in the description itself.

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 mark this as a safe read of a closed dataset, so the bar is lower. The description still adds real behavioral context: the snapshot nature, that live includes non-trading companies, that results are split into pre-2021 and since, and that formation-agent postcodes are excluded from area answers. That is meaningful methodology an agent would otherwise get wrong.

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 tight sentences, front-loaded with the question it answers, then scope, then the live definition, then the caveat. There is little waste, although the row-split sentence partly duplicates what the output schema already conveys.

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 an output schema present, the description need not explain return values, and the key semantic risks (what 'live' means, registration-year split, formation-agent postcodes) are covered. The remaining gap is routing guidance against the many sibling counting and comparison tools.

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

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

Schema coverage is 100%, so both parameters are already documented in detail, including SIC code formats and bundles. The description only restates that codes must be primary SIC codes and that area responses exclude formation-agent postcodes; it adds no new parameter mechanics, so baseline 3 applies.

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 gives a specific verb and resource: count companies (private limited, PLC, LLP) with given primary SIC codes that are live, in a named area. It also defines 'live' (not dissolved, even if not trading) and the year split, so an agent can tell this is a point-in-time count rather than a time-series or ranking. It does not name or differentiate from siblings such as count_incorporations_still_live, which keeps it from a 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?

'How crowded is it?' frames the intended question, and the note about formation-agent postcodes explains a scope quirk. But there is no explicit when-to-use/when-not guidance and no pointer to alternatives like count_incorporations_still_live or compare_two_areas for the same SIC codes, so the choice is only implied.

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 openWorldHint=false, so safety is covered; the description adds genuine context beyond that — results are snapshot-based, include_closed changes which population is counted, and area breakdowns exclude formation-agent postcodes. The uncovered piece is whether the snapshot date is fixed or caller-controlled.

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?

Front-loads the verb and resource, and every clause carries information, but the single heavily nested sentence with an inline parenthetical is hard to parse. The trailing fragment 'Area answers leave out formation-agent postcodes' reads as an afterthought rather than a structured caveat.

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

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

An output schema exists and annotations cover the safety profile, so return-value detail is rightly omitted. Still, with six parameters and a group_by option that is undocumented everywhere, plus no guidance on which sibling answers the adjacent question, an agent has to guess at the margin.

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 83%, so the baseline is 3. The description's include_closed explanation largely restates the schema field, and the area caveat adds only marginal meaning; the undocumented group_by parameter gets no explanation in either the schema or 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?

States a specific verb and resource ('Count companies ... registered in the period with these primary SIC codes'), and pins down entity types (private limited, PLC, LLP) and the liveness condition. It implicitly separates itself from count_companies_live_now and registrations_against_closures via the 'still live in the snapshot' framing, but never names those siblings directly.

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?

Gives one explicit conditional: use include_closed 'to compare periods fairly', and warns that area answers omit formation-agent postcodes. However, it never says when to pick this over count_companies_live_now, registrations_against_closures, or one_year_survival, which is exactly the confusion a sibling set this dense creates.

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

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

The annotations only declare readOnlyHint and openWorldHint=false, so the description carries the real behavioral burden and does so well: it discloses match semantics, result ordering (regions/nations before districts), the London disambiguation rule, and explicit coverage gaps for counties and Northern Ireland. It stops short of stating case sensitivity, result-set limits, or whether zero matches is an error, which is why it is not a 5.

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 sentences, front-loaded with the core match rule, then precedence, then caveats; nothing is filler. The London parenthetical is longer than strictly necessary but it disambiguates a genuinely confusing naming case, so it earns most of its space.

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

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

An output schema exists, so return-value detail is correctly omitted, and the remaining complexity (name ambiguity, hierarchical precedence, regional coverage gaps) is addressed. The one omission that matters for a resolution tool is whether the returned names/identifiers are what the sibling analysis tools expect as input, plus how an empty result should be read.

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

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

Schema description coverage is 0% for the single 'text' parameter, so the description must compensate and largely does: 'matching from the start of any word' defines how the free-text value is interpreted, and the examples clarify that a broader name yields multiple areas. It does not state case handling or whether the value must be a place name specifically, leaving a small gap given the full reliance on prose.

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 gives a specific verb and resource ('Find areas by name') and spells out the match rule (start-of-word), which alone tells an agent this is the name-resolution tool rather than one of the analytical siblings. It never names a sibling or states the relationship ('use this to resolve a name before compare_two_areas'), so the differentiation is implicit from the verb rather than explicit.

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?

Usage is implied by the matching and coverage rules — a caller learns that counties are not valid areas and that Northern Ireland has no breakdown, which functions as a 'when not to expect results' signal. There is no explicit statement of when to call this versus the other area-taking tools, nor what to do when the lookup returns nothing.

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 a read-only, closed-world lookup, and the description still adds real behavioral detail: bundles are approximate code sets with stated inclusions and misses, word matching is whole-word only, results are capped at 15 and sorted by code rather than relevance. The one gap is that the 'pass a bundle's id in sic_codes' step cannot actually be executed against this one-parameter schema, leaving the agents' next call unclear.

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 opening sentence is properly front-loaded and the workflow ordering is preserved, but the rest is a dense run-on that mixes lookup instructions, output-reading instructions, and answer-formatting advice with no separation. The final 'Name the codes you used in your answer' is useful but reads as output policy rather than tool documentation.

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

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

An output schema exists, so return values need not be explained, yet the description insists on describing bundles, ordering, and caps while omitting the one thing that matters more: how to actually invoke the bundle path given there is no sic_codes parameter. The mismatch between the described two-stage workflow and the single 'text' input leaves an agent likely to attempt an invalid call.

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

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

Schema description coverage is 0% for the single 'text' parameter, so the description has to carry it, and it partly does by giving examples of acceptable input ('AI, coffee shop, barber, e-commerce'). But it never states the length constraints and spends its parameter-related wording on 'sic_codes', which is not a parameter of this tool, creating a semantics mismatch with 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 first sentence gives a specific verb and resource: 'Find SIC 2007 codes for an industry', which an agent can act on immediately. It does not differentiate itself from related siblings such as breakdown_by_industry or largest_industries, so the agent must infer the boundary itself.

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

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

It does give workflow guidance: query everyday words first, treat returned bundles as approximate, drill into codes, then 3-digit groups, and pass a group code for broad industries like 'cleaning'. However, no guidance is given on when this tool should be preferred over the many industry-counting siblings, and the workflow references a 'sic_codes' parameter that does not exist in this schema.

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 establish this as a safe, non-open-world read, so the description's job is to add domain behavior — and it does: the default window is the latest four quarters, formation-agent addresses are excluded to avoid registered-office artifacts, and results carry a likely range and rank rather than point counts. It does not discuss how ties or boundary cases in the range/rank are handled, which keeps it short of a 5.

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 tight sentences: what it returns, the default period and unit of comparison, then the explicit exclusion and the growth-tool redirect. The leading question frames the use case efficiently and nothing is redundant.

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

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

For a six-parameter aggregation tool with an output schema, the description covers the key interpretive facts an agent needs: default period, ordering, output shape (range and rank), the formation-agent exclusion, and the size-vs-growth distinction. The remaining detail (levels, limits, closed-company counting) is delegated to a well-described schema, which is reasonable.

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 83%, so parameters are already well documented — notably sic_codes, whose schema text carries the format rules, examples and bundling guidance. The description only reinforces 'with these codes' and the default four-quarter period, adding little meaning beyond the schema. Baseline 3 is appropriate here.

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

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

States a specific operation on a specific resource: the council areas/regions/nations of Great Britain with the most companies registered under given SIC codes in a period, ordered largest first, returning a likely range and rank. It also explicitly separates itself from a sibling ('Size, not growth'), so an agent can tell it apart from rank_areas_against_great_britain without opening either schema.

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?

Gives a clear use condition (measuring size/concentration, not growth) and names the alternative to use for growth questions. It also states the default period, which matters for interpreting results. It does not address other plausible siblings such as compare_two_areas or compare_area_with_great_britain, so routing is good but not exhaustive.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds behavior beyond that: the default four-quarter window, the size-not-growth framing, and the note that area answers omit formation-agent addresses. Return format is left to the output schema, which is acceptable, so this falls just short of the top mark.

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?

Dense and largely front-loaded, moving from the question to the resource, the defaults, and the sibling routing in three sentences. The opening rhetorical question is a small framing cost, but the remaining wording all carries information.

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

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

For a question-shaped aggregation tool with five parameters, full schema coverage, annotations, and an output schema, the description covers scope, default period, exclusions, and the alternative tool. Nothing essential to correct invocation is missing, though pagination or limit behavior is only implied by the 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%, so every parameter is already documented, including the area format and the from_quarter/to_quarter defaults. The description's period default ('the latest four quarters') restates what the schema says rather than adding new semantics, so the baseline 3 applies.

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

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

States a specific verb+resource: the 2-digit SIC industry divisions with the most companies registered in a place over a period, returned largest first with a likely range and rank. It explicitly distinguishes itself from breakdown_by_industry on the size-vs-growth axis, so an agent can separate it from the closest sibling without reading either schema.

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?

Names the alternative and the condition that selects it: 'Size, not growth: for what is growing, use breakdown_by_industry.' It also states the default period and the caveat that area answers exclude formation-agent addresses, so the agent knows what question this tool answers and what it does not.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: a significance test against the rest of Great Britain for single areas, a raised bar when testing hundreds of areas for 'UK', and the rule that only quarters with a full year of exposure are permitted. It omits any mention of result shape or how many rows the limit truncates, but with an output schema present that 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?

Three sentences, purpose front-loaded, then the two output modes, then the temporal eligibility constraint. Every sentence carries information and there is no filler, though the phrasing ('the bar is raised for testing hundreds of areas') is parenthetical and slightly compressed.

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 five-parameter analytical tool with annotations and an output schema, the description covers the metric definition, both modes, the significance-testing behavior, and the quarter-eligibility rule. The one visible hole is the 'limit' parameter, which neither schema nor description explains — likely the cap on council areas listed for 'UK'.

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 80%, so most parameters are already documented, and the description partly repeats that (area modes, SIC bundle ids). It does add meaning beyond the schema: the constraint that only quarters whose companies have completed a full year are allowed, which governs from_quarter/to_quarter selection, plus the caveat that SIC choice can change the answer and should be reported. The 'limit' parameter remains unexplained in both schema and 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 states a precise metric — the share of companies registered in a period with given SIC codes that were not dissolved within a year — which is a specific verb-free but unambiguous resource definition. It is clearly a survival-rate tool rather than a raw count, distinguishing it from count_incorporations_still_live or registrations_against_closures. It never names a sibling, so it stops short of a 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 explains the two operating modes (single area vs 'UK') and the eligibility rule for quarters, which is genuine usage context. However, it gives no explicit when-to-use/when-not guidance relative to siblings like compare_area_with_great_britain or registrations_against_closures, and no prerequisites are stated. Usage is implied by the mode descriptions rather than prescribed.

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

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

Beyond the read-only annotation, the description discloses the statistical testing burden, the raised significance bar for testing many areas, the minimum-count threshold, and that only standout areas are returned strongest first. It also explains why dissolved companies are counted, preventing closure-driven false hotspots in older periods.

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

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

The description is dense but front-loads the core question and follows with the testing caveats needed to interpret results. It is somewhat long as a single paragraph, but most sentences carry necessary nuance for a statistical ranking tool.

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

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

Given output schema exists, the description correctly focuses on interpretation: testing, thresholds, inclusion of dissolved companies, ordering, and the key limitation that a missing area may still have grown quickly on weaker evidence. It also names the sibling tool for a single-area comparison, making the definition complete for this complexity level.

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

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

Schema coverage is 71%, with against, sic_codes, to_quarter, from_quarter, and include_closed already documented in the schema. The description adds the latest-four-quarters default and points to against, but it does not add meaningful interpretation for parameters such as limit or direction beyond what the schema provides.

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

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

The description states a specific analytical operation: ranking council areas by how much an industry's share of Great Britain's new companies rose or fell versus an earlier period. It clearly frames the output as evidence-ranked hotspots, and explicitly distinguishes itself from compare_area_with_great_britain for single-area checks.

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

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

It explains the default comparison period, notes that every area is tested, and warns that only standout areas are listed so absence is not proof of slower growth. It directly routes the agent to compare_area_with_great_britain when checking one named area, giving a clear alternative for a different task.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the real burden and does so well: it discloses the rounding tolerance in the verdict, the weekly batching that blocks sub-year verdicts, and that area answers omit formation-agent addresses. These are exactly the caveats an agent needs to interpret results honestly; only the omission of any note on what the comparison returns structurally keeps it at 4.

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 compact sentences, front-loaded with the core comparison and followed by scope, limits and caveats in priority order. The leading rhetorical question costs a few words but does orient the reader quickly; nothing else is padded.

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 an output schema present the description does not need to explain return values, and it covers scope, defaults, verdict behavior and area caveats. It does not tell the agent what to do when the question requires a sub-year verdict or a trend, which is the one informational gap for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents area, sic_codes, from_quarter and to_quarter with defaults and formats. The description restates the defaults and adds no syntax or edge-case meaning beyond the schema, so the baseline 3 applies.

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

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

The opening question is rhetorical framing, but the body states a concrete operation: compares companies registered against companies dissolved in a given area and period and tests which was higher. That is a specific verb pair plus resource that separates it from siblings like count_incorporations_still_live or breakdown_by_industry, though the agent has to read past the question to get there.

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?

Gives clear operating conditions: defaults to UK and the latest four quarters, sub-year periods return counts with no verdict, and the counts cannot show whether closures are accelerating. It does not name a sibling alternative for the cases it refuses (e.g. where to go for acceleration or sub-year verdicts), which keeps it short of a 5.

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