UK company & compliance data

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: a free daily sample quota and a per-call price ($0.005 USDC via x402), which is exactly the rate-limit/cost disclosure annotations cannot express. It still omits result caps or pagination behavior.

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

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

Two short sentences, zero filler, with the functional scope front-loaded and the cost model following. Nothing could be removed without losing 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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. What is missing is the operational context an agent needs in a crowded sibling set: how filters combine, behavior when no filters are supplied (all params optional), and routing guidance versus the other Companies House search 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 description coverage is 100%, so every one of the six filters is already documented in the schema, and the description merely restates the same facets (name, status, SIC, location, dates). It adds no syntax, combination logic, or default behavior beyond the structured fields, so the baseline 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?

States a specific verb (filter) and resource (companies) plus the filterable facets, which matches the schema exactly. However, it offers no differentiation from close siblings like companies-house__search, dissolved-search, or alphabetical-search, so an agent cannot tell from the description alone why it would pick 'advanced' over them.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of the alternative search tools in the sibling set. The only usage-adjacent information is the pricing/rate-limit note, which describes cost, not selection 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, openWorldHint, idempotent, non-destructive), so the description earns credit for adding non-obvious operational context: a free daily sample allowance followed by $0.003 USDC per call via x402. Cost and rate-limit disclosure is exactly the kind of behavior annotations cannot express; it does not describe result volume or ordering details, keeping 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?

Two short sentences, zero filler, with the core capability front-loaded and the pricing caveat trailing. Every clause carries information an agent can act on.

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 explanation is not required, and annotations cover safety. Purpose, use case, and cost model are all present for a single-parameter tool; the only gap is routing guidance among the many related search 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?

Only one parameter (q) and schema coverage is 100%, so the baseline is 3. The phrase 'around a name' hints that q is matched alphabetically rather than by keyword, but no matching semantics (prefix, exact, fuzzy) are given beyond what the schema label 'Name' already says.

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 access pattern: companies returned in alphabetical order around a supplied name, plus the concrete use case of name-availability checks. It does not name a sibling (e.g. companies-house__search or advanced-search) to disambiguate against the many other Companies House search tools, 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?

'Good for name-availability checks' implies the intended scenario, which is more than nothing. However it gives no when-not-to-use guidance and never mentions the obvious alternatives (keyword search, advanced-search, dissolved-search) that an agent must choose between in this large sibling set.

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). The description adds genuinely non-derivable behavioral context: a free-sample quota followed by $0.008 USDC per call via x402. That pricing/rate-limit disclosure is exactly the kind of value structured fields cannot carry, though nothing is said about result shape or pagination.

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 tightly written sentences: the resource description is front-loaded and the cost/access note follows. No filler, no repetition of the title or schema.

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, annotations carry the safety profile, and the single parameter is fully documented. The description supplies purpose and payment mechanics, leaving only edge-case behavior (e.g., companies with no charges) 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?

Only one parameter and schema description coverage is 100% (the schema already documents the 8-character company number with an example). The description adds no format, validation, or edge-case detail beyond what the schema provides, so the baseline 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?

States a specific resource (mortgages and charges registered against a company) plus the notable payload contents (lenders and status), which is far more informative than the bare tool name. It is clearly distinguishable from siblings like profile or insolvency, though it never explicitly names those alternatives. Clear verb-less but precise noun statement.

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

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

The description implies the use case (looking up secured debt against a company) but offers no explicit when-to-use or when-not-to-use guidance, and never routes the agent away from the many sibling lookup tools. Usage is inferable from the resource statement 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: a free-sample quota and a paid tier at $0.003 USDC per call via x402, which an agent needs for cost/payment planning.

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 tight sentences: what it searches first, cost model second. No filler, nothing 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?

An output schema exists and annotations carry the safety profile, so return values needn't be explained. For a one-param read search, the definition is nearly complete; only result limits/pagination behavior is unaddressed.

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 parameter, so the schema already documents 'q'. The description's 'by name' matches the schema but adds no syntax, matching, or format detail beyond it; 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 (search) and a narrowed resource (dissolved and removed companies), which lets an agent distinguish it from the sibling companies-house__search that handles active companies. It stops short of naming that sibling explicitly, so the differentiation is implied rather than stated.

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 scope ('dissolved and removed') implicitly tells the agent when to reach for this tool over a general company search, but there is no explicit when-to-use/when-not or named alternative. Usage is inferable 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the throttling/pricing model ('A few free samples a day, then $0.002 USDC per call via x402'), which an agent cannot infer from structured fields.

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 with zero filler; the resource is front-loaded and the commercial constraint follows. Nothing can be trimmed without losing 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?

The tool is simple (one required param), an output schema exists so return values need not be described, and annotations cover the safety profile. Purpose plus cost/rate-limit disclosure is nearly sufficient, though a pointer to when this data is relevant (e.g., PSC screening) is absent.

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 (company_number) at 100% schema description coverage, so the schema already carries parameter meaning. The description adds nothing about format or expected value, which matches the baseline 3 for a fully documented schema.

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

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

The description names a specific resource ('PSC disclosure exemptions a company holds'), which is distinguishable from siblings like profile, charges, or insolvency. It is a noun phrase rather than a verb+resource construction and never explicitly frames the operation as a lookup, 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?

There is no statement of when to use this tool versus alternatives such as companies-house__profile or uk-business__due-diligence, and no prerequisites or exclusions. Only the pricing model is given, which is not usage guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: a rate limit ("a few free samples a day") and a per-call cost ($0.003 USDC via x402), which an agent needs to budget calls.

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 resource definition front-loaded ahead of the pricing note. Every clause carries information an agent can act on.

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, and both required parameters are fully documented in the schema. For a simple single-item read tool with full annotation coverage this is close to complete; only the relationship to filing-history is 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 the hint that transaction_id comes from filing history, so the baseline is 3. The description adds nothing about either parameter beyond what the schema already documents.

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 resource ("one filing") and states what comes back ("detail and document link"), so an agent knows this returns a single filing rather than a list. It does not name or explicitly distinguish itself from the obvious sibling companies-house__filing-history, which is the main gap.

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 guidance on when to use this instead of filing-history or any other sibling, and no prerequisite information. The only context offered is commercial (free samples, per-call price), which is not usage guidance.

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

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

Annotations already declare readOnly/idempotent/openWorld/destructive=false, so the safety profile is covered. The description usefully adds a rate limit and a paid-access model (free samples then $0.005 USDC per call via x402), which the annotations do not convey and which materially affects invocation cost.

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 with no wasted words; the content enumeration is front-loaded and the cost note follows. Appropriately sized for a two-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?

With an output schema present, return values need not be explained, and annotations cover safety while the description covers cost. The one gap is the lack of differentiation from the sibling filing tool, which an agent would need to disambiguate the two.

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 (company_number and category) are already documented in the schema, including the category examples. The description adds no further parameter meaning, 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 names the resource concretely by enumerating what is returned (accounts, confirmation statements, appointments, other filings) with a clear sort order ("newest first"), so an agent knows what this tool surfaces. However, it never distinguishes itself from the sibling companies-house__filing, which is a genuine source of confusion given the near-identical scope.

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 only guidance is transactional (free samples, per-call cost); there is no statement of when to pick this over the sibling filing tool or advanced-search. Usage must be inferred entirely from the name and enumerations.

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 safety is covered. The description adds genuinely new behavioral context not present in the annotations: a metered cost model (a few free samples per day, then $0.008 USDC per call via x402), which affects how an agent should budget repeated calls. It stops short of describing throttling or error behavior.

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

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

