katalis

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: it discloses that PDF-filed accounts cannot be read, that credits are refunded in that case, and that only certain fields are returned 'where the accounts include them'.

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 a clear purpose sentence, and every sentence earns its place by enumerating return fields or noting limitations. The middle portion is a dense, run-on list of fields that could be more structured, but given the absence of an output schema, the detail is justified.

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

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

With no output schema, the description must convey return values, which it does exhaustively by listing financial line items, metadata, and what may be omitted. It also covers the key limitation about PDF filings and credit refunds. Together with the schema and annotations, an agent has everything needed to invoke the tool correctly.

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

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

Schema description coverage is 100%, with the single 'company' parameter documented as 'A company number or name.' The description adds no additional meaning about this parameter, so the baseline score of 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 verb and resource: reading the company's latest filed accounts into plain figures. It clearly distinguishes this tool from general company search or other financial tools by naming the exact data source (iXBRL accounts document). However, it does not explicitly name a sibling tool or contrast its scope, which would be needed for 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 implies when to use the tool (to retrieve filed financial accounts) and includes a when-not condition: 'Accounts filed as a PDF can't be read and the call's credits go back.' It does not, however, suggest alternatives such as company_search or explain when this tool should be preferred over other 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description goes well beyond them: it explains the match key, that a company number resolves registered and former names, that postcode district is checked against the registered office, what statuses appear, and two important limits ('absence never means unsupervised', 'People never loaded'). That is substantive behavioral context an agent cannot infer from the schema or 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 dense sentences, front-loaded with the core purpose and no filler. The middle sentences are slightly run-on and stack match logic with return-format details, but every clause carries information the agent needs.

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

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

