CelerAPI

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

Annotations already declare read-only, idempotent, non-destructive and open-world, and the description adds genuinely new context: the upstream source, that it is a single CelerAPI call, that the rate is a published ECB reference rather than a live quote, and the x402 USDC price. This is exactly the kind of cost, provenance and freshness disclosure annotations cannot carry, and nothing contradicts them.

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

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

Roughly six short sentences, front-loaded with the action and its data source, then constraints, then return shape, then the important caveat and cost. Every sentence carries distinct information; nothing is 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?

For a three-parameter conversion tool it covers source, constraints, return fields, freshness caveat, billing and a call example. An output schema exists, yet the description still names the returned fields without over-explaining, so nothing an agent needs 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 0%, so the description must carry the load, and it does: it names all three parameters, clarifies the amount must be finite and within bounds, and specifies supported three-letter ISO codes plus a worked example. Some of that (the 1e9 ceiling, the >0 floor, the three-letter pattern) duplicates what the JSON Schema already encodes, which keeps it from a 5.

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 ("Convert a specified amount") plus the data source (ECB reference rates via Frankfurter), which distinguishes it from rate-lookup siblings. An agent can tell immediately this returns a converted value rather than a bare rate.

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

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

Explicitly rules out a common mistake by stating "get_fx_rate is not a prerequisite" and frames the use case as an "Informational estimate, not trade execution or a real-time quote." It stops short of saying when to prefer get_fx_rate or get_historical_fx_rate instead, so routing is implied rather than fully specified.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, and the description adds real context beyond that: the x402 USDC price on Base mainnet and the boundary that contents are not interpreted. It doesn't describe ordering, pagination, or what happens for an unknown company number, but the safety profile is well covered.

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

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

Three sentences, front-loaded with the core action, then scope, then usage and pricing. The limit range is duplicated from the schema and the pricing sentence is a bit abrupt, but there is little wasted wording.

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 explained, and the description covers input requirement, scope, and cost. The only real gap is how 'recent' records are ordered and whether there is pagination beyond the limit cap, which matters for a list tool capped at 100.

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 both company_number (pattern, example, pointer to search_company) and limit (default, 1-100 bounds) fully documented in the schema. The description's restatement of 'limit defaults to 10 and accepts 1 to 100' adds no meaning beyond that, 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 names a specific verb and resource ('Retrieve recent Companies House filing-history metadata') scoped to 'a known UK company', and lists the record types. The Companies House / UK qualifier implicitly separates it from get_sec_filings and get_entity_filings, but it never names those siblings directly, leaving the jurisdictional split 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?

It gives concrete use cases (corporate research, due diligence, reviewing recent changes) and an explicit exclusion ('does not semantically interpret filing contents'), plus 'for a known UK company' implies running search_company first. It stops short of routing to alternatives such as get_entity_filings for non-UK entities.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds meaningful behavior beyond them: normalized outcomes for no insolvency information, existing insolvency information, and lookup/source failure, plus the caveat that absence is not proof of financial health and the x402 price.

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 purpose and stays compact without repeating schema details. The use-case sentence is somewhat generic and the pricing sentence is operational, but both are relevant; minor density keeps it from a 5.

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 read-only lookup with an output schema and rich annotations, the description covers purpose, result interpretation, use context, and a key inference caveat. The main omission is sibling differentiation from get_entity_insolvency.

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 one parameter and schema description coverage is 100%; the schema already documents the company_number pattern, example, and source. The description's 'known UK company' aligns with that but adds no further syntax or format meaning, so the baseline of 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 verb and resource ('Retrieve Companies House insolvency information') and scopes it to a known UK company, making it distinguishable from filings, officers, and profile tools. It does not explicitly distinguish itself from the sibling get_entity_insolvency, which keeps it below 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?

Gives clear usage contexts such as supplier checks, counterparty due diligence, and company-risk research, plus a caution about interpreting absence of data. It does not state when not to use it or name get_entity_insolvency as an alternative, so it lacks explicit exclusions and alternatives.

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, so the safety profile is covered; the description adds genuinely new behavioral context on top: 'where available' signals incomplete coverage, the fields 'are not independently verified by CelerAPI' discloses data provenance/trust limits, and the x402 price on Base mainnet tells the agent a paid call is involved. It stops short of explaining any rate limits, pagination, or empty-result behavior beyond the availability caveat.

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

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