Two sentences, zero padding, with the resource and scope front-loaded before the pricing note. Every clause carries information and nothing is repeated from 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 an output schema present, the agent needn't be told the return shape, and the annotations cover the safety profile, so the description only needs to cover purpose and cost — both are present. The remaining gap is the absence of any usage framing relative to sibling tools, which is a minor but real omission for a multi-tool lookup server.

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 there is only one parameter, company_number, fully documented in the schema. The description adds only the vague notion that the lookup is 'for a company', no format, validation, or example values. Baseline 3 is appropriate when the schema carries the parameter detail.

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?

Names a specific resource set (insolvency cases, practitioners, key dates) scoped to a company, which is distinct from siblings like charges, filing-history, or profile. The retrieval verb is only implied ('for a company'), but an agent can still tell what data comes back. No explicit sibling routing, which keeps 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?

The description says nothing about when to reach for this tool versus the many sibling lookups (charges, filing-history, profile) or what a company with no insolvency history returns. The only context offered is billing, not usage. An agent must infer the use case entirely from the name.

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, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not carry: a daily free-sample quota followed by per-call x402/USDC payment, which materially affects whether an agent should call it. It does not mention prerequisites such as requiring an 8-char number to resolve or behaviour for unknown numbers.

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 tight sentences with no filler; the returned-field list is front-loaded and the pricing caveat is appended. It could be marginally stronger with an explicit verb, but nothing is wasted.

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, and annotations cover the safety profile. What is missing is routing guidance (this tool vs. the registered-office/charges/filing-history siblings) and any precondition behaviour, leaving the agent to infer the tool's place in the family.

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% and the single parameter's format (8-character company number, example "00445790") is fully documented in the schema. The description adds no additional parameter meaning, 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 enumerates the concrete fields returned (status, type, incorporation date, SIC codes, accounts/confirmation statement due dates, registered office), so the resource is clear. However, it never states the verb ('retrieve/fetch the profile') and does not distinguish itself from overlapping siblings like registered-office, charges, or filing-history, which also surface some of these fields.

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 mention of alternatives such as advanced-search or registered-office. The only usage constraint given is commercial (free samples then $0.005 USDC per call), which is useful but does not tell the agent when this tool is the right choice.

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, openWorld and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context the annotations lack: a metered payment model ('a few free samples a day, then $0.002 USDC per call via x402'), which tells the agent to expect rate/cost constraints.

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

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

Two short sentences with the resource stated first and the pricing condition second; every clause carries information and nothing 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?

For a one-parameter lookup with a full output schema and complete annotations, the description covers what the tool returns and what it costs. The only real gap is the absence of any signal about how it relates to the other companies-house lookups.

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% and the single company_number parameter is fully documented in the schema with a format example. The description adds nothing about the parameter, so baseline 3 is appropriate.

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

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

The description identifies a specific resource ('Current registered office address') tied to a UK Companies House company, which an agent can distinguish from siblings like charges, filing-history or profile. However, it states no verb and never mentions that the lookup is keyed by company number, so it falls short of the 'specific verb + resource' bar 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?

Nothing indicates when this tool should be chosen over siblings such as companies-house__profile or the various search tools. The pricing note is cost information, not usage guidance, so an agent gets no routing help.

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, and openWorldHint, so safety behavior is covered. The description does add genuinely new context — the free-sample allowance and the $0.003 USDC per-call x402 cost — which is behavior an agent cannot infer from structured fields, but it says nothing about result caps, pagination, or empty-result behavior.

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

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

Two short sentences, front-loaded with the core capability and followed by the cost note. Nothing is padded, though separating the pricing sentence from the functional sentence would read slightly cleaner.

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, and the pricing disclosure is a nice addition. However, for a hub-style search tool sitting beside many overlapping search siblings, the absence of any disambiguation guidance leaves a real completeness 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 coverage, so the schema already documents 'q'. The description's 'name or number' merely restates the schema wording without adding format hints (e.g., company-number patterns or fuzzy matching), so the baseline 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?

States a specific verb and resource ('Find UK companies by name or number') and lists returned fields (status, address, incorporation date). It is clear on its own, but with siblings like advanced-search, alphabetical-search, and dissolved-search it never says what distinguishes this general search from them.

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

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

The description gives no when-to-use or when-not-to-use guidance. Given that three sibling tools (advanced-search, alphabetical-search, dissolved-search) plausibly overlap, the agent is left to guess which search variant to pick, and the only 'when' information is billing-related.

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, covering the safety profile. The description does add genuinely new behavioral context not in the structured fields: free daily samples followed by $0.002 USDC per call via x402, which signals a cost/rate-limit boundary. It still says nothing about result shape or limits, so it goes beyond annotations but not far.

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 with no filler, and the pricing constraint is stated cleanly. It is appropriately sized, though the brevity buys conciseness at the cost of substance.

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, and annotations cover safety. However, for a lookup tool the core question — what am I getting back and for which entity type — is never answered by the prose, leaving the definition short of what an agent needs to invoke it confidently.

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 and 100% schema description coverage, the schema already documents company_number as the overseas company number (FC…). The description's phrase 'overseas company' loosely reinforces this but adds no format, validation, or example beyond the schema, so the baseline 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 is a bare noun phrase ('UK branches of an overseas company') that essentially restates the title rather than naming an action. There is no verb indicating whether it lists, retrieves, or resolves establishments, so an agent cannot tell what the call actually does or 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?

No when-to-use guidance and no mention of alternatives, despite many plausible siblings (profile, registered-office, gleif__branches, search). The only guidance offered is billing mechanics, which does not help select the tool.

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 safety is covered. The description adds genuinely new behavioral context the annotations cannot express: a free daily allowance followed by $0.002 USDC per call via x402, which tells the agent to expect a paid/rate-limited surface and to budget calls.

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

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

Two sentences with zero waste: the purpose is front-loaded and the pricing constraint follows. Nothing needs trimming or reordering.

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 no explanation, and the single parameter is fully documented. Pricing and read-only behavior are covered; the only real gap is the missing comparison to overlapping GLEIF search 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?

There is a single parameter ('q', described in-schema as 'Partial name') with 100% schema description coverage, so the baseline is 3. The description adds no syntax, length, or matching-rule detail beyond what the schema already 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 verb and resource: 'Name autocompletion across the LEI index.' An agent can tell this is a typeahead/prefix suggestion tool rather than a general lookup. However, it never names the nearby siblings it overlaps with (gleif__search, gleif__fuzzy), so the boundary is left to inference.

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: nothing says to reach for this while a user is typing a partial name versus calling gleif__search or gleif__fuzzy for a complete query. The only condition stated is economic (free allowance, then per-call price), not functional, so the agent gets no routing help.

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 the safety profile is covered. The description goes beyond that by disclosing the cost model — free within a daily allowance, then $0.003 USDC per call via x402 — which is genuinely useful behavioral context an agent cannot get from structured fields. It stops short of explaining allowance scope or payment failure behavior.

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

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

Two short sentences, purpose first, cost second — front-loaded and free of filler. Both sentences earn their place, though the purpose sentence is minimal, leaving the definition terse rather than information-dense.

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 no explanation, and rich annotations cover the safety semantics; for a one-parameter read tool the burden is light. The remaining gap is sibling disambiguation — the description never distinguishes branches from direct-children/ultimate-parent or explains what a caller gets back conceptually.

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% and there is a single required 'lei' parameter, so the schema fully documents the input. The description adds no format, validation, or sourcing detail (where to obtain an LEI) beyond what the schema already provides, which is the baseline 3 case.

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

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

