CompanyVerify

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

With no annotations, the description carries the full burden and does disclose the two behaviors that matter: the call has a side effect (the requirement is recorded) and the response is a fixed 'not-covered' with no data. It omits where the record lands, whether it is deduplicated, or rate limits, but the critical 'this does nothing useful for screening' signal is stated plainly.

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 disqualifying status ('not yet served') front-loaded before the operational detail. Nothing repeats the title gratuitously.

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 stub tool with one fully documented parameter and no output schema, the description conveys what an agent needs: it will not get screening results and the call is logged. The missing piece is guidance on which sibling to use for real adverse media needs, but the core caveat is 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% for the single 'name' parameter, so baseline is 3. The description adds no meaning beyond the schema — it does not clarify whether name is a person, company, or free-text subject, which would be the one useful addition 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 names the intended resource (adverse media screening with citations) and immediately qualifies it as 'roadmap probe, not yet served', then states the actual runtime behavior: records the requirement, returns not-covered. That distinguishes it from real screening siblings like pep_screen and sanctions_screen. It stops short of 5 only because the name implies functioning screening, so the true purpose is only clarified in the second clause.

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 'not yet served' phrasing implies the agent should not rely on it for actual screening, and 'calling records the requirement' implies a demand-capture use case. However, it never states explicitly when to call it versus pep_screen or sanctions_screen, nor what an agent should do instead when it needs adverse media 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?

With no annotations, the description carries the full burden, and it does disclose the single most important non-obvious trait: the tool does not serve data and calling it has a side effect (recording a requirement). That is exactly the kind of gotcha an agent would otherwise misread as a data lookup. It stops short of describing the response payload or whether repeated calls are deduplicated, which keeps it from 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 short sentences with zero filler, and the unusable status is placed early. Nothing repeats or pads the definition.

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 probe with no output schema, the description covers the essentials an agent needs: domain, unavailability, and the recording side effect. A note on what the call returns (confirmation versus empty result) would close the remaining 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 one required parameter and schema description coverage is 100%, so the baseline is 3. The description adds no meaning beyond the schema for company_number — no format, jurisdiction, or identifier-scheme guidance beyond the loose 'UK company' framing.

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 the domain resource (outstanding charges and security for a UK company) but immediately reframes the tool as a 'roadmap probe, not yet served', so the effective purpose is ambiguous: it does not fetch charges, it records a requirement. The final clause 'Calling records the requirement' is the only thing that tells an agent what the call actually accomplishes, and it arrives after the misleading domain framing.

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?

'Not yet served' implicitly warns an agent not to rely on this for real charge data, which is a useful negative signal. However, no alternative is named despite siblings like request_data, find_capability, and registry_doc_fetch that plausibly cover this need, and there is no statement of when an agent should deliberately call this probe versus skip it.

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?

With no annotations provided, the description carries the full behavioral burden and does well on the critical point: no actual resolution occurs, the call records a request, and the response is not-covered. It omits auth, rate-limit, and persistence details, but discloses the main behavioral surprise clearly.

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

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

The description is two sentences, front-loaded with the non-implementation status, and every clause conveys either status, intended scope, or return behavior. There is no wasted text.

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 non-implemented roadmap probe with no output schema and no annotations, the description explains what calling the tool does and what comes back. Parameter meanings remain thin, but the unusual status and side effect are fully surfaced.

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%, which sets the baseline at 3, but the schema descriptions are merely field names and the tool description adds no further meaning for name, identifiers, or jurisdiction. The nested identifiers object in particular remains semantically unspecified.

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 intended aggregate resolution scope across named registries and immediately qualifies it as a roadmap probe that is not yet served. It is clear about intended versus actual behavior, though it does not explicitly differentiate itself from sibling tools such as entity_match or kyb_verdict.

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 a strong when-not signal by saying the tool is 'not yet served' and that calling it only records the ask and returns not-covered. However, it does not name alternatives like entity_match, kyb_verdict, or request_data, so selection guidance is implied rather than 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?

With no annotations, the description carries the full burden and does so well: it discloses that LEIs are compared as supplied and not validated against GLEIF, that Companies House corroboration is optional and external, and that the output is a verdict plus heuristic confidence and signal provenance. It omits whether the optional external lookup carries latency/quota costs or 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?

Four tight sentences, front-loaded with the core action, then the caveat, then the return shape. No filler and nothing that could be cut 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?