Three sentences organized as purpose, field content, use cases, with the core verb and scope front-loaded and no filler. The pricing sentence is useful but sits somewhat detached at the end rather than being integrated into the operational guidance.

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 cover the safety profile; the description fills the remaining gaps an agent would care about: data trust, field availability, cost. It leaves minor operational details (empty-result handling, whether resigned officers are included by default given the 'resignation details where available' phrasing) 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% and the single company_number parameter is fully documented in the schema (format pattern, source sibling search_company, example). The description only implies that the identifier is a UK Companies House number and adds no syntax or sourcing detail beyond what the schema already 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?

States a specific verb and resource ('Retrieve directors and other officers recorded for a UK company at Companies House'), which is far more precise than the tool name alone. The 'UK company / Companies House' scoping implicitly distinguishes it from the parallel get_entity_officers sibling, but that sibling is never named, so the differentiation is inferential rather than explicit.

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

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

Enumerates concrete use contexts (due diligence, governance research, supplier onboarding, public-register verification), which gives an agent a clear sense of when the tool is appropriate. There are no exclusions or named alternatives ('use X instead when...'), so it falls short of the top band.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: PSC data mirrors the public register and is not independent verification of beneficial ownership, plus the paid x402/USDC access model on Base mainnet — a real operational constraint an agent must 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?

Four short sentences, front-loaded with the verb and resource, followed by use case, a data-provenance caveat and the price. Each sentence carries information, though the pricing sentence is somewhat boilerplate-adjacent and could be tightened.

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

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

With an output schema present, return values need no explanation, and the single required parameter is fully documented in the schema. The description covers provenance and payment prerequisites, leaving only minor gaps such as behavior when a company has no recorded PSC.

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 at 100% schema description coverage, with the pattern and an example already documented in the schema. The description contributes nothing further about company_number format or sourcing, so baseline 3 applies.

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

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

The description names a specific verb and resource — 'Retrieve Persons with Significant Control (PSC) recorded for a UK company at Companies House' — and enumerates what comes back (nature of control, identity information). It is clearly separable from sibling data tools by the PSC domain term, though it never explicitly contrasts itself with get_company_officers or get_entity_owners, which an agent must infer from domain knowledge.

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?

'Useful for company ownership research and KYB-supporting due diligence' gives a use context but not a selection rule: it doesn't say when to prefer this over get_company_officers (officers/directors) or get_entity_owners (non-UK entities), nor when not to call it. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-schema context: the call is paid ($0.0053 production USDC via x402 on Base mainnet), which an agent must know before invoking it, and that it requires an already-known company number. It does not say what happens on an unknown/invalid registration, but the payment disclosure is a substantial addition.

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

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

Three sentences, front-loaded with the core action and resource, followed by scope enumeration then use cases then cost. The field list is long but informative; the price sentence earns its place because it affects invocation decisions. Slight bloat from the unfocused use-case sentence.

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

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

The tool is simple (one required parameter, no nesting), an output schema exists so return shapes need not be explained, and the description covers purpose, scope, prerequisites and payment. The main remaining gap is routing guidance among the many sibling lookup tools, which for a registry with both company- and entity-level variants would be valuable.

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%: the single parameter has a pattern, a format note, an example and a pointer to search_company. The description only reinforces 'known UK company number' as a prerequisite, adding little 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 uses a specific verb ('Retrieve') and resource ('Companies House profile for a known UK company number') and enumerates the payload (legal name, status, type, incorporation date, registered office, SIC codes, accounts/confirmation metadata). The field list implicitly separates it from siblings like get_company_officers, get_company_filings and get_company_insolvency, but it never explicitly names those alternatives or the near-twin get_entity_profile, so the differentiation is inferred 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?

It lists use cases (public-register verification, onboarding, supplier checks, corporate research) but these describe business scenarios rather than tool-selection criteria. There is no when-not-to-use guidance and nothing explaining when to pick get_company_profile over get_entity_profile or why the company must already be 'known' (i.e., obtained via search_company).

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), so the description's job is to add operational detail, which it does: coverage is limited to GB Companies House, no cross-jurisdiction equivalence is inferred, and unsupported calls are rejected before payment. Pricing ($0.0106 USDC via x402 on Base mainnet) is genuinely useful context for an autonomous agent. It stops short of describing result volume or pagination despite a limit parameter.

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

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