The description states the resource ('Registered branches of an entity'), which is a meaningful clarification over the bare name 'branches' — it tells the agent this returns branch/establishment records for a legal entity. However, it uses no verb (list/get) and offers no differentiation from adjacent LEI siblings such as gleif__direct-children or gleif__ultimate-parent that also traverse entity structures.

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 only guidance given is commercial ('Free within the daily allowance, then $0.003 USDC per call'), not task-oriented. Nothing says when to call this versus gleif__lookup, gleif__direct-children, or a search tool, and no prerequisites (e.g. needing an LEI already in hand) are stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds a genuinely non-structured behavioral trait: the billing model (free daily allowance, then $0.003 USDC per call via x402), which lets an agent reason about cost. It stops short of stating the response shape, but an output schema exists.

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 with no filler; the functional purpose is front-loaded and the pricing detail is relegated to second position. Sized appropriately for a single-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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. However, the description omits any routing against the many sibling lookup tools and never states the output is an LEI record, leaving the agent to infer the tool's place in the family.

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 one parameter at 100% schema coverage, the baseline is 3, but the schema description is merely 'BIC' while the description clarifies that this means a 'SWIFT/BIC code'. That expansion adds real meaning about the identifier's origin beyond the structured field.

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 mapping task — find which entity holds a given SWIFT/BIC code — which pairs with the title's 'LEI by BIC' to convey verb and resource. It is clear on its own but never explicitly says it returns an LEI, and it does not distinguish itself from close siblings such as gleif__by-isin or gleif__lookup.

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

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

No guidance is given about when to use this tool versus alternatives like gleif__lookup, gleif__by-isin, or gleif__search. The only contextual information is pricing ('free within the daily allowance, then $0.003 USDC per call'), which is cost, not usage routing.

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, openWorldHint, destructiveHint=false), and the description adds genuinely new operational context: a free daily allowance followed by $0.003 USDC per call via x402. That cost/quota disclosure is exactly the kind of behavioral detail annotations cannot express, though auth/payment setup mechanics remain unstated.

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, zero padding, with the core purpose front-loaded before the pricing note. 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 an output schema present, return values need not be explained, and the pricing/allowance note covers a key operational concern. The only real gap is routing relative to the closely-named gleif__isins sibling, which is not addressed.

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 (isin) at 100% schema coverage, so the schema already carries the burden and baseline 3 applies. The description adds no format guidance (e.g. that ISIN is a 12-character alphanumeric code) beyond what the schema's 'ISIN' label 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?

States a specific resolution: ISIN -> issuing entity (LEI), which is a clear verb+resource pairing an agent can act on. It does not, however, distinguish itself from the sibling gleif__isins tool, which an agent could easily confuse with this one.

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 gives pricing context but no when-to-use guidance: nothing says whether to reach for gleif__by-isin versus gleif__isins or gleif__search, and no prerequisites (e.g. valid ISIN required) are stated. Usage is only implied by the one-line purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real information beyond that: the call is free within a daily allowance and then billed at $0.003 USDC per call via x402, which is exactly the kind of metering detail a caller needs before invoking.

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, zero filler: the purpose lead is front-loaded and the pricing caveat follows it. Nothing is repeated from the title or the schema, and every clause 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?

An output schema exists, so the description need not explain return values, and the annotations cover the safety profile. Purpose plus cost model plus those structured fields give an agent what it needs, with only the hierarchy-depth semantics of 'direct' being left implicit.

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 'lei' parameter, so the schema already carries the parameter documentation and the baseline of 3 applies. The description adds no format, validation, or sourcing detail about the LEI argument, so nothing pushes it above baseline.

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 resource ('entities directly owned by this entity'), which is enough for an agent to understand the tool returns the ownership subtree one level below the given LEI. It stops short of explicitly contrasting itself with the semantically adjacent siblings (gleif__direct-parent, gleif__ultimate-parent, gleif__branches), so the 'direct' vs 'ultimate' distinction is left to inference.

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 named alternative. The only usage-relevant signal is the commercial framing, which tells the agent a call is free up to a daily allowance and then metered, but that is cost context rather than selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond the structured fields: the pricing model (free within a daily allowance, then $0.003 USDC per call via x402), which is real operational information an agent cannot get from annotations. It stops short of noting behavior when an entity has no parent.

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 what the tool returns and then the cost model. There is no filler and no sentence that fails to earn 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the missing piece an agent would care about — cost and the x402 payment path. It is only slightly short of complete in not covering the no-parent edge case.

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 exists and schema description coverage is 100%, so the schema already carries the burden; the baseline of 3 applies. The description adds nothing about the lei argument (format, source, validity), and the schema's own description is merely the redundant string 'LEI'.

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 exact resource returned — the direct accounting parent of an entity — which is specific enough to distinguish it in spirit from gleif__ultimate-parent and gleif__direct-children. It does not, however, explicitly contrast itself against those siblings, so an agent must infer the direct-vs-ultimate distinction from the term 'direct' 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 explicit when-to-use guidance and no alternatives named, even though gleif__ultimate-parent is an obvious competing choice for the same question. The only implied guidance is the tool's name and return noun, which leaves the agent to infer the selection rule.

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 and openWorld, so the safety profile is covered. The description adds valuable context beyond that: the cost model (free within daily allowance, then $0.003 USDC per call via x402), which is genuinely useful for an agent deciding whether to call. It does not mention rate-limit thresholds or match-quality behavior.

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

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

Two tight sentences, with the core purpose front-loaded before the pricing detail. Every sentence carries information; the em-dash aside is efficient. Minimal but not wasteful.

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 shape needn't be described. For a single-parameter matching tool with full annotation coverage, the description covers purpose, use case and cost. The only gap is the absence of explicit sibling routing, which is a minor omission.

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 'q' is documented as 'Approximate name'. The description reinforces this with 'fuzzy matches of a name' and 'messy company names', but adds no syntax, length or formatting guidance beyond what the schema already provides. Baseline 3 is appropriate.

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

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

States a specific operation (fuzzy name matching to LEIs) and the resource, with the quantifier 'Best fuzzy matches'. It implicitly contrasts with exact-match siblings like gleif__search and gleif__autocomplete via 'fuzzy' and 'messy company names', but never names a sibling 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?

The phrase 'for messy company names' does give a condition for choosing this over exact-search siblings, which is better than nothing. However it never names an alternative tool or states when NOT to use fuzzy matching (e.g. clean/known names), leaving the routing largely to inference.

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 safety is covered. The description adds genuinely new behavioral context beyond the annotations: a cost model (free within a daily allowance, then $0.003 USDC per call via x402), which matters for call planning. It still doesn't say how an unknown or invalid LEI behaves (empty result vs error) or whether results paginate.

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 with no filler, and the subject (what the tool returns) is front-loaded. The pricing sentence is longer than the functional sentence, but it carries real information rather than padding.

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 explanation is not required, and with one fully documented parameter this is a simple tool. It is close to complete; the only unresolved agent questions are error behavior for an unknown LEI and the mechanics of the x402 payment path.

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 single 'lei' parameter is already documented, and the description implicitly confirms the entity is identified by its LEI. It adds no format, validation, or normalization detail beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description names the resource (ISINs) and the relationship (issued by an entity), so an agent can tell it returns securities identifiers tied to a given entity. It lacks an explicit retrieval verb and does not distinguish itself from siblings such as gleif__by-isin, which performs the inverse ISIN-to-entity lookup.

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

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

No when-to-use guidance is given: nothing says to use this when you have an LEI and need its issued securities, and no alternative is named (gleif__by-isin is the obvious inverse). The only contextual sentence is about pricing, which is not usage guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely new operational context that annotations cannot express: the free daily allowance and the $0.003 USDC per-call charge via x402, which matters for an agent deciding whether to spend a call.

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: the returned fields first, then the cost model. No filler, no restatement of the title, and the most decision-relevant information (what you get, what it costs) is front-loaded.

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

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