For a 2-param tool with nested objects and no output schema, the description covers the method, the optional external dependency, the validation caveat, and the return shape (verdict, confidence, provenance). Minor gaps remain around degraded cases (e.g. name-only vs name-only with no identifiers) but nothing an agent needs 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 coverage is 100%, so the baseline would be 3, but the description adds real meaning the schema lacks: it explains how 'a' and 'b' are actually compared (identifier equality first, normalised name similarity second) and which optional fields drive which signal. It does not address the asymmetry of name normalisation or case/format expectations for supplied identifiers.

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 ('Compare two company references') and the exact matching basis (company-number/LEI equality, normalised name similarity). It implicitly separates itself from resolution-style siblings like cross_registry_resolve by describing the comparison mechanism, but never names an alternative 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: the description sketches the 'one side UK company number, other side name only' scenario and the optional Companies House corroboration, which hints at when the tool is useful. There is no explicit when-to-use vs kyb_verdict/cross_registry_resolve guidance, and no stated exclusions or 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?

With no annotations, the description carries the full behavioral burden, and it does disclose the single most important trait: the tool is not implemented and calling it records a requirement rather than performing a lookup. That is genuinely useful and prevents false assumptions about a real VIES call. It still omits what happens on invocation (error, stub response, storage of the VAT value) and any side effects or rate considerations.

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 most decision-relevant fact ('Roadmap probe, not yet served') front-loaded before the domain description. No filler; the only minor weakness is that the second clause is terse to the point of being cryptic.

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 stub with no output schema, the description covers the crucial 'not yet served' status. It is still incomplete about the observable result of a call and how the recorded requirement surfaces, which is what an agent needs to decide between this and request_data or find_capability.

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, though the schema itself only repeats the field name 'vat'. The description adds no format guidance (country prefix, spacing, length expectations) beyond the schema, so the baseline 3 applies.

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

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

The description names a specific resource and capability (VIES VAT validation with provenance), which is more than a restatement of the name. However, it immediately undercuts that purpose with 'Roadmap probe, not yet served', leaving ambiguity about whether the tool validates VAT or merely logs intent. An agent can guess the domain but not the actual verb that will execute.

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?

'Calling records the requirement' hints at a demand-signal use, but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives. Siblings like find_capability and request_data plausibly cover the same 'express a need' role, and the description never differentiates.

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?

With no annotations, the description carries the full burden and does disclose the critical, non-obvious trait: this is a stub whose only effect is recording a requirement, not returning authorisation data. It stops short of saying what a call actually returns (confirmation, error, empty payload), which matters for an agent deciding whether to 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 the implementation status front-loaded before the subject matter. Nothing is padded and the critical caveat comes first.

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 zero-side-effect stub with no output schema the description covers the essentials (unimplemented, records demand), but it leaves the agent unsure what a call returns and whether a real alternative exists in the sibling set, which matters given the array of registry tools available.

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% (frn, firm), so the baseline is 3. The description adds only the notion of firm or individual lookup, and there is no 'individual' parameter, so that phrasing is slightly mismatched; it also does not say whether frn or firm should be preferred, or why no parameter is required. Given zero required params, guidance on calling with an empty payload would have helped.

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 (FCA register authorisation status for a firm or individual) but immediately reframes it as an unimplemented placeholder. An agent can tell what the tool would do and that it currently does not serve results, though the phrase "roadmap probe" is internal jargon and no sibling is 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?

"Not yet served" and "calling records the requirement" imply when this should be called (demand signalling, not real lookups), but there is no explicit when-not statement or named alternative such as request_data for actually obtaining the data. Routing is left 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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the search covers both live and planned capabilities, but it does not explain result format, limits, authentication, or how planned results are distinguished from live ones.

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

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

The description is only two short sentences and is front-loaded with the search action. The second sentence is somewhat vague, but the overall structure is appropriately concise.

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

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

With no annotations and no output schema, the description should do more to explain what a capability result contains and how live versus planned capabilities are represented. It also lacks enough context to help an agent choose it over 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?

The single query parameter has 100% schema description coverage, and the schema states 'What data or verdict you need'. The description adds no parameter-level 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?