Four tight sentences, front-loaded with the core capability before scope caveats and pricing. Every sentence carries distinct information (capability, coverage limit, rejection behavior, price). The pricing sentence is arguably secondary but is legitimately decision-relevant.

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 needn't explain return values, and it correctly focuses on the unusual constraints — jurisdiction coverage and pre-payment rejection. The remaining gap is that it doesn't indicate how many filings are returned by default or how the limit interacts with results, which an agent budgeting calls would want.

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 50%: entity_id is documented in the schema itself, and limit is a self-explanatory bounded integer with a default. The description reinforces that the entity must be 'resolved' but adds no syntax, format, or limit semantics beyond what the schema provides. Baseline 3 is appropriate when the schema carries this much of the 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 states a specific verb and resource: 'Retrieve normalized authoritative filing-history metadata for a resolved legal entity.' The qualifier 'resolved legal entity' plus the coverage scope (GB Companies House) makes the intent clear. It never explicitly contrasts itself with the sibling get_company_filings, so an agent must infer the entity-vs-company distinction from naming 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?

Usage is implied rather than stated: 'where supported by its registry' and 'Coverage currently includes GB Companies House filings only' tell the agent when the tool will fail, and 'Unsupported capabilities are rejected before payment' reassures about cost. However, it never says 'use this instead of get_company_filings when...' or specifies prerequisites such as resolving the entity via search_company first — that constraint only appears in the schema.

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

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

Annotations already cover the read-only, idempotent, non-destructive, open-world profile, so the description adds genuine extra context: the paid x402 flow at $0.0056 USDC on Base mainnet, pre-payment rejection of unsupported capabilities, and the false-negative caveat about missing records. It does not discuss error behavior or latency, but the payment and coverage semantics are the high-value disclosures an agent needs.

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 what the tool returns and immediately followed by the coverage constraint. The pricing sentence is dense but factual. No filler, though the payment-mechanics sentence could be trimmed without losing decision-relevant 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 parameter, output schema present), so return values need no explanation. Coverage limits, the paid-payment model, and the interpretation caveat are all covered. The missing piece is disambiguation from the near-identically named sibling tool, which matters given the crowded entity/company toolset.

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 entity_id field is thoroughly documented ('Stable CelerAPI entity ID returned by search_company. Pass it unchanged.'). The description adds only the indirect hint that the entity must already be 'resolved'. With the schema carrying the parameter burden, 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 normalized authoritative insolvency information for a resolved legal entity where supported by its registry.' It scopes coverage to GB Companies House, so an agent knows what data it is getting. The one gap is that it never distinguishes itself from the sibling 'get_company_insolvency', leaving the entity-vs-company split implicit.

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

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

It gives clear usage context: the entity must be resolved, coverage is currently GB Companies House only, and unsupported capabilities are rejected before payment. It also warns that absence of a record is not proof of financial health, which prevents misreading an empty result. It stops short of naming an alternative tool for non-GB entities or for the company-level variant.

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

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

Annotations already establish read-only, idempotent, non-destructive semantics, so the description is free to add what they cannot: the specific price ($0.0104 USDC), the payment rail (x402 on Base mainnet), and the billing-safety guarantee that unsupported calls are rejected before payment. Jurisdiction-dependent variation in role semantics is also disclosed, which prevents the agent from assuming uniform output across entities.

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 front-loaded sentences covering capability, jurisdictional scope, and commercial terms, with no filler. Slight deduction because 'normalized authoritative' is dense abstraction that conveys little concrete meaning to a selecting agent, and the pricing sentence, while useful, is appended as a flat trailer.

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 shape, and it covers the two things structured fields cannot: geographic coverage limits and cost/payment behavior. The remaining gap is that it never states what happens for entities outside GB beyond a generic rejection, nor whether a prior search_company call in the same session is required.

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

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

There is only one parameter and schema coverage is 100%, with the schema itself explaining that entity_id is a stable ID from search_company to be passed unchanged. The description reinforces the 'resolved legal entity' precondition but adds no format, length, or validation detail 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 names a specific verb ('Retrieve') and a specific resource ('normalized authoritative management or registered-role information') scoped to a 'resolved legal entity'. The word 'resolved' implicitly separates it from the name-search paths used by siblings like get_company_officers, but no sibling is named outright, so the differentiation is inferred 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?