An output schema exists, so return structure need not be described, and annotations carry the safety semantics. For a one-parameter identifier lookup the description covers purpose, payload and cost adequately; only the routing against neighbouring GLEIF endpoints 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% — the single 'lei' parameter is fully documented as a 20-character Legal Entity Identifier. The description adds no format detail, truncation rules, or handling for malformed LEIs beyond what the schema already 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 description states exactly what comes back for a single LEI — legal name, addresses, jurisdiction, legal form, status and registration — which is more concrete than a generic 'lookup'. The phrase 'for one LEI' implicitly separates it from query-based siblings like gleif__search, gleif__fuzzy and gleif__autocomplete, though those siblings are never named.

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: taking a single LEI signals an exact-identifier lookup rather than a name search, so an agent can infer it should use search/autocomplete first if it lacks an LEI. No explicit when-to-use, when-not-to-use, or named alternative is given.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, open-world), so the description's value-add is the cost model: free within a daily allowance, then $0.003 USDC per call via x402. That is real behavioral context an agent cannot get from the schema. It stops short of stating rate limits or matching semantics.

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, both front-loaded, with no padding. The opening fragment is slightly under-specified, but nothing is wasted.

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 no explanation, and the one-parameter surface is simple. However, the description omits matching semantics and sibling routing (exact vs fuzzy vs autocomplete), leaving the agent to guess which LEI search tool to pick.

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 'name' parameter is documented as 'Legal name'. The description only restates this, adding no format, casing, or exact-vs-prefix matching detail. Baseline 3 applies with zero parameters beyond the schema.

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

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

The fragment 'Entities whose legal name matches' names the resource and the match dimension, but it is not a complete verb+resource statement and it does not distinguish this tool from gleif__fuzzy or gleif__autocomplete, which also match names. The title carries most of the clarity.

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

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

No when-to-use guidance, no exclusions, and no reference to the obvious alternatives (gleif__fuzzy for approximate matching, gleif__autocomplete for prefix suggestions). Only pricing is 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot express — the cost model (free within the daily allowance, then $0.003 USDC per call via x402) — which materially affects an agent's call strategy.

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 what is returned and followed by the cost condition. No redundant restatement of the title or schema, and every clause 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?

An output schema exists, so return values need not be described, and the description plus annotations cover purpose and cost. The one material gap is the common edge case for parent lookups — what is returned when the entity has no ultimate parent — but for a one-parameter read tool the definition is otherwise complete.

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

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

With a single parameter at 100% schema coverage, the schema already documents 'lei'. The description adds no format guidance (e.g., 20-character LEI syntax, whether the entity must exist in the register), so it neither compensates nor detracts — 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 resource returned — the ultimate accounting parent of an entity — and the adjective 'ultimate' implicitly separates it from the sibling gleif__direct-parent. It is not a verb-led description, but for a read-only lookup the returned relationship is the essential information, so the purpose is clear without naming the sibling 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?

Usage is only implied: an agent must infer that this differs from gleif__direct-parent by the immediacy of the parent (ultimate vs. immediate). No explicit when-to-use, when-not-to-use, or prerequisite (e.g., a valid LEI must already be known) is 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new behavioral context: a free-sample quota followed by per-call metered payment via x402. That is exactly the kind of operational constraint annotations cannot express. Return-shape detail is partly redundant since an output schema exists.

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 compact sentences with no waste. The payload summary is front-loaded and the cost/quota note is relegated to second position, which is the right priority ordering.

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 re-explain return values, and annotations carry the safety profile. Parameters are fully documented in the schema. What is complete enough to call correctly; the only minor gap is that the screen-then-entry workflow remains implicit rather than stated.

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, including the enum-like values for 'list' and the cross-reference hint that list_id/entry_id come from a screen result. The description adds no parameter syntax or format detail 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?

States a specific verb+resource ('Full record for a matched entry') and enumerates exactly what the record returns: aliases, programmes, countries, dates of birth, remarks. This clearly separates it from the search-oriented siblings like sanctions__screen, which return matches rather than full detail.

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 itself gives no explicit when-to-use or when-not-to-use guidance; the drill-down workflow is only implied by the schema notes ('list_id in a screen result'). The only genuine usage framing is the pricing model (free samples then $0.005/call), which is useful but is cost guidance rather than selection guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not: a free-sample quota, per-call pricing of $0.001 USDC via x402, and recency via last sync time.

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 tight sentences: the first front-loads the returned fields, the second covers the cost model. Nothing is redundant, though the first sentence is a bare noun list rather than an explicit action statement.

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 and zero parameters, the description does not need to explain return values or arguments. It covers purpose, freshness and pricing, leaving only explicit sibling routing unstated, which keeps it from being fully complete.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. The absence of parameters is consistent with a metadata/listing call and requires no further explanation.

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 resource (sanctions lists that are mirrored) and enumerates exactly what metadata is returned: entry counts, list dates, last sync time. It clearly reads as a discovery/metadata tool distinct from the screening siblings (screen, screen-uk, entry), though it never explicitly labels itself as such.

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 statement and no sibling is named. However, the content (which lists are mirrored) implies the natural discovery-first usage before running a screen, giving usable but not stated 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, idempotent, openWorld and non-destructive, so the safety profile is settled. The description goes beyond them by disclosing a rate limit ('a few free samples a day') and a per-call price with a payment mechanism (x402), which materially affects whether and how often an agent should call it.

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 with no filler, and the substantive content leads. The first sentence is a verbless fragment, which slightly hurts readability, but nothing is wasted.

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 enumerate return fields — yet it spends its entire first sentence doing exactly that while omitting the core statement of the action. Annotations and schema carry the rest, so it is adequate but leaves the agent without usage routing.

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 six parameters including the list codes, threshold range and corroboration fields. The description only echoes some of these concepts ('score', 'countries', 'dates of birth') as output fields and adds the fact that all lists are searched by default, which is a marginal increment.

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 is a noun phrase about results ('Potential matches across all four lists with score, list, programmes...') rather than a verb+resource statement of what the tool does; the action must be inferred from the title. 'All four lists' weakly distinguishes it from sanctions__screen-uk and sanctions__screen-us, but that contrast is never made 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?

There is no when-to-use guidance at all. The only second sentence concerns pricing ('A few free samples a day, then $0.02 USDC per call via x402'), which is cost information, not routing advice, and the description never says why an agent should pick this over the sibling sanctions__screen-uk or sanctions__screen-us.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the data source (FCDO) and the cost model ('a few free samples a day, then $0.01 USDC per call via x402'), which matters for an agent deciding whether to invoke repeatedly.

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 with zero filler; the scope constraint is front-loaded and the pricing caveat follows. 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 an output schema present, return values need not be explained, and the description covers source list, scope, and cost. It is nearly complete, missing only explicit routing to the sibling screeners for non-UK lists.

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 both 'name' and 'threshold' (default 80) are already documented in the schema, and an output schema exists. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description names the resource and scope precisely — 'Potential matches on the UK Sanctions List only (FCDO)' — and the word 'only' carves it out from the sibling screen/screen-us tools. The screening verb itself is only implied by the name, so it falls just short of a full verb+resource statement, but an agent can still tell it apart from its siblings.

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

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

'UK Sanctions List only' implies the when-to-use condition (UK/FCDO targets) and implicitly rules out the US and generic screeners, but no alternative is named and no explicit 'use X when Y' guidance is given. The pricing note tells the agent it is metered but not when to prefer it over siblings.

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

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

Annotations already declare the safety profile (readOnly=true, idempotent=true, openWorld=true, destructive=false), and the description adds genuinely new behavioral context the annotations lack: a free-sample quota and per-call cost of $0.01 USDC via x402, which is a rate/billing constraint an agent should know before invoking. It doesn't describe scoring behavior or what a match result contains, but the pricing detail is meaningful added value.

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 with no filler, and the core scope ('US OFAC SDN list only') is front-loaded ahead of the secondary pricing note. 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?