The description states a search operation on data capabilities, but 'data capability' and 'honestly planned' are abstract, and 'Searches inform build priority' muddies rather than clarifies the tool's purpose. It does not differentiate the tool from siblings such as request_data or the registry lookup tools.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'Searches inform build priority' hints at context but is too vague to route an agent between find_capability and tools like request_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?

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses that the tool is not yet served, that calling it records a requirement, and that it returns 'not-covered'. This is exactly the kind of non-obvious behavior an agent must know before invoking the tool.

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

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

The description is two sentences, front-loads the critical 'Roadmap probe, not yet served' warning, and contains no wasted text. Every sentence contributes to correct tool selection and invocation behavior.

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 low-complexity roadmap probe with full schema coverage and no output schema, the description is complete enough: it explains what the tool would do, that it is not yet available, and what happens when called. No critical information is missing for an agent to make the right decision.

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 three parameters are already documented in the schema. The description does not add parameter-level meaning beyond what the schema provides, which is acceptable given full schema 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?

The description clearly states the intended resource and scope: a single-call KYB verdict covering existence, active status, officers, PSC, sanctions, and insolvency. It also immediately qualifies that this is a roadmap probe, not a served capability, which prevents misselection. It does not explicitly name sibling alternatives, so it falls 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?

The phrase 'Roadmap probe, not yet served' gives clear usage context and effectively warns the agent not to rely on it for real KYB checks. 'Calling records the requirement and returns not-covered' further clarifies the outcome of invocation. However, it does not explicitly route the agent to the individual sibling tools that currently provide these checks.

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?

With no annotations, the description carries the burden and does add real context: it is a lookup against an external API, sourced under CC0, with provenance attached, and it names the returned fields. It does not cover not-found behavior, rate limits, authentication, or whether a name search can return multiple candidates.

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: capability and access modes first, return payload second, provenance last. Every clause adds 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?

There is no output schema, so the description usefully enumerates the return fields and notes provenance/licensing. The remaining gap is the invocation constraint (zero required params, so presumably at least one of lei/name must be supplied) and multi-result behavior on name search.

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% (both params documented, including the 20-character LEI constraint), so the schema does the heavy lifting. The description's 'by LEI or by name' hints that the params are alternative lookup keys, but it never says whether both may be supplied or which wins — a meaningful gap the schema leaves open.

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: resolve a legal entity to its LEI via the GLEIF API, with both lookup modes named. It is clearly distinct from screening tools like sanctions_screen or pep_screen, though it does not explicitly distinguish itself from cross_registry_resolve or entity_match.

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?

'By LEI or by name' implies two usage modes but never states when to prefer one over the other, nor when to reach for a sibling like entity_match or cross_registry_resolve instead. Usage is inferable from the tool's purpose but no alternatives 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?

With no annotations, the description carries the full burden and does so well: it discloses that the capability is not served, that the call has a side effect (recording the requirement), and that the return is a structured not-covered response. This is exactly the behavioral context an agent needs to avoid mistaking the result for a real PEP match.

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 the critical qualifier ('Roadmap probe, not yet served') front-loaded before any details. No wasted text.

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 stub tool with no output schema, the description covers the essential behavior and the alternative route. The only gap is that the shape of the 'structured not-covered response' is not described, which an agent might want when parsing the result.

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%, but the schema descriptions are tautological ('name', 'country'), so structured fields add little meaning. The description itself says nothing about name or country semantics, so the baseline 3 for high schema coverage 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 (PEP screening) and immediately qualifies the tool as an unimplemented roadmap probe. It also names the live sibling path (sanctions-only screening), so an agent can distinguish this stub from sanctions_screen without opening either schema.

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

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

Explicitly tells the agent what calling does ('records the requirement', returns a structured not-covered response) and routes real screening to the live alternative at /v1/screen/sanctions. There is no ambiguity about when this tool is and is not 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?