It gives clear positive context (GB coverage today, jurisdiction-dependent role semantics) and a negative condition (unsupported capabilities are rejected before payment), which is exactly the kind of when-not guidance an agent needs. It stops short of an explicit 5 because no alternative tool is named for cases where registry coverage does not exist or the caller only has a company 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 read-only, idempotent, non-destructive profile, and the description adds genuinely useful context beyond them: the authoritative-registry caveat, the explicit 'not independent beneficial-ownership verification' disclaimer, pre-payment rejection of unsupported capabilities, and the x402 USDC price. It stops short of describing pagination or response shape, but the safety and cost profile are clear.

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

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

Four sentences, each carrying distinct information (capability, coverage caveat, rejection behavior, price), with the capability and scope front-loaded. The pricing sentence is slightly dense but is necessary operational context for a paid endpoint.

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 a simple single-parameter read with an output schema, so return values need not be explained. The description supplies the regulatory caveat, geographic coverage, payment model, and failure behavior, leaving little an agent needs that 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?

With a single parameter at 100% schema description coverage, the schema already explains that entity_id is a stable ID from search_company to be passed unchanged. The description's phrase 'resolved legal entity' reinforces that prerequisite but adds no new syntax or format detail, 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 opens with a specific verb and resource ('Retrieve normalized ownership or control records for a resolved legal entity'), which is far more informative than the bare tool name. It scopes the data to GB Companies House PSC records, though it never explicitly contrasts itself with the sibling get_company_owners, leaving the entity-vs-company distinction 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?

Coverage limits ('GB Companies House PSC records only') and the statement that unsupported capabilities are rejected before payment give an implicit when-to-use and when-not-to-use signal. However, no alternative sibling is named for cases outside GB PSC coverage, and the dependency on a prior search_company resolution is only conveyed via the schema.

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

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

Annotations already declare read-only, idempotent, open-world behavior, and the description goes beyond them by disclosing jurisdiction-dependent field completeness, pre-payment rejection of unsupported requests, and the exact price and payment rail (x402 on Base mainnet). That billing behavior is not derivable from any structured field.

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

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

Four compact sentences, front-loaded with the core action, followed by coverage caveats and pricing. Every sentence carries information; no filler or repetition of the tool name.

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?

Output schema exists, so return values need no explanation, and the definition covers the remaining agent-relevant unknowns: data coverage, jurisdictional variability, failure behavior, and cost. Only the entity-vs-company sibling relationship 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% and the parameter description already says the ID comes from search_company and must be passed unchanged. The body only restates 'using its stable CelerAPI entity ID', adding no new syntax or format 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?

States a specific verb and resource ('Retrieve normalized authoritative profile information for a resolved legal entity') and the identifier it keys on (stable CelerAPI entity ID). It does not explicitly distinguish itself from the sibling get_company_profile, so the entity-vs-company split must be inferred from the name.

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?

Adds useful usage boundaries: coverage is limited to GB and NO, and unsupported capabilities are rejected before payment, which tells the agent when a call will fail. It never states when to prefer this over get_company_profile or the entity_* siblings, so sibling routing is left implicit.

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 the description still adds material context: the response fields (rate, published rate date, provider_code), the retrieved_at-vs-rate-date distinction, and the paid-access requirement ($0.0010 USDC via x402 on Base mainnet). The payment/auth trait is exactly the kind of behavior 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?

Every clause carries distinct information and the critical disambiguation (reference rate, not converted amount) is front-loaded. The single dense paragraph is slightly over-packed, but nothing is redundant with the schema or annotations.

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 two-parameter read tool with an output schema, the remaining burden is disambiguation, provenance, freshness, and cost — all of which are covered. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning — it does, by specifying three-letter ISO codes restricted to ECB-supported currencies, plus a concrete example object. It stops short of naming the actual supported currency set or case requirements, which the schema pattern handles only partially.

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?

"Get a reference exchange rate, not a converted amount" states a specific verb and resource and immediately fences off the nearest sibling, convert_currency. The ECB/Frankfurter sourcing narrows the domain further, so an agent can pick this over get_historical_fx_rate or convert_currency without opening a schema.

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

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

It gives explicit when-to-use context: reference rate rather than conversion, latest available daily data rather than a real-time trading feed or executable quote. It does not explicitly name get_historical_fx_rate as the alternative for past dates, so routing to that sibling is left to inference from "latest available".

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-obvious behavior: holiday/weekend date resolution and a paid x402 micropayment model with a concrete price and chain. It does not describe rate source timing or what happens on unsupported currency pairs.

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

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