An output schema exists, so return values need not be explained, and the description covers scope and cost for a simple two-parameter tool. The main gap is the absence of any guidance on aggregating this with the UK or general screening siblings, but for a low-complexity tool the definition is largely complete.

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

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

Schema description coverage is 100%, so the schema already documents both 'name' and 'threshold' (with its default of 80). The description adds no additional parameter meaning beyond what the schema provides, so the baseline 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 specifies the exact data source: 'Potential matches on the US OFAC SDN list only.' Combined with the title and name, an agent can tell this screens names against the US OFAC list, and the word 'only' distinguishes it from the UK-list sibling sanctions__screen-uk. It stops short of stating the verb/resource explicitly (the title carries that), so 4 rather than 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 phrase 'US OFAC SDN list only' implicitly routes the agent away from sanctions__screen-uk, but the description never explicitly says when to choose this tool over sanctions__screen or the other sanctions siblings. No prerequisites or exclusions are spelled out; the routing is inferred 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 readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavior: the commercial model (free within a daily allowance, then $0.002 USDC per call via x402) and the specific source list (OFAC SDN), which tells the agent the result is authoritative for US sanctions only.

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

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

Two short sentences with the purpose front-loaded and the cost caveat second; no filler. The first sentence is a grammatical fragment ('Whether a crypto address ... is listed'), which is slightly awkward phrasing, but the information density is high.

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 covering return values and annotations covering safety, the description supplies the remaining essentials: what is checked, against which list, which chains are supported, and the pricing model. The one real gap is routing relative to the sibling sanctions screening 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% with a single 'address' parameter, so the baseline is 3. The description does add value by enumerating the supported chains/formats (BTC, ETH/EVM, TRX, USDT and others), but it gives no format syntax or normalization guidance beyond that.

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 (a crypto address) and the exact check performed against the OFAC SDN list, plus the asset families supported (BTC, ETH/EVM, TRX, USDT). It does not, however, differentiate itself from the sibling screening tools (sanctions__screen, sanctions__screen-us, sanctions__entry), so an agent must infer that this one is wallet-only.

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

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

There is no when-to-use guidance and no reference to alternative tools. Nothing tells the agent when to pick wallet-screen over sanctions__screen or sanctions__screen-us, nor whether an address must be pre-normalized. Only pricing, not selection context, is provided.

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 the safety profile is covered. The description adds genuinely new behavioral context not in the structured fields: the $0.08 USDC per-call cost via x402 and the exact breadth of risk dimensions screened. Cost disclosure for a paid endpoint is high-value 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?

Two sentences, front-loaded with the tool's scope before the cost note. The content list is dense but each item is a distinct risk dimension, so it earns its space. Minor density in the enumeration but 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the remaining essentials an agent needs: what sources are screened and the per-call cost. It could be improved by noting it is a composite alternative to the individual sibling lookups, but nothing required for correct invocation 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?

There is a single parameter with 100% schema description coverage, so the schema already documents the 8-character Companies House number format and examples. The description adds no parameter-level meaning beyond the schema, which is the expected baseline for a fully documented single-param tool.

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 composite resource (UK company register profile plus risk flags) and enumerates exactly what it aggregates: status, overdue accounts, insolvency history, Gazette notices, name/office changes, LEI and sanctions screening. An agent can tell this is a multi-source due-diligence rollup rather than a single-source lookup. It does not explicitly contrast itself with the individual sibling tools (profile, insolvency, charges), so it stops short of full sibling differentiation.

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 statement or mention of alternatives. The tool's purpose is implied by the title and content list, but the description never says whether to call this instead of the individual companies-house tools, nor when it is overkill. Guidance is left entirely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context absent from annotations: the metered pricing ('a few free samples a day, then $0.003 USDC per call via x402'), which an agent must know before invoking. It stops short of 5 because it omits rate-limit specifics on the free tier and auth/wallet requirements for x402.

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, zero filler, with the returned resource front-loaded and the pricing caveat trailing. 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?

An output schema exists, so the return-format burden is lifted, and the description covers what is returned plus the payment behavior for a one-param read tool. It is nearly complete, missing only explicit usage routing relative to the other uk-disputes 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% and there is a single parameter ('organisation' = company name), so the schema already does the work. The description's phrase 'for a UK company' confirms the parameter's scope but adds no syntax, format, or ambiguity guidance, 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 specifies the exact resource returned (complaints address, email, phone and URL) and scopes it to a UK company, which lets an agent distinguish it from siblings like uk-disputes__organisations or uk-disputes__energy-complaint. It reads as a data-retrieval tool, but no explicit verb anchors it, 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 never states when to use this over the other uk-disputes tools (organisations, energy-complaint, telecoms-complaint, etc.) or what prerequisites exist. The only condition mentioned is the pricing model, which is not usage routing.

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 non-annotation context: it is a guidance/signposting tool rather than a lookup, and it discloses a rate/cost model ('a few free samples a day, then $0.01 USDC per call via x402'). That pricing disclosure is exactly the kind of behavioral detail annotations cannot convey.

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 compact sentences, front-loaded with the domain and covered categories, then the exclusion, then the pricing note. Every sentence carries information; the pricing sentence is a slight tag-on but is legitimately useful. No padding or redundancy.

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

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

An output schema exists, so return values need not be explained. The description covers scope, legal basis, the regulated-claim exclusion, and the cost model, which is sufficient for an agent to decide and invoke. The only gap is not pointing to the sibling dispute tools for out-of-scope domains.

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 all four parameters are already documented in the schema, including the category enum values and the date format. The description only restates the category list and adds no format, default, or validation detail beyond the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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 covered domains (subscription, gym, retailer, tradesperson charges) and what the tool returns: the applicable rules under the Consumer Rights Act 2015, what to ask for, and the escalation ladder to a small claim. This is specific enough to distinguish it from the regulated-claims path and from domain siblings like energy/telecoms/water. It does not name a sibling tool explicitly, so it falls short of the top score.

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

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

It provides a clear exclusion: 'Regulated claims are signposted instead,' reinforced by the schema's list of regulated categories (credit_card, bank, insurance). That tells the agent when not to use this tool. It does not, however, route the agent to the other uk-disputes siblings (energy-complaint, telecoms-complaint, water-complaint, parking-appeal), which would be needed for 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/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-structured behavior: a free-sample quota per day and $0.01 USDC per call via x402, which tells the agent about cost and rate limiting before invoking.

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 compact sentences with zero filler; the functional capability is front-loaded and the pricing caveat trails it. Sized well for a single-purpose 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?

With annotations covering safety, a full parameter schema, and an output schema handling return values, the description only needs to convey purpose and any call-time caveats. It does both, omitting only explicit sibling routing.

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 supplier, bill_date, charges_from, and complained_on. The description adds no parameter-level detail beyond that, which is the expected baseline 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 names a specific domain (UK energy complaint) and concrete deliverables: back-billing/12-month rule check, Ombudsman timeline, cited rules. The 'energy' qualifier implicitly separates it from the telecoms-complaint and water-complaint siblings, though it never names them 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?

Usage is only implied by the domain phrase 'for a UK energy complaint'. The description never states when to pick this over uk-disputes__telecoms-complaint, uk-disputes__water-complaint, or uk-disputes__consumer-charge, and gives no prerequisites.

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 non-structured context the annotations cannot express: the cost model and rate limit ('a few free samples a day, then $0.001 USDC per call via x402'). That is material for an agent deciding whether to call it repeatedly; return shape is covered by the 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 compact sentences, no filler, with the resource scope front-loaded and the pricing caveat second. Every clause 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?