With no annotations, the description carries the full burden and does disclose the critical trait: the tool is not yet served, so calling it produces no filing data and instead records a requirement. That is exactly the kind of side-effect disclosure an agent needs before invoking. It stops short of saying whether the call errors, returns an empty payload, or has any rate/side-effect 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 clauses with the most decision-relevant fact ('not yet served') front-loaded, followed by what the tool would do and what a call actually accomplishes. No filler; only minor redundancy between 'roadmap probe' and 'not yet served'.

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 stub with no annotations and no output schema, the description covers the essential caveat, but leaves open what an agent observes on invocation (error vs. acknowledgement) and offers no guidance on filing_type values. Enough to avoid a wrong expectation, not enough to plan a workflow around it.

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 nominally 100%, so the baseline of 3 applies, but the schema descriptions are tautological (the field names repeated verbatim). The tool description adds nothing about what filing_type accepts or which Companies House filing categories are valid, so the agent learns no more than the field names.

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 (fetch and parse a Companies House filing into structured JSON) and immediately qualifies it as an unserved roadmap probe. An agent can tell this is about company filings rather than, say, sanctions or director data, though it is not differentiated from the closest sibling (uk_company_profile) which may also surface filings.

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?

'Roadmap probe, not yet served' plus 'Calling records the requirement' implies the usage: call it to register demand, not to obtain data. But it never says what to use instead when actual filing content is needed, and no sibling is named as the fallback.

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?

With no annotations present, the description carries the full burden; it does disclose two genuinely useful traits (the request is free, and it is logged), which is more than nothing. It never says whether anything is returned, how long a response takes, or that no immediate data or verdict comes back, leaving an agent to possibly expect a synchronous result.

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 clauses, front-loaded with the core action and followed by the cost/logging qualifier, with no filler. Slightly wasted space because the field enumeration in the first clause largely restates 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?

For a 5-parameter, annotation-free, output-schema-free intake tool, the description should clarify the response contract (confirmation only? ticket reference? follow-up via the contact field). It explains cost and logging but not the outcome, so the agent cannot fully predict what calling it produces.

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 baseline is 3. The description recasts volume as 'expected monthly volume' and price as 'acceptable price', which adds modest meaning over the schema's tautological placeholders (the schema literally repeats 'volume_per_month' and 'max_price_usd' as descriptions), but it omits the optional contact parameter entirely.

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 action (submit a data requirement with use case, volume and price) and adds the key qualifier 'Free and logged to inform build priority', which tells the agent this is a demand-capture request rather than a data-returning lookup. It does not, however, distinguish itself from siblings such as find_capability, which an agent might reasonably reach for instead.

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: 'logged to inform build priority' suggests this is for data/capabilities not yet available, but there is no explicit when-to-use statement and no named alternative. The agent must infer that find_capability should be tried first and this tool used only as an escalation.

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?

With no annotations, the description carries the load and does well: it discloses data provenance (primary government sources), configurability of list sets, and the exact response shape (verdict, candidate hits with scores, list versions, retrieval timestamps). It omits practical traits such as threshold defaults, latency, or whether lists are cached/refreshed and how often.

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

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

Three tight sentences: purpose first, source scope second, return payload third, exclusions last. No filler, and the most decision-relevant information is front-loaded before the boundary clause.

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

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

No output schema exists, and the description compensates by enumerating the return payload (verdict, scored candidate hits, list versions, timestamps), which is exactly what an agent needs. The remaining gap is the unspecified default and tuning behavior of the optional threshold 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 100% and both parameters are documented in-schema, so the baseline of 3 applies. The description's reference to 'scores' loosely connects to the threshold parameter but adds no default value, tuning guidance, or interpretation of threshold 0..1 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?

States a specific verb and resource ('Screen a person or entity name against sanctions lists') plus the exact data provenance (OFAC SDN/consolidated, UK Sanctions List). The closing clause explicitly rules out PEP and adverse-media screening, routing the agent away from pep_screen and adverse_media siblings, and the 'person or entity' scoping implicitly distinguishes it from vessel_sanctions.

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 negative boundary ('Not a PEP or adverse-media screen') that names the alternative tools to use instead, and the source-list enumeration tells the agent what coverage to expect. It stops short of stating positive trigger conditions (e.g., onboarding/KYC screening) or prerequisites, so it is clear context without full when/when-not guidance.

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

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

With no annotations present, the description carries the full burden and does disclose non-obvious traits: results are cached up to 24 hours, provenance is attached, and officers are capped at the first page (~35) with explicit total/coverage metadata so truncation is detectable. It does not state authentication requirements, rate limits, or behavior when a company number is not found.

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

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

A single dense sentence that front-loads the resource and then the returned fields, with no filler. Every clause (officer cap, coverage metadata, cache TTL, provenance) contributes 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?

There is no output schema, so the description must describe returns, and it does so thoroughly, including pagination and freshness. For a one-parameter tool this is close to sufficient; only failure modes and auth expectations are 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?