Three sentences, front-loaded with the operation, then the usage caveat, then the payment terms. No filler and each sentence contributes distinct 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-value detail is unnecessary, and the description covers the mutation-free nature, date-resolution caveat and payment requirement. The remaining gap is base/quote orientation, which an agent needs in order to interpret the result correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and only partly does: 'three-letter ISO currency pair' clarifies the two currency params and 'specified historical date' clarifies the date. It never explains base-versus-quote direction, i.e. which currency the returned rate is expressed in, which is the key ambiguity for this parameter pair.

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: return the ECB reference rate for a three-letter ISO currency pair on a specified historical date. The word 'historical' plus 'ECB reference rate' implicitly separates it from get_fx_rate and convert_currency, but no sibling is named explicitly, so differentiation is inferred 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?

Gives a clear use context ('retrospective reconciliation or analysis') and warns that non-business dates may resolve to provider handling rather than an intraday quote. It stops short of naming get_fx_rate as the alternative for current rates or stating when not to use this 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, non-destructive, open-world behavior, and the description adds genuinely new traits: reporting exceptions surface as warnings, absence is not proof of no relationship, and each call costs $0.0057 USDC via x402 on Base mainnet. Disclosing the paid-invocation mechanism and the epistemic caveat is exactly the value-add expected beyond 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?

Three sentences ordered purpose → caveat → cost, each carrying distinct information with no repetition of schema or annotation content. Slightly dense but front-loaded and free of 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?

With an output schema present, return-shape explanation is unnecessary, and the description covers safety, cost, and failure semantics. The only remaining gap is practical detail on how the x402 payment is settled, which an agent would need before invoking a paid endpoint.

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

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

Schema description coverage is 0%, so the single 'lei' parameter is documented only by its pattern; the description compensates partially by stressing 'exact LEI', which rules out fuzzy or name-based matching. It adds no format, casing, or lookup guidance beyond that single qualifier.

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

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

The description gives a specific verb ('Retrieve') plus a precisely scoped resource: normalized direct and ultimate accounting-consolidation parent identifiers reported to GLEIF for an exact LEI. The 'accounting-consolidation parent' framing implicitly separates it from the ownership tools (get_entity_owners, get_company_owners), but no sibling is named explicitly, so it stops short of full 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?

'Use for public corporate-hierarchy research' gives clear positive guidance, and 'for an exact LEI' signals the prerequisite that a valid LEI must already be in hand (implying lookup_lei/search_lei first). It never states when not to use it or names the beneficial-ownership alternatives, so exclusion guidance is missing.

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 readOnly/idempotent/non-destructive/openWorld, and the description adds genuinely new behavior: a concrete price ('$0.0100 production USDC via x402 on Base mainnet'), the fact that resolving an unknown CIK costs a separate paid call, what the response contains (forms, dates, accession numbers, document URLs), and the caveat that forms must be inspected for 10-K/10-Q. None of that is recoverable from the 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?

The purpose and the cik prerequisite are front-loaded, and each clause carries information (scope, prerequisites, cost, return contents, exclusions). The result is dense and slightly overloaded for one block, but no sentence is filler.

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

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

For a two-parameter, paid, read-only lookup with an output schema and full annotation coverage, the description supplies everything else an agent needs: preconditions, cost, response shape, limitations, and an invocation example. Return values are explicitly described even though an output schema exists, so there is no ambiguity about what comes back.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it partially does by explaining where cik comes from and supplying example arguments {"cik":"0000320193","limit":5}. The limit parameter is only demonstrated numerically and never explained as a result count, and the cik format (digits only) is left entirely to the schema pattern.

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

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

The description names a specific verb and resource ('Find recent SEC EDGAR filing records') and enumerates use cases (financial research, issuer due diligence, regulatory-event checks). It does not, however, differentiate itself from the very similar sibling tools get_company_filings and get_entity_filings, 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?

It gives an explicit prerequisite workflow: 'Requires cik; if unknown, first use search_sec_company by name/ticker', and flags that the lookup is a separate paid call, which is exactly the kind of when-to-use routing an agent needs. It also states clear exclusions ('No form filter, complete documents, financial extraction or investment advice'), though it never says when to prefer get_company_filings or get_entity_filings instead.

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 the description adds material context beyond them: the tzdb release is runtime-controlled so results are only deterministic per runtime, rules can change, and there is a paid call of $0.0012 USDC via x402 on Base mainnet. Payment/auth requirements are exactly the kind of behavior an agent cannot infer from annotations.

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

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