With an output schema present, return values need not be described, and the coverage of the resource plus pricing makes this callable as-is. The remaining gap is the absence of any link to how the returned organisations are consumed by the sibling complaint 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline applies. It correctly avoids inventing filter semantics that the empty schema does not support.

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 concrete resource returned: organisations in the complaints directory, broken into private parking operators and UK councils with a London flag. That is specific enough for an agent to know what comes back, though it never says what the tool *does* with them (list, search, look up) and does not distinguish itself from uk-disputes__complaints-contact, the nearest sibling.

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

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

No when-to-use or when-not-to-use guidance is given. The description does not explain whether this is the lookup step that precedes uk-disputes__complaints-contact / parking-appeal / energy-complaint, nor what conditions select it over those siblings. Usage is only inferable from the resource name.

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). The description adds genuinely non-annotation context: a rate limit ('a few free samples a day') and a per-call cost model ('$0.01 USDC per call via x402'). That payment/throttling disclosure is real added value, though it does not describe latency, auth, or how the assessment itself is produced.

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 tight sentences with the operational listing front-loaded and the pricing caveat second. Nothing is padded, but the first sentence is a keyword cluster that reads more like an output dump than polished prose, and the output schema already exists to carry that detail.

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 it correctly focuses on scope and the payment/rate-limit model. Required inputs (type, issued_on) are covered by the schema. It is largely complete for a single-purpose read-only assessment tool, missing only framing of what 'strategy' output means.

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 all six parameters (type, amount, ground, issuer, issued_on, ticket_kind) are already documented in the schema and the baseline is 3. The description adds only marginal meaning, restating the council/private split that 'type' already captures, and does not explain the 'ground' key or date format beyond what the schema states.

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

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

The description names the resource (council PCN or private parking charge) and enumerates the concrete outputs an agent gets back: route, deadlines, grounds, tribunal, cited law and strategy. It is specific enough to distinguish this appeal-assessment tool from sibling dispute tools like complaints-contact or consumer-charge. It falls short of a 5 because the framing is telegraphic and never states the core verb (assess/route) in prose.

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 phrase 'Council PCN or private charge' implies the domain in which this tool applies, giving implied usage context. However, it names no alternative and gives no explicit when-to-use / when-not-to-use guidance relative to siblings such as uk-disputes__complaints-contact or uk-disputes__consumer-charge.

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 new behavioral context the annotations lack: the free-sample quota and the x402 micropayment charge per call, which tells the agent this is a metered paid service.

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 compact sentences with the domain purpose front-loaded and the payment terms secondary; no filler. It could be marginally tighter, but nothing is wasted.

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 described, and the schema fully covers parameter semantics. The remaining gap is routing guidance against the sibling complaint tools, which is a moderate omission rather than a critical one.

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 all four parameters (provider, complained_on, contract_start, change_notified_on) are already documented in the schema. The description adds no additional meaning about formats, defaults, or how dates drive the 6 vs 8 week determination, so the baseline 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?

Names the specific resource (UK telecoms complaint) and the concrete outputs (ADR timeline of 6 or 8 weeks, price-rise rules, penalty-free exit window), which clearly distinguishes it from sibling tools like uk-disputes__energy-complaint and uk-disputes__water-complaint. No explicit verb such as 'returns' or 'calculates', so the action is implied rather than stated.

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 only usage-oriented information is the commercial model (a few free samples per day, then $0.01 USDC per call via x402). There is no guidance on when this tool applies versus the other uk-disputes complaint tools, nor any prerequisite such as needing a complaint date or contract start.

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 safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds real behavioral context beyond them: a rate/allowance limit ('a few free samples a day') and a per-call cost ('$0.01 USDC per call via x402'), plus the England & Wales applicability boundary. Rate limits and cost are exactly the kind of trait annotations cannot express, though return/pagination behavior is unaddressed.

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 compact sentences that front-load the substantive scope before the pricing detail. Every element is brief, though the payment/cost sentence is arguably secondary to invocation semantics and slightly dilutes the focus.

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, and annotations carry the safety profile. The description covers topical scope and cost, but omits the most consequential missing piece for a multi-sibling dispute family: when this tool is the right choice versus complaints-contact or the other *-complaint tools. Adequate but with a clear 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?

Schema description coverage is 100%, with 'company' and 'complained_on' both documented, so the baseline is 3. The description adds no parameter-level meaning (e.g., acceptable date formats or company-name matching) on top of the schema. With all parameters already documented, this is adequate.

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 domain content ('two-stage complaint, CCW referral and Guaranteed Standards Scheme timeline') and the geographic scope (England & Wales), which distinguishes it from the energy/telecoms/parking siblings. However, it never states the action the tool performs (retrieve? generate? walk through steps?) or what it returns, so the purpose is inferred from name and title rather than stated. It is topical rather than functional.

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

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

No guidance on when to use this tool versus alternatives such as uk-disputes__complaints-contact or uk-disputes__energy-complaint. The only adjacent information is a pricing sentence ('free samples a day, then $0.01 USDC per call'), which is cost, not usage routing. The agent must guess the selection condition.

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 non-redundant behavior the annotations cannot convey: the free-sample quota and the x402 USDC micropayment model, which materially affects whether an agent should invoke it repeatedly.

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 tight sentences with no filler; the search scope is front-loaded and the payment caveat follows immediately. 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 an output schema present, return values need not be explained, and the description covers scope, the key filter, and the cost model. What is missing is any indication of source coverage or freshness and any link to the sibling notice-retrieval tool.

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

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

Schema coverage is 100% with descriptive text for all three parameters, so the baseline is 3. The description restates name and death_year but adds no format, range, or behavior detail (e.g. matching semantics on name) beyond what the schema already provides, and never mentions limit.

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 (Search) and resource (UK deceased-estates notices) and names both filter dimensions (name, year of death). It does not distinguish itself from the sibling uk-gazette__notice, which an agent may confuse with it, so it falls 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?

Usage is implied by the required name parameter, and the pricing statement ('a few free samples a day, then $0.01 USDC per call via x402') gives useful decision context. However there is no explicit when-to-use vs when-not guidance, nor any pointer to the related uk-gazette__notice tool.

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 read-only, idempotent and open-world behavior, so the bar is lower. The description meaningfully adds the commercial model — a few free samples per day, then $0.02 USDC per call via x402 — which the agent cannot infer from annotations and needs in order to budget calls.

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: payload contents first, cost model second. No filler, no redundancy with the title, and the most decision-relevant information is front-loaded.

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

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

An output schema exists, so return structure need not be spelled out, and the description still previews the key fields. Pricing is covered. What is missing is how to source a valid notice_id or what happens on an unknown id.

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 at 100% schema coverage, so the schema fully documents notice_id. The description adds no format, sourcing or validation guidance beyond what the schema already says, which is the expected baseline 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 resource ('one deceased-estates notice') and enumerates the returned fields (address, date of death, executor, claim deadline). The singular framing implicitly differentiates it from the list-style sibling uk-gazette__deceased-estates, though that sibling is never named.

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

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