Only one parameter exists and the schema documents it at 100% coverage ('Companies House number'), so the baseline is 3. The description confirms the parameter is a company number but adds no format guidance (numeric vs prefixed, e.g. SC/OC prefixes) beyond the schema.

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

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

The description names a specific resource and enumerates exactly what it returns: status, SIC codes, registered office, accounts/confirmation dates, and first-page officers. That field list implicitly separates it from uk_company_search (search) and uk_psc_ubo (ownership), but no sibling is named explicitly, so it falls just 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?

'Primary source' implies this is the default canonical lookup rather than a cross-registry fallback, which is a useful hint. However, there is no explicit when-to-use/when-not guidance, and no routing to complementary siblings like charge_register, uk_psc_ubo, or uk_insolvency_notices for data this tool does not cover.

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?

With no annotations, the description carries the full burden and does disclose real behavioral traits: results carry provenance and a retrieval timestamp, and responses may be cached for up to 24 hours, so the agent knows data can be stale. It omits auth requirements, rate limits, and error/empty-result behavior, which keeps it from 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 sentences, front-loaded with the action and resource, then the return shape and freshness caveat. Every clause carries information; the return-field list is long but justified because there is no output 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 no output schema, the description usefully enumerates return fields and notes caching and provenance, which is what an agent needs to interpret results. Missing pieces are authentication, rate limits, and the distinction from the sibling profile tool, so it is strong but not 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?

Schema description coverage is 100%, so both parameters ('q' as company name or number, 'limit' as max results) are already documented in the schema. The description adds only marginal meaning, restating the name-or-number duality of 'q'; 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: 'Search the UK Companies House register by name or number.' It also enumerates the returned fields (number, status, type, incorporation date, registered address), so an agent knows exactly what it gets. It does not distinguish itself from the sibling uk_company_profile, which is the plausible search-vs-detail alternative, 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?

The phrase 'Primary source with retrieval timestamp; cached for up to 24 hours' implies this is the canonical/preferred lookup, which is weak usage guidance. However, there is no explicit statement of when to use this versus uk_company_profile or cross_registry_resolve, and no exclusions or prerequisites 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?

With no annotations, the description carries the full burden and does well: it discloses the side effect (calling records a requirement), the return state ('not-covered'), and the pricing model ('per delta'). It does not describe the shape of the not-covered response beyond its status, but the essential behavioral facts are present.

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

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

A single compact sentence with the most decision-relevant fact ('Roadmap probe, not yet served') front-loaded, followed by scope, cost, and call behavior. No filler.

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

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

For a stub with one parameter, no annotations, and no output schema, the description covers what the tool would do, what calling it actually returns, and its cost model. It is complete enough that an agent will not misinvoke it expecting real director data.

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

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

Schema coverage is nominally 100%, so baseline is 3, but the schema's only description is the literal string 'company_number' with no added meaning. The tool description says 'per-entity' without ever explaining that company_number identifies the entity being monitored, so it neither helps nor hurts.

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: a per-entity change feed for officer appointments and resignations, and immediately flags it as an unserved roadmap probe. The resource ('officer appointments and resignations') distinguishes it from siblings like uk_company_profile and uk_psc_ubo, though it does not name them directly.

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

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

'Roadmap probe, not yet served' plus 'Calling records the requirement and returns not-covered' makes the intended usage explicit: call it only to register demand, not to obtain data. It stops short of naming an alternative tool an agent should use instead for actual director data, so it is one step from 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?

No annotations are provided, so the description carries the full burden, and it discloses the single most non-obvious trait: this endpoint is unimplemented and invoking it has a side effect (recording a requirement). It does not describe what the call actually returns (error, acknowledgement, empty payload), which is the remaining gap for an unannotated tool.

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 clauses with the critical caveat front-loaded before any promise of capability — exactly the right ordering for a stub tool. No filler sentences.

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 probe with no output schema and no annotations, the description covers the decisive fact an agent needs before calling. The only omission is the shape of the response after 'Calling records the requirement', which would fully close the loop.

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 nominally 100%, so the baseline is 3, but the schema 'descriptions' are literally the parameter names ('name', 'company_number'), adding no semantics. The description's phrase 'for a monitored entity' only hints that the pair identifies an entity; it does not explain whether both are needed (required count is 0) or how they relate.

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 ('structured Gazette insolvency notices ... per event') for a specific scope ('a monitored entity'), which distinguishes it from siblings like adverse_media or charge_register. The leading qualifier 'Roadmap probe, not yet served' reframes what the tool actually is, but the substantive purpose is still legible.

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

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