Three sentences, front-loaded with the operation before caveats and pricing; nothing is padding. The runtime/tzdb caveat is slightly compressed into one dense clause, but 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?

An output schema exists, so return values need not be described, and the tool is simple with only two parameters. Purpose, determinism caveat, and cost are all covered; the only missing piece an agent needs is the default behavior of the optional `at` parameter.

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

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

Schema description coverage is 0%, so the description carries the burden: it identifies `time_zone` as an IANA identifier and `at` as an optional ISO timestamp, which is meaningful beyond the bare pattern. However, it gives no example IANA value, no statement of what happens when `at` is omitted (current time?), and no note on how offsets are returned, leaving real gaps at zero coverage.

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 ('Resolve') and resource ('IANA time-zone identifier') plus the secondary operation ('convert an optional ISO timestamp'), and names the backing data source (Worker runtime time-zone database). An agent knows exactly what it gets, and no sibling in the list overlaps with time-zone conversion.

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?

'Use for deterministic local-time and UTC-offset calculations' gives a clear positive use case, and the note about government rules changing tells the agent when results may drift. There is no explicit when-not or named alternative, but no sibling tool is a plausible substitute, so the guidance is effectively complete.

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 bar is low. The description adds genuinely new context beyond them: the upstream data source (GLEIF), an epistemic caveat that records reflect submissions and are not independent verification, and a payment requirement of $0.0052 USDC via x402 on Base mainnet, which is critical for an agent that must arrange payment before calling.

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-load what the tool returns, then the caveat, then the cost; each clause carries information an agent needs (scope, trust caveat, payment). The pricing sentence is appended after the caveat rather than up front, which slightly buries a constraint that affects whether the call can succeed.

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 lookup with an output schema present, the description need not explain return fields, and it correctly focuses on source, scope, trust caveat, and payment. The main residual gap is that it never explicitly contrasts with the search_lei sibling, which matters given how many entity-lookup siblings exist in this toolset.

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 0%, so the description must carry the burden, and it does specify that the LEI must be an exact 20-character identifier, reinforcing and contextualizing the pattern in the schema. With only one parameter and little else to disambiguate, this is sufficient, though it adds no detail on case handling or checksum behavior.

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

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

The description opens with a concrete verb and resource: "Retrieve normalized public legal-entity reference data from GLEIF," and constrains it to "an exact 20-character LEI." The word "exact" implicitly separates it from the sibling search_lei, though it never names that sibling, so an agent must infer the distinction.

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?

"Use to resolve a known identifier to its legal name, status, jurisdiction, and public addresses" gives clear when-to-use context that naturally excludes fuzzy/name-based search. It stops short of explicitly stating "if you have a name rather than an LEI, use search_lei," so the routing guidance is implied rather than spelled out.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description goes beyond them by disclosing dataset scope ("currently supported" authorities) and the per-call price of $0.0060 production USDC via x402 on Base mainnet, which matters for budgeting. It does not discuss latency, error behavior, or what a positive match implies beyond the negative scoping sentence.

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 short sentences with zero filler: purpose first, scope boundary second, cost third. Each sentence carries a distinct piece of decision-relevant information and nothing is repeated from 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-value explanation is rightly omitted, and the description covers what is checked, the exactness of matching, dataset breadth, and cost. The only gap is any hint about how the optional authorities filter interacts with the default all-authorities behavior, which the schema largely handles on its own.

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 three parameters carry their own documentation including the enum list and the note that CelerAPI never guesses a network. The description reinforces the exact-match requirement for the address but adds no format, normalization, or casing guidance beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific verb and resource ("Checks whether an exact digital-currency address appears in the authoritative sanctions datasets") and explicitly delimits scope by ruling out blockchain-risk analysis and compliance determinations. An agent can tell exactly what question this tool answers, and no sibling in the list overlaps with sanctions screening.

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

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

It gives clear context for use (sanctions-list membership) and explicit when-not boundaries ("not blockchain-risk analysis or a compliance determination"), which prevents over-trusting the result. It stops short of stating the triggering situation, e.g. screening a counterparty before a transfer, and there is no sibling alternative to route to.

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 behavior, so the description's remaining job is narrower. It adds real value by disclosing the GB default, unsupported country codes returning errors, and the pay-per-call price of $0.0050 USDC via x402. It does not describe result volume, ranking, or what the response looks like, which is acceptable 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?