No when-to-use statement, no prerequisite (e.g. 'requires a notice_id obtained from uk-gazette__deceased-estates'), and no alternatives mentioned. The workflow hint lives only in the schema's notice_id description, not in the tool description.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive. The description adds genuinely new behavioral context beyond those: a hard cap of the most recent 50 changes, the fields returned (amending provision, in-force dates, whether the change is reflected in the text), and the payment model (free within daily allowance, then $0.003 USDC per call via x402). That pricing/limit disclosure is valuable and not derivable from structured fields.

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, front-loaded with the resource and its contents before the ancillary payment note. Nearly every clause earns its place; the x402 pricing sentence is relevant for invocation planning even if slightly appended.

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 structure needn't be restated, and the description still summarizes what the response contains. Parameters are covered by the schema and the payment model is disclosed. The only gap is the absence of routing guidance relative to sibling 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 description coverage is 100%, so all three parameters (type, year, number) are already documented in the schema, including the regnal-year edge case. The description adds no parameter-level meaning beyond identifying the target legislation, 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 verb and resource: retrieve the most recent 50 changes (substitutions, repeals, insertions) made by later legislation to a given Act/SI, with amending provision, in-force dates, and reflected-in-text status. This is clear and concrete. It does not, however, explicitly distinguish itself from siblings like uk-legislation__provision or uk-legislation__item, so an agent must infer 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 explicit when-to-use or when-not-to-use guidance, and no named alternatives among the uk-legislation siblings (item, latest, provision, search, types). The implicit context — you supply type/year/number to identify a specific piece of legislation — is present but never spelled out as routing guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the pricing model (free within a daily allowance, then $0.003 USDC per call via x402), which an agent needs to reason about cost of invocation.

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

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

Two short sentences with no waste; the returned-field inventory is front-loaded and the cost model follows. It is tight and readable, though it spends its first sentence enumerating return values that 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 and rich annotations, the description need not explain return values or safety, and it usefully covers pricing. Remaining gaps are procedural rather than informational: nothing tells the agent how to obtain a valid identifier or when to prefer this tool over provision/changes.

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 type, year and number, including the regnal-year format for pre-1963. The description adds no parameter-level meaning beyond that, 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 the resource (an Act or instrument) and enumerates the returned fields (title, long title, date, status, extent, changes count, table of contents), so the agent can infer this is a metadata/overview fetch by identifier. However, it reads as a list of return values rather than a verb+resource action, and it never distinguishes itself from siblings like uk-legislation__provision or uk-legislation__changes.

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

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

No when-to-use guidance and no routing to alternatives such as provision, changes, or search. The only implicit hint is the schema's 'see types' note pointing at uk-legislation__types, which helps identify the type code but says nothing about when this tool is the right choice versus its 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), and the description adds a genuinely new behavioral trait: the pricing/auth model ('Free within the daily allowance, then $0.001 USDC per call via x402'). That is valuable context beyond structured fields, though return-shape behavior is left to the 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 tight sentences, front-loaded with the core purpose, and each sentence carries distinct information (scope + pricing). No waste.

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

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

An output schema exists, so return values need no explanation, and the pricing model is disclosed. For a low-complexity single-optional-param tool this is nearly complete; the only gap is not directing the agent to uk-legislation__types for valid type codes.

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 the single 'type' parameter. The description adds only that the filter is optional and refers to 'one type', without enumerating valid type codes or pointing at the sibling that lists them. Baseline 3 is appropriate.

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

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

States a specific resource and scope: 'The newest Acts and instruments published, optionally of one type.' An agent can tell it returns the latest legislation rather than search or a specific item. It does not, however, explicitly distinguish itself from close siblings like uk-legislation__changes or uk-legislation__search.

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?

Only implied guidance ('optionally of one type') suggests a filter is available. There is no statement of when to use this versus uk-legislation__search, __changes, or __types, and no prerequisites or exclusions are given.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive traits. The description adds real value beyond them: it discloses the output form (plain numbered text with amendment and commencement notes), the point-in-time behavior, and a rate/cost limit (free within a daily allowance, then $0.003 USDC per call via x402).

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 tight sentences with no filler: the capability is front-loaded and the cost/scope caveat follows. Every clause 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?

With an output schema present, the description need not explain return values, and it adequately covers granularity, date behavior and cost. Only the relationship to sibling legislation tools is unaddressed, 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?

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description reinforces the date parameter's 'today or past date' semantics but adds no syntax or format detail beyond what the schema provides — baseline 3.

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

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

States a specific verb+resource: retrieving 'plain numbered text of one section, regulation, article or schedule paragraph'. The granularity ('one ... paragraph') implicitly distinguishes it from whole-item retrieval, but no sibling such as uk-legislation__item or uk-legislation__search is named to make the boundary 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 indicates the applicable context ('as it stands today or on a past date') and discloses the cost model, which is genuine usage information. However, it never says when to pick this over the sibling item/search/changes tools, so selection guidance 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context the annotations lack: a cost model (free within a daily allowance, then $0.002 USDC per call via x402). It does not discuss result limits or pagination behavior, so it stops 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?

Two compact sentences, front-loaded with what the tool does followed by the pricing caveat. No filler and nothing 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?

An output schema exists, so return values need not be explained. Combined with full schema coverage and annotation-backed safety, the description covers purpose and cost adequately; only the lack of routing guidance against sibling tools is a meaningful 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?

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description's mention of title/full-text/type/year mirrors the schema without adding syntax or format detail, 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 pairs a specific verb ('Find') with a specific resource ('Acts and instruments') and states the searchable facets (title words or full text, type, year). It is clearly a search tool, but it never names or differentiates itself from siblings like uk-legislation__latest, uk-legislation__item, or uk-legislation__changes.

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 lists what can be searched but gives no when-to-use context and no alternatives. An agent cannot tell from the description whether to reach for this tool or uk-legislation__latest/uk-legislation__item for a given need.

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 safety is covered. The description adds genuinely useful non-obvious behavior beyond that: the pricing model (free within the daily allowance, then $0.0005 USDC per call via x402), which materially affects invocation decisions. It stops short of noting anything about result stability or caching.

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 with zero filler: purpose first, cost second. Nothing is redundant, though the purpose clause is so compressed that a few more words of scope would have cost nothing.

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 parameterless reference lookup with an output schema present, the description covers what the tool returns and its cost, which is enough for an agent to call it correctly. The remaining gap is workflow placement — it never says this is the tool to consult before filtering other legislation calls.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter text is needed or expected 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?

The description states the resource ("Type codes and what they mean") but gives no verb and no scope statement, so it reads more like a label than an action. It is distinguishable from siblings like uk-legislation__search or uk-legislation__item only by inference, since it never says it is a static reference list of legislation types. Purpose is inferable but not crisp.

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 guidance on when to call this versus the sibling legislation tools, and no hint of the obvious use case (resolving the type codes that search/item expect). The only contextual sentence is about billing, not usage. An agent must guess the tool's role in a workflow.

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 new context not in structured fields: a pricing model (free within the daily allowance, then $0.003 USDC per call via x402) and the fact that 'updated' as well as newly published notices 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?

Two tight sentences, front-loaded with the scope and window before the pricing note. The pricing sentence carries real information rather than filler, though the stage enumeration slightly duplicates the schema.

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 no explanation. The description covers scope, time window, stage dimension, filtering and cost model, leaving little an agent would need before calling it; only sibling routing is absent.

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% and all four parameters (q, days, limit, stage) are documented there, including defaults and the 1–7 day bound. The description restates the stage values and keyword filter without adding syntax or format detail, 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 resource and scope: above-threshold UK notices published or updated on Find a Tender within a 1–7 day window, broken out by stage. The recency window implicitly separates it from the historical uk-tenders__search, but no sibling is named 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?

Usage is implied by the 'last 1–7 days' framing (use this for recent notices rather than historical lookup), but there is no explicit when-to-use statement, no exclusions, and no pointer to uk-tenders__search or uk-tenders__notice for other cases.

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 context beyond that: the pricing/licensing model (free within the daily allowance, then $0.002 USDC per call via x402), which an agent cannot infer from annotations and which affects invocation strategy.

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 tightly packed sentences: the first front-loads the content scope, the second covers accepted ID formats and cost. No filler, no restatement of the title, and every clause carries information an agent can act on.

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 an output schema present, the description needn't document return values and doesn't try. It covers identity, input formats, and cost, which is sufficient; only explicit sibling routing is missing, which is a usage-guideline gap rather than a completeness one.

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 there is only one parameter, so the baseline is 3. The description goes slightly beyond the schema by restating both accepted identifier types and supplying a concrete example format ('095302-2026'), which helps the agent construct a valid value.

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

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