It tells the agent the essential usage fact — calling it does not retrieve notices, it records a requirement — which prevents wasted calls or misinterpretation of an empty result. However, it never says what to do instead when insolvency data is actually needed; with siblings like request_data or registry_doc_fetch present, an explicit pointer 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?

As there are no annotations, the description must carry the full load of operational transparency. It fails to disclose critical behavioral aspects such as data latency, data accuracy, or whether the 'serving' state implies a guaranteed operational status for the agent.

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 two-sentence structure is inefficient. The first sentence is an unnecessary, overly detailed internal developer note ('Roadmap probe, not yet served') that is verbose and irrelevant to the agent's task.

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

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

The description provides adequate context by naming the data source ('Find a Tender OCDS data') and the target information (supplier contracts). For a simple lookup tool, this meets the minimum viable 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?

The schema coverage is 100% for a single parameter ('supplier'). The description simply repeats this information within the context of the tool's function, providing no semantic value beyond what the structured schema already provides. Baseline score is appropriate.

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

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

The description clearly states the function is to retrieve contract awards for a supplier from specific data sources (Find a Tender OCDS data). However, the opening phrase, 'Roadmap probe, not yet served,' adds informal meta-commentary that slightly detract from the direct functional purpose.

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 offers no guidance on when this tool should be preferred over other lookup tools (e.g., searching company profiles or sanctions lists). It lacks explicit usage constraints or 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?

With no annotations, the description carries the full burden and does well: it discloses that the capability is not yet served, that calling it records the requirement, and that the return is a structured not-covered response. It does not detail what recording the requirement entails, but the key behavioral surprise is clearly surfaced.

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

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

The description is a compact pair of clauses, with the critical status (not yet served) front-loaded. Every phrase contributes to explaining the tool's stub nature and its side effect.

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 stub with no output schema, the description gives the essential context: no real resolution data is returned and a structured not-covered response is produced. It could specify the response fields more concretely, but nothing critical 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?

The schema has 100% description coverage for the single company_number parameter, so the parameter is already documented structurally. The description does not add format or meaning beyond what the schema provides, which is the expected baseline when schema coverage is complete.

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 (UK beneficial-ownership chain from PSC data) and explicitly labels the tool as a roadmap probe that is not yet served. It does not explicitly name sibling alternatives such as request_data or find_capability, but the non-functional status is clear enough for an agent to understand what this tool does.

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

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

The description implies usage by saying that calling it records a requirement and returns a not-covered response, which tells the agent when the tool is applicable. However, it does not say when to avoid it or point to an alternative for recording capability requests, leaving routing against request_data and find_capability 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?

With no annotations, the description carries the full burden and does the most important thing: it discloses up front that the tool is unimplemented and that invoking it merely logs demand, preventing an agent from treating a call as a real screening result. It stops short of saying what the call actually returns or errors with, and it names a 'flag' input that the schema does not contain.

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 decisive caveat ('not yet served') placed first rather than buried. 'Roadmap probe' is slightly jargon-y but earns its place by compressing the stub status.

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 2-parameter, no-output-schema, no-annotation tool, the description covers the essential fact that the capability is absent. It leaves open what a call returns, whether the recorded requirement is visible anywhere, and what to do instead, which matters for an agent deciding whether calling has any value.

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 two parameters (imo, name) are documented by the schema and a baseline 3 applies. The description adds little beyond echoing IMO and name, and its mention of 'flag' refers to an argument that does not exist in the schema, a small source of confusion rather than added meaning.

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 ('screen a vessel ... against sanctions designations') and lists identifying inputs, so it is distinguishable from the sibling sanctions_screen by subject (vessel vs. entity/person). The qualifier 'Roadmap probe, not yet served' immediately signals the capability does not exist yet, which reframes purpose as requirement capture rather than 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?

'Calling records the requirement' implies the only useful action and hints the tool is a demand-signal channel, which is adequate implied usage. However, it never names an alternative (e.g. find_capability, request_data, or sanctions_screen for non-vessel subjects), so an agent must infer what to do when a real vessel screen is needed.

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