Front-loaded with the core action and scope, and every sentence is on-topic. However, it is a dense six-sentence block that mixes discovery guidance, jurisdiction coverage, legal disclaimers, and pricing; the disclaimer and price could be trimmed or separated to keep the selection sentence sharp.

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

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

Covers what an agent needs before calling: jurisdiction support, default behavior, pricing, and the meaning of results as evidence rather than a compliance determination. With an output schema present, return-value detail is unnecessary, leaving only minor gaps such as result limits or ranking behavior.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the GB default and supported codes. The description only restates and recommends country_hint rather than adding format or syntax detail beyond the schema, so the baseline 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 ("search authoritative company registries by company name") plus the outcome ("resolve candidate legal entities and registration identifiers"). It distinguishes itself from siblings like search_lei and search_sec_company by naming the registry type and the jurisdictions covered.

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

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

Gives explicit routing guidance: "Use this first when the registration identifier is unknown," which tells the agent when this beats identifier-based lookups. It also sets the supported-country boundary, but never names a concrete alternative tool for users who already have an identifier or need SEC/LEI data.

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 materially new behavior: it names the returned fields (candidates, legal names, jurisdictions, statuses), warns that name matching is not identity certification and that LEI status is not a soundness attestation, and discloses a paid, metered call ($0.0051 USDC via x402 on Base mainnet). The payment requirement is exactly the kind of precondition an agent cannot infer from annotations or 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?

Front-loaded with the action and resource, followed by return values, workflow, caveats, pricing, and an example — a sensible priority order with no filler. The caveat and pricing sentences are dense and pack multiple clauses each, but every one carries actionable signal.

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 two-parameter search tool with an output schema, the description supplies everything else an agent needs: what comes back, how it chains into lookup_lei, the interpretive limits of a match, and the paid-call precondition. Nothing essential is left out relative to the tool's complexity.

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

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

Schema description coverage is 0%, so the description carries the burden here, and it does only partial work: it says "supply query; optionally limit results" and gives a concrete example payload, which clarifies the shape of both parameters. It never states that limit is an integer bounded 1–20 with a default of 10, nor what form a valid query string takes beyond "legal-entity name" (min/max length, partial-match behavior). Adequate but with real gaps for a 0%-coverage 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?

"Find candidate LEIs by legal-entity name in GLEIF's global LEI index" gives a specific verb (find/search), a specific resource (LEI), and the source registry. It is explicitly a candidate-search tool, which separates it from lookup_lei (exact-record retrieval) and from search_company in the sibling list.

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 lays out a concrete workflow: supply a query, pick a candidate, verify it, then call lookup_lei for the full record. That is clear routing guidance to the natural alternative. It stops short of stating when NOT to use it (e.g., when the LEI is already known, or versus search_company for non-LEI entity search), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new context: a concrete price ($0.0058 production USDC via x402 on Base mainnet), the fact the follow-up filing lookup is a separate paid request, and a data-coverage caveat. It does not explain what 'bounded' means numerically (the 20 cap lives only in the schema) or any 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?

Three front-loaded sentences: capability and scope first, then the follow-up workflow, then the caveat and price. Nearly every clause earns its place, though the embedded pricing/network detail and the example payload make the last portion feel slightly packed together.

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

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

With an output schema present, return values need not be explained, and the description covers the remaining essentials: what is searchable, the downstream workflow to get_sec_filings, coverage limits, and payment cost. For a two-parameter paid lookup tool this is close to complete, missing only explicit limit-range guidance.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: it tells the agent that 'query' accepts issuer name, ticker, or CIK, which the schema's bare string type does not. The example arguments {"query":"Apple","limit":10} also demonstrate the interaction of both parameters. It leaves the limit bounds (1-20, default 10) unstated, so it does not fully compensate for the coverage gap.

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

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

The description gives a specific verb ('Search') plus a precisely scoped resource ('the official SEC company ticker reference data') and names the searchable fields (issuer name, ticker, CIK) and result shape ('bounded normalized candidates'). It implicitly separates itself from the generic search_company sibling by emphasizing the SEC ticker reference list, but it never names that sibling to make the distinction 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 states a concrete when-to-use scenario: when a CIK is unknown, pick a matching candidate and pass its cik to get_sec_filings in a separate paid request. It also warns the reference list is not a complete registry of every U.S. legal entity, which prevents over-trusting results. There is no explicit exclusion against the generic search_company alternative, so it falls short of a full 5.

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