States a specific verb and resource ('One notice in full') and enumerates the returned content (description, CPV codes, contract dates, procedure, awards), which clearly frames it as the detail-view counterpart to the search tools. It does not explicitly name a sibling, so the differentiation is implicit rather than stated.

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 which identifier forms are accepted (Contracts Finder GUID or Find a Tender notice number, with an example), which implies the retrieval context. However, it gives no explicit guidance on when to use this versus uk-tenders__search, uk-tenders__find-a-tender-latest, or uk-tenders__supplier-awards, nor any prerequisites or exclusions.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful behavioral context the annotations lack: the x402 pay-per-call model and the free daily allowance, which affects how an agent should budget repeated calls.

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: the first front-loads the resource and searchable facets, the second handles only the pricing caveat. No filler, no repetition 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?

An output schema exists so return values need not be explained, and all seven params are optional and schema-documented. The description covers facets and cost; it omits only minor operational details like result pagination or ordering behavior, which keeps it just short of full completeness.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters with their formats and enum-like values. The description restates the same facets (status values, type, dates, min value) without adding syntax or semantics 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?

States a specific resource (Contracts Finder notices) and enumerates the filterable facets: keyword, status, type, publication date, and minimum value. An agent understands exactly what corpus is searched, though it never explicitly contrasts itself with siblings like uk-tenders__notice or uk-tenders__find-a-tender-latest.

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 never says when to pick this tool over uk-tenders__notice, uk-tenders__find-a-tender-latest, or the EU equivalents, nor when-not to use it. The only usage-adjacent content is pricing (free allowance, then $0.003/call), which is cost guidance rather than selection 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 the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower; the description still adds real context by disclosing result ordering, phrase-based name matching, and the pricing model (free within a daily allowance, then $0.003 USDC via x402). The paid call behavior is a genuine operational trait an agent should know before invoking.

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 scope (awards to a supplier), then matching method, ordering, return value, and cost. No filler or repetition.

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 structure need not be described, and the description covers scope, ordering, and cost. The only meaningful omission is routing guidance relative to the sibling uk-tenders__search and uk-tenders__notice 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 description coverage is 100%, so both parameters are already documented, and the description's 'name match' phrasing merely echoes the schema's 'matched as a phrase' note. No additional date-format or default semantics are supplied beyond the schema. 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: awards won by a supplier from Contracts Finder, with the matching method (name match) and ordering (newest first). That is enough to separate it from the generic uk-tenders__search, though it never names a sibling 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?

The description says what the tool returns but never states when to choose it over uk-tenders__search or uk-tenders__notice, nor any prerequisite around the supplier name format. Usage is only inferable from the purpose sentence.

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 new operational context: the result includes group members, and there is a metered cost model (free daily allowance, then $0.002 USDC per call via x402) that the agent must know before issuing calls. Nothing contradicts the annotations.

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

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

Two tight sentences: the resource definition and scope come first, followed by the cost note. Every clause carries signal — examples, members, and pricing — with 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?

An output schema exists, so return-format explanation is not needed, and the description still flags that group members are included. With annotations covering safety and the description covering cost, the only unmet need is explicit guidance on when to prefer this tool over the other uk-trade-tariff endpoints.

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; the description lifts it by giving concrete id examples (1011, 1013) that clarify what a 'group' id looks like for the q filter and what 'groups used in measures' means. It does not explain the kind enum values, but the schema does.

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 resource — tariff geographical areas — and disambiguates it with concrete examples (1011 ERGA OMNES, 1013 European Union, trade agreements) plus the scope of 'group members'. None of the siblings (commodity, heading, quotas, exchange-rates) overlap, so an agent can place this tool 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?

There is no when-to-use or when-not-to-use guidance and no routing to an alternative tool. The only contextual sentence is about pricing ('Free within the daily allowance, then $0.002 USDC per call'), which is cost information, not selection 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, idempotent, openWorld, and non-destructive, so the safety profile is set. The description adds real behavioral value by disclosing cost/rate-limit behavior ('Free within the daily allowance, then $0.002 USDC per call via x402'), which the annotations do not convey, plus the breadth of returned measures including controls with document codes.

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 returned payload, then the optional parameter's effect, then the pricing model in three compact sentences with no filler. Slightly dense but every clause carries information an 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?

Given an output schema already documents return structure and annotations carry the safety profile, the description supplies the remaining essentials: scope of measures, origin filtering, and cost. Error and pagination behavior are untouched, but for this lookup-shaped tool the coverage is sufficient.

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

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

Schema description coverage is 100%, so both parameters are documented at baseline. The description restates the country filter's effect ('keep only what applies to that origin'), largely repeating the schema's 'filters measures to those that apply' without adding format, padding, or default details beyond the code example already in 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?

States a specific resource ('One commodity code') and enumerates exactly what is returned: description, section/chapter/heading, third-country duty, and every import/export measure. This is far more informative than the title. It does not explicitly name the sibling it differs from (heading, search), but 'one commodity code' implies a single-code detail lookup.

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 only usage guidance is the origin-filtering hint ('Give country to keep only what applies to that origin'). There is no explicit when-to-use vs alternatives such as uk-trade-tariff__heading (broader level) or uk-trade-tariff__search (code discovery), leaving the agent to infer which tariff tool fits which lookup granularity.

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/idempotent/non-destructive/openWorld, so the safety profile is handled. The description adds genuinely useful behavioral context beyond them: the data unit ('units per £1') and the commercial constraint ('Free within the daily allowance, then $0.002 USDC per call via x402'), which an agent needs to know before invoking.

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 tight sentences with no waste: the what/unit comes first, the cost constraint second. Every clause earns its place and nothing 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?

An output schema exists, so return values need not be explained, and the description still communicates the output unit and payment model. For a simple 3-param read tool this is nearly complete; only explicit routing to alternatives would make it fully airtight.

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 year/month/currency are already documented in the schema, and the description adds no parameter-level detail beyond implying a monthly granularity. Baseline 3 is correct 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 names a specific resource ('HMRC's monthly exchange rates') and its role ('convert invoice values for customs and import VAT'), which is clearly distinct from the sibling tariff endpoints (commodity, heading, quotas, search). It stops short of explicitly contrasting itself with siblings, but the resource 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?

The phrase 'used to convert invoice values for customs and import VAT' implies the usage context, but there is no explicit when-to-use vs when-to-use-an-alternative guidance or mention of prerequisites. Context is implied 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 cover safety (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). The description adds useful operational context: a free daily allowance followed by $0.002 USDC per call via x402, and it characterizes the return as including indents and declarability. This goes beyond the structured annotations, though it doesn't detail authentication or rate-limit mechanics.

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 tight sentences: the first defines the output, the second covers pricing. Both are front-loaded and free of filler, so every sentence earns its place.

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

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

For a simple lookup with a rich output schema and detailed annotations, the description covers the returned data and the payment model. The main omission is routing guidance relative to sibling tariff tools, which prevents a perfect score.

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 'code' parameter is documented with type and example. The description repeats '4-digit heading' but adds no syntax, format, or validation detail beyond what the schema provides, 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 states a specific resource ('A 4-digit heading and every commodity code under it') and what it returns ('with indents and whether each is declarable'). It does not name or differentiate from sibling tariff tools like uk-trade-tariff__commodity or uk-trade-tariff__search, 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?

There is no guidance on when to use this tool versus alternatives such as uk-trade-tariff__commodity or uk-trade-tariff__search. The pricing sentence describes cost, not usage context, so the agent is left to infer selection.

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