With no output schema, the description does the heavy lifting and covers return content, statuses, match semantics, and key limitations. It stops short of noting result-size behavior or pagination for the 'every change recorded' list, which for a possibly large change history would be worth one more clause.

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 the baseline is 3, but the description adds real meaning beyond the terse schema text: it clarifies that matching is on the name as the register writes it and that passing a company number pulls in registered and former names. The postcode-district check is also explained. This is beyond the schema, though not exhaustive on fuzzy-match fallback behavior.

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 names a specific verb+resource (checking whether a business is on HMRC's Money Laundering Regulations supervised register), and even states what it returns: sector, status, and since when. An agent can distinguish this from siblings like sra_check, cqc_check, or charity_check because the regulator and register are 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?

It frames interpretation ('HMRC is one supervisor among several, so absence never means unsupervised') which is genuinely useful for when to trust a negative result, but it never names an alternative sibling or states a selection condition against the other regulator-check tools. Usage is implied rather than guided.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. Beyond that the description adds real behavioural context: the upstream source, that individuals are never named among lenders, that both fixed and floating charges are covered, and that a total/outstanding split is returned. It omits pagination, rate limits, and behaviour for companies with no charges.

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, purpose front-loaded before the field enumeration, with no filler. The second sentence is a dense list but each item carries distinct information about the returned data.

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

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

With no output schema, the description carries the return-value burden and does so reasonably: totals, outstanding amounts, lenders, security type (fixed/floating), what is charged over, and latest creation date. Gaps are minor (shape of the response, empty-result behaviour) given the single-parameter, read-only nature of 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?

Only one parameter (company), and schema description coverage is 100% ('A company number or name'), so the schema fully documents it. The description adds no format or disambiguation detail beyond implying the company identifies the charges; 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 clear verb+resource ('a company's registered charges') and names the data source (Companies House register of charges), so the agent knows exactly what entity is being retrieved. It doesn't differentiate from nearest siblings such as registers or public_record, but the subject matter is unambiguous.

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?

There is no explicit when-to-use, when-not-to-use, or alternative tool guidance; the use case (assessing secured borrowing) is only inferable from the field list. An agent gets no help deciding between this and registers or public_record.

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 declare readOnly/idempotent/openWorld, but the description adds real substance beyond them: it discloses the register source, the 'up to three matches, registered first' cap on name search, that trustees are counted but never named, and the England-and-Wales-only scope. It does not discuss rate limits or response shape, but for a read lookup this is solid extra 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 opening question-led framing is front-loaded and effective, but the middle is a dense comma-spliced list of attributes that is harder to scan than it needs to be. The trailing licensing sentence is legally necessary but adds bulk.

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 read tool with no output schema, the description enumerates what the agent can expect back (status, dates, flags, six years of accounts, governance) and sets jurisdiction limits. It does not explain the response format, but as a lookup it tells the agent enough to call and interpret it correctly.

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

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

Schema coverage is 100% and the schema already documents the single parameter's three accepted forms, so baseline is 3. The description goes further by explaining that company-number matching is done via the Companies House number held on the register, and that group members use a hyphenated charity number — meaning beyond the raw 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?

States a specific triple question (registered? in good standing? what do accounts say?) against a named authoritative source, the Charity Commission for England and Wales. It clearly distinguishes itself from compliance-lookup siblings like cqc_check and sra_check by naming the exact register and jurisdiction.

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 tells you three lookup modes (charity number, company number via Companies House, name with up to three matches), which implies when each is usable. But it never states when to prefer this tool over siblings such as accounts, registers, or distress_signals, nor any exclusion criteria.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description nonetheless adds real behavioral context: results are 'cleaned and confidence-ranked' and the data scope is restricted to company-level records, never officer personal data. It omits auth/rate-limit behavior and does not explain what the ranking signal means.

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 short sentences, front-loaded with the core action and immediately followed by the most valuable constraints (source, ranking, data scope). No filler or redundant restatement of the title.

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

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

With no output schema, the description carries the burden of explaining returns, yet it only gestures at 'confidence-ranked' without describing result fields or pagination beyond the limit param. Combined with the undocumented q parameter, the definition is serviceable but leaves real gaps for an agent to guess at.

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 only 50% and the required parameter q has an empty schema description. The description says nothing about what q should contain (company name, registration number, fuzzy matching?) or how limit interacts with ranking, so the most important input is effectively undocumented in both places.

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 ('Search UK registered companies') and scopes the domain to Companies House company-level data, explicitly excluding officer personal data. It does not, however, distinguish itself from company-adjacent siblings such as public_record, ownership, or charges, so an agent cannot route between them from the text alone.

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?

There is no when-to-use guidance and no named alternative. The description never says when this search should be preferred over siblings like public_record or charity_check, nor any preconditions, so the agent must infer usage from the name 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?

Annotations already declare read-only, idempotent, open-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the data sources, the fallback matching logic (company number first, exact registered name otherwise), and a preview of returned content (count, notified value, top buyers, latest awards) in the absence of an output schema.

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 dense sentences with the resource and scope front-loaded, followed by sources, return contents, and matching rule. No filler, though the second sentence is slightly packed with three distinct facts.

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

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

With no output schema, the description usefully summarizes what comes back, and annotations cover the safety profile, so the core is complete. Remaining gaps are the undocumented 'months' parameter and any default time window or result-count 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 coverage is 50%: 'company' is documented and the description usefully extends it with the number-vs-exact-name matching rule. However, 'months' has an empty schema description and is never mentioned in the description, leaving the time-window control entirely unexplained to the agent.

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 resource and scope ('Public-sector contracts a UK company has been awarded') and names the underlying data sources (Contracts Finder, Find a Tender award notices). An agent can tell this apart from generic siblings like company_search or public_record, though no sibling is named explicitly to sharpen the boundary.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives among the ~19 sibling tools. The matching rule ('by company number where a notice gives one, else by exact registered name') is a behavioral detail, not usage guidance, so the agent must infer the appropriate 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 establish read-only, idempotent, open-world, non-destructive semantics, and the description adds substantial context beyond them: the hybrid cached-register/live-CQC read path, the cap of twelve registered locations, the exact fields surfaced (ratings, five key questions, inspection and report dates), and a full change history since 2 October 2026. This is unusually rich behavioral disclosure.

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

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

The core question is front-loaded in the first clause and every subsequent sentence carries new information rather than repeating the name or title. It is dense and semicolon-heavy, which hurts scannability slightly, but nothing meaningful 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 only one parameter, no output schema, and no nested objects, the description carries the burden of explaining returns and does so thoroughly: registration status with dates, provider type, location inventory with ratings and inspection dates, and change history. An agent has everything needed to call it and interpret results.

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 the baseline would be 3, but the description adds genuine meaning: it reveals the matching precedence (the CQC's own Companies House number first, then registered and former names, then a CQC provider or location id) and that the register is read live after matching. That is more than the schema's flat list of accepted input kinds.

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 names a precise question set (CQC registration, ratings, rating changes) over a specific resource, and the rest of the paragraph makes clear it is a care-provider register check, readily distinguished from siblings like sra_check, charity_check and aml_register. No ambiguity about what the tool returns.

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 clearly implied and bounded: 'England only. Organisations and services only, never people.' Those are real exclusions that steer an agent away from misuse. What is missing is any explicit statement of when to prefer this over sibling register tools, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral detail beyond that: sort order (overdue first), derivation rules for identity verification ('earliest among those not yet showing as verified'), the name-matching basis for the ICO fee register entry, and the presence of a calendar feed URL in the reply.

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 core promise ('Every deadline a UK company has, sorted, with days left') and then dense enumeration; nearly every clause earns its place by naming a deadline source. The single long sentence is heavy but not 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?

There is no output schema, so the description must carry the return contract, and it does: it enumerates the included deadline types, notes overdue-first ordering and the calendar feed URL. It stops short of describing the response shape, handling of companies with no deadlines, or behavior when a name matches multiple companies.

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

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

Only one parameter and schema description coverage is 100% ('A company number, or a name'), so the schema already carries the semantics. The description adds nothing about the parameter itself — it does not restate that a name or number is accepted, nor address how ambiguous names are resolved. Baseline 3 for a single fully documented parameter.

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

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

States a specific resource (every deadline a UK company has) with scope and ordering, then enumerates exactly which deadline classes are covered: accounts, confirmation statement, director/PSC identity verification, ICO fee, payment practices and gender pay gap. This lets an agent distinguish it from siblings like gender_pay_gap or payment_practices, which it implicitly aggregates.

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 rather than stated: it is clearly the tool for a consolidated deadline view of one company. There is no explicit when-to-use guidance relative to the sibling report tools (e.g., whether to call this or gender_pay_gap/payment_practices for a single report), and no exclusions or prerequisites noted.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful behavior: findings are graded serious/watch/info, each carries a date, plus a one-line summary. With no output schema, disclosing this return shape is valuable. It does not state whether results are time-bounded or how many signals are returned.

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?

A single, front-loaded sentence pair that names the purpose first and then enumerates the signals. No filler or repetition. The trailing 'Matched by company number only' is terse but earns its place as an input constraint.

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

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

With no output schema, the description carries the burden of explaining returns and does so adequately: signal categories, severity grades, dates, and a one-line summary. Combined with annotations covering safety and open-world behavior, an agent has enough to call the tool correctly. Missing detail on the grading rubric and result window keeps it from a 5.

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% for the single `company` parameter, so the schema already documents it (number or name, name resolved). The description's 'Matched by company number only' adds a matching-key nuance, but it sits in mild tension with the schema's allowance of a name input and could confuse an agent about accepted formats. Baseline 3 applies 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 states a specific verb and resource ('what the register shows about a company's health') and enumerates the exact signals returned: status, strike-off proposals, insolvency cases, overdue filings, charges, directors leaving. An agent immediately understands the scope. It stops short of differentiating itself from overlapping siblings like `charges`, `deadlines`, and `late_payment`, which cover some of the same ground.

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 use case (assessing company health/distress) is clearly implied by the content and the serious/watch/info grading. However there is no explicit when-to-use, no exclusion, and no routing to the siblings that overlap it, notably `charges` and `deadlines` which appear to cover portions of this data individually.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds what the result contains, but says nothing about the reporting-year coverage, the 250+ employee statutory threshold, or behaviour for non-reporting employers.

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, no filler, with the load-bearing statement of what is returned front-loaded after the scope clause. Every clause earns its place.

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

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

With no output schema, the description usefully enumerates the returned metrics, which is the main missing piece an agent would need. It stops short of covering reporting-year scope, coverage limits and failure modes for employers without a published report.

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

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

Only one parameter, and schema description coverage is 100% ('A company number or employer name'), so the schema already carries the semantics. The description adds no disambiguation between the number and name forms or their format expectations, 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?

States a specific verb (read and benchmarked) and resource (an employer's gender pay gap reports), and enumerates the distinct output facets - median/mean gaps, bonus gaps, pay quarters, YoY trend, rank. Among siblings such as public_record, company_search and payment_practices, no other tool covers statutory gender pay gap reporting, so it is clearly distinguishable.

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?

There is no when-to-use or when-not-to-use guidance and no named alternative. It does not tell the agent whether to resolve an employer first via company_search or what happens for an employer that has never filed a report.

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 readOnly/idempotent/openWorld, so the bar is lower, and the description adds genuine behavioral context beyond them: the external Bank Rate dependency read daily (explaining the open-world flag), simple day-count interest from the day after due, the default of today when 'paid' is omitted, and size-banded fixed compensation. It stops short of describing the returned figure breakdown.

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?

Purpose is front-loaded in the first clause, and the dense legal/arithmetic detail that follows is largely load-bearing for a calculator of this kind. The long parenthetical rate clause is heavy but reordering it would lose precision.

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

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

With no output schema but a fully covered input schema and rich annotations, the description supplies the calculation method, the edge case (unpaid, defaults to today), and the external data source. It could state the shape of the computed figures, but nothing needed to invoke it correctly 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it clarifies that interest accrues from the day after the due date to the paid date, that omitting 'paid' resolves to today, and that the fixed compensation is banded by the invoice's size (tying back to 'amount'). This is more than the schema restates.

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 names a concrete verb and resource ('statutory interest and fixed compensation on a late business invoice') and grounds it in a specific statute, so it is unambiguously distinguishable from every sibling (none of which computes late-payment interest). An agent knows exactly what this tool produces before opening the 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?

Scope is implicitly constrained to commercial/business invoices by the Act citation, which quietly excludes consumer debts, but the description never states when to reach for this tool versus siblings such as will_they_pay or payment_practices. Usage must be inferred from the domain rather than 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 already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a five-level depth cap, explicit termination states (foreign parent, listed company, PSC statement), insolvency flags, 'trouble above', and the privacy rule that individuals are counted but never named.

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?

Purpose is front-loaded in the first clause, followed by progressively finer detail about the walk, the per-company fields, and the stopping conditions. It is dense and slightly run-on, but essentially every clause carries information an agent or upstream model would want.

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

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

With no output schema, the description must describe return content, and it does: per-company name, number, status, insolvency flag, holdings, plus the register's endpoint and any adverse signals. Depth limit and privacy handling are also stated. Only minor gaps remain, such as what happens for non-UK or unresolvable inputs.

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?

There is a single parameter with 100% schema description coverage ('A company number or name'), so the schema already carries the semantics. The description never mentions the parameter or clarifies accepted formats (e.g. number vs name resolution behavior), so it adds nothing here — 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 scope: the people-with-significant-control chain followed company-by-company up to five levels, with the termination conditions spelled out. This is clear and unambiguous. It does not, however, name or contrast itself with the nearby siblings (registers, company_search, public_record), so an 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?

Usage is only implied: the description makes it obvious this is for tracing control upward through corporate controllers, and the five-level cap plus termination conditions hint at scope limits. There is no explicit when-to-use guidance and no named alternative for raw register data (e.g. registers) or basic lookups (company_search).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered structurally. The description adds meaningful context beyond that: the statutory source and licence, the 1-credit cost, and the fact that a name input also returns otherMatches (possible duplicate reporting companies).

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 sentence, with the returned fields and cost following compactly. The em-dash field list is dense but informative; 'a plain reading for suppliers' is slightly vague phrasing but does signal an interpretive summary field.

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

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

With no output schema, the description usefully enumerates what comes back: average days to pay, share paid late, terms, trend, benchmark, plain reading, and otherMatches. That is enough for an agent to call it correctly; minor gaps are error behavior for companies with no reports and pagination/limits, which are unlikely to matter for a per-company lookup.

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 company parameter, so the baseline is 3. The description goes beyond it by clarifying the behavioral difference between passing a number versus a name, since a name triggers the additional otherMatches result.

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-like outcome and resource: how fast a large UK company pays its suppliers, sourced from statutory Payment Practices reports. It clearly distinguishes itself from generic company-data siblings, though it does not explicitly differentiate from the overlapping late_payment and will_they_pay 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?

Usage is implied by the content summary — you call it when you need supplier payment-speed data for a UK company with filed reports. There is no explicit when-to-use framing, no mention of when it is inappropriate, and no named alternative among the many payment-related 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?

Annotations already declare this a read-only, idempotent, non-destructive, open-world lookup, so the safety profile is covered. The description adds genuine behavioral detail beyond that: it discloses that 'a company that doesn't report is said so' and that Silver 'can't be judged from the report', which tells the agent how missing or non-evaluable cases surface. It stops short of describing the overall return shape.

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?

It is front-loaded with the core purpose, but the opening is a sentence fragment ('A company's statutory payment reports against...') rather than a clear verb phrase, and the tier/test parentheticals make the middle dense. The information earns its place, but the phrasing could be tightened.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it only partially does so by noting non-reporting is flagged and that Silver is unjudgeable. It never describes the actual return structure or fields, which is a real gap for a tool whose output is not otherwise documented.

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?

There is a single required parameter with 100% schema description coverage ('A company number or name'), so the schema already carries the parameter semantics. The description adds nothing about the company argument itself, making the baseline 3 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 makes specific what the tool evaluates: a company's statutory payment reports read against PPN 018's two tests and the Fair Payment Code tier thresholds. It names the concrete evaluation criteria (95% within 60 days, 90% with action plan, 45-day average) so the resource and the operation are both clear. It does not differentiate itself from overlapping siblings like payment_practices or late_payment, 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives. Siblings such as late_payment, payment_practices, and will_they_pay clearly overlap in domain, yet the description never routes the agent between them. Usage is only implied by the topic.

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, openWorldHint=true, so the safety profile is covered. The description adds that it joins multiple sources and surfaces 'the three things most worth knowing first', which is useful read-behavior context, but it says nothing about latency, rate limits, or what happens when a name resolves to multiple companies beyond 'resolved to one company'.

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?

It is a dense but front-loaded enumeration, opening with the core purpose and then listing coverage. Every clause names a real dataset, so little is wasted, though the long trailing list of data categories is close to padding for a single-parameter read.

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 broad aggregate read tool with annotations covering safety and no output schema, the description needs to tell the agent what it will and won't get back. It names the coverage areas but not the shape of the response, so an agent can't tell what 'joined and read' actually returns. Adequate but incomplete.

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

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

Schema coverage is 100% and the single parameter's description already explains number-vs-name resolution. The tool description itself adds nothing about the parameter, but with full schema coverage the baseline of 3 is exceeded slightly because the 'resolved to one company, named in the reply' behavior implies a resolution step the caller should be aware of.

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 a broad 'public record' lookup for a UK company and enumerates the datasets it joins (registry facts, distress signals, director/PSC verification, payment practices, contracts, gender pay gap, Environment Agency registrations, Sanctions List). The verb+resource is clear, but the tool heavily overlaps with many siblings (distress_signals, contracts_won, gender_pay_gap, payment_practices) without stating how it differs from them, keeping it 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?

There is no explicit when-to-use or when-not-to-use guidance. Given 19 siblings that each cover a slice of this tool's outputs, the absence of any routing advice is a real gap — an agent can't tell whether to call this aggregate tool or the targeted 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?

Annotations already declare readOnly, idempotent, non-destructive and open-world behaviour, so the safety profile is covered. The description adds genuine context beyond them: the jurisdictional limit (England only for permits/enforcement) and the critical caveat that a sanctions hit is a lead to confirm, never a finding. No auth, rate-limit or freshness details, but the interpretive caveat is substantive.

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?

A single dense sentence that front-loads the two main data sources before enumerating sub-checks. The parentheticals are justified by content, though the second half is packed with comma-separated clauses. No redundant 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 one-parameter lookup with no output schema, the description is complete enough: it tells the agent what categories of data come back and flags the England geographic limitation plus the sanctions-match caveat. Only the response shape (format/structuring of the results) is left unspecified, which is a minor gap.

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?

There is a single parameter with 100% schema description coverage ('A company number or name'), so the schema already documents it fully. The description adds nothing about accepted formats or ambiguity between number and name input, 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 names the specific data sources (Environment Agency registrations, UK Sanctions List) and enumerates the returned subject matter (waste carrier/broker/dealer status, permits, exemptions, enforcement actions), which cleanly separates it from sibling register checks like cqc_check, sra_check and charity_check. It lacks an explicit action verb, but the resource and scope are unambiguous.

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 only implied — a compliance/due-diligence lookup on a single company — with no statement of when to use this versus siblings such as public_record, company_search or aml_register. It does add one interpretive rule (the sanctions match is a lead to confirm, never a finding), which is useful but not a routing guideline.

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 readOnly, idempotent, non-destructive and open-world semantics, so the safety profile is covered. The description goes well beyond them by disclosing the matching rules (organisation name as the register spells it, company number pulling registered and former names, town cross-checked against the registered office) and the temporal scope of results, including former licences and recorded changes since 6 October 2026. It stops short of stating rate limits or result-size behaviour.

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?

It is a single dense sentence-complex, but the core question (is this organisation on the register, on which routes, at what rating) leads, and the matching and coverage caveats follow. Every clause carries information; slightly dense for the reader but not 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 no output schema, the description carries the burden of describing returns, and it does: current licences, former licences with exit dates, and recorded changes. Combined with the 100%-covered single parameter and the annotation safety profile, an agent has enough to call it correctly, though nothing tells it when another register-check sibling would be the better choice.

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 schema already says 'company number or organisation name', so the baseline is 3. The description earns above baseline by explaining the consequences of each input form: a company number resolves registered and former names, whereas a name must match the register's spelling, and the town is validated against the registered office.

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 verb+resource: checking whether an organisation appears on the register of licensed sponsors (workers), and it adds the dimensions of the result (which routes, what rating). That is specific enough to separate it from other regulatory-check siblings like sra_check, cqc_check or charity_check without opening a 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?

Usage is implied by the register being named, but there is no explicit when-to-use/when-not guidance and no alternative tool is named (e.g. when to prefer company_search or another register check). An agent can infer the purpose but receives no routing 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 read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds substantial context beyond that: the data source and freshness (a daily copy of the SRA register), the matching precedence (Companies House number, then registered/former names, then SRA number), the enumerable outcomes (authorised, authorised with conditions, ceased, revoked, intervened), and the coverage window since 8 October 2026.

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 answerable question is front-loaded, followed by source, matching logic, returned fields and scope limits as compact clauses. It is dense and mostly waste-free, though the enumerations of statuses and returned fields make it longer than strictly necessary for a one-parameter lookup.

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?

There is no output schema, so the description carries the full burden of describing returns, and it does: statuses with dates, kind of firm, work areas, offices and head office, trading and former names, and recorded changes. Combined with the source, freshness and entity scope, an agent has everything needed to call and interpret 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 a single parameter at 100% schema coverage, the baseline is 3, but the description goes further by explaining the resolution order the single string is matched against — register Companies House number first, then registered/former names, then SRA number. That materially changes how an agent should populate the field, which the schema description alone does not convey.

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

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

The description opens with a concrete question it answers — whether a firm is SRA-authorised, what kind, since when, and whether that changed — naming the verb, resource and the register it draws from. An agent can distinguish it at a glance from siblings like cqc_check, charity_check or sponsor_licence, which cover entirely different registers.

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 states clear applicability (law firms regulated by the SRA) and an explicit boundary: 'Firms only, never individuals.' That exclusion is useful routing guidance. It stops short of naming a sibling to use for individuals or other regulated-entity checks, so it is clear context rather than fully prescriptive when/when-not 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 cover readOnly/openWorld/idempotent/destructive, so the safety profile is handled. The description adds useful context beyond that: the data source (statutory Payment Practices reports), the derived nature of the output (computed interest and fixed compensation), and the edge-case behavior that a non-reporting company is explicitly stated. It doesn't mention latency, freshness, or output format details.

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

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

The purpose is front-loaded and information-dense, but the phrasing is run-on and the idea of 'what lateness is worth on your invoice' is stated twice ('what its lateness is worth on your invoice' and 'statutory interest plus fixed compensation its typical lateness is worth on an invoice of your size'). That redundancy and the heavy dash-clause structure cost some efficiency.

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

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

With no output schema, the description carries the job of describing return values, and it does so reasonably: it lists the metrics returned and the derived compensation/interest figures, plus the non-reporting edge case. It is largely complete for a read-only analytical tool, though it could say more about the shape or units of the returned data.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters and the baseline would be 3. The description adds meaning by explaining how the parameters are used — 'typical days to pay against your terms' and 'on an invoice of your size' — clarifying that terms and invoice feed a computation rather than being arbitrary inputs.

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 subject (a company's payment habits from its statutory Payment Practices reports) and enumerates the outputs (typical days to pay, share paid late/past 60 days, trend, statutory interest plus fixed compensation). It's clear what the tool does, but it never differentiates itself from close siblings like 'late_payment' and 'payment_practices', which sound like they may overlap.

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

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

There is no when-to-use or when-not-to-use guidance, and no named alternative among the many siblings (late_payment, payment_practices, distress_signals) that could plausibly cover the same question. The only usage-ish note is the edge case that a non-reporting company is flagged, which is behavioral rather than routing guidance.

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