WhiteIntel — Ownership Intelligence

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

With no annotations, the description carries the full transparency burden. It discloses that Stripe collects an email for delivery, returns a checkout_url and next_steps, and requires the session_id to be fed to claim_dossier afterward. This gives a clear picture of the guest checkout behavior without access to structured safety hints.

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

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

The description is dense but well-structured: the main action and key differentiator (guest, no account) are front-loaded, with pricing in compact parentheses and next steps clearly separated. Every sentence earns its place with no filler.

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

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

There is no output schema, so the description explains the return value (checkout_url + next_steps) and the exact follow-up action for the agent (open URL, then feed session_id to claim_dossier). It also references get_pricing for the full list, making this sufficiently complete for a checkout-initiation tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains tier options with pricing and inclusions ('standard' €39 full UBO chain + financial history · 'premium' €99 additionally itemised assets), describes pack as an optional bulk pack ('5'/'25'), and clarifies entity_id as 'the entity_id the report is for'. However, entity_name is not explained, leaving one parameter semantically uncovered.

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 action: 'Start a one-off dossier purchase via guest Stripe Checkout' — a clear verb, resource, and mechanism. It also distinguishes itself from sibling tools like get_dossier and get_pricing by framing this as initiating a purchase flow rather than retrieving reports or listing prices.

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 clearly states the guest/no-account use case and directs users to 'See get_pricing for the full list' for pricing details. It also references claim_dossier to explain the follow-up step, giving clear context on when this tool fits into the overall flow, though it doesn't explicitly state when not to use 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, the description carries the full burden. It states the core action (walking the ownership chain) and the result (flagging hops), but does not disclose whether it is read-only, what the output format is, whether it modifies anything, or any performance/rate implications. The action is not destructive, but this is only implied by the verb 'check' and the description does not explicitly confirm safety.

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 single, compact sentence with no filler words. It is front-loaded with the action ('walk the ownership chain') and conveys core intent efficiently. Despite its brevity, it does not waste words and 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?

The tool is moderately complex (ownership chain traversal, sanctions/secrecy flagging) and has no annotations, no output schema, and 0% schema coverage. The description is only one sentence and does not explain what constitutes a 'hop', how flags are presented, what the returned data looks like, or how to interpret the result. This is far from complete for an agent to use reliably.

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% and the description does not mention the parameters 'id' or 'max_depth' at all. An agent must infer that 'id' likely refers to an entity identifier, but 'max_depth' (likely the depth of the ownership chain to traverse) is entirely unexplained. The description provides no semantic context for these fields, failing to compensate for missing schema documentation.

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 ('Walk the ownership chain') and resource ('ownership chain') clearly stating the tool's function: flagging sanctioned and secrecy-jurisdiction hops. It clearly differentiates from sibling tools like graph_path or trace_ownership_path by focusing on sanctions and secrecy jurisdictions, and even names the lead type ('offshore-layering').

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 'the offshore-layering lead' implies the intended use case, but there is no explicit when-to-use, when-not-to-use, or mention of alternative tools. It offers a hint of context but does not actively guide selection among the many sibling navigation and lookup tools.

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 full burden. It discloses idempotency ('Idempotent'), error behavior ('fails with 402 not_paid until payment completes'), and return shape ('Returns { token, entity_id, tier }'). This is rich behavioral context beyond what any schema could convey, making the tool's behavior predictable.

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 three sentences, front-loaded with the purpose, then input, then return/behavior. Every sentence adds essential information with no fluff or repetition. It is concise while covering all necessary aspects.

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

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

Given the tool has only one parameter and no output schema, the description is complete. It explains when to call (after buy_dossier and payment), what to pass (session_id), what to expect (token, entity_id, tier), and error handling (402). It also references the downstream tool (get_dossier), making the entire flow clear.

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 only lists session_id as a string with no description. The tool description adds significant meaning by identifying the format (cs_…), the source (post-payment redirect after buy_dossier), and its role in the redemption flow. This fully compensates for the 0% 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 states the exact purpose: 'Redeem a paid Stripe Checkout session for a dossier access token.' It clearly identifies the action (redeem), the resource (Stripe checkout session), and the outcome (dossier access token). It distinguishes itself from siblings like buy_dossier and get_dossier by focusing on the redemption step after payment.

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 provides explicit usage instructions: pass the session_id from the post-payment redirect after buy_dossier, and wait for payment completion before calling again due to 402 errors. It also specifies the next step (pass the token to get_dossier), giving clear context on when to use this tool versus 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 appropriately discloses partial coverage and that entities outside the subset return empty instead of error, setting expectations. It also implies read-only behavior and mentions the underlying risk-scored subset. Could add more on how similarity is computed, but the essential caveat is 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?

Two concise sentences, front-loaded with purpose, then a clarifying caveat. No wordiness; every sentence adds value.

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

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

Given no output schema, the description covers the input necessity, the outcome (similar dossier cards), and the coverage limitation. It is sufficient for a simple retrieval tool, though it could elaborate on the meaning of 'similar' (e.g., embedding-based) for better expectation setting.

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% (no param descriptions in schema). The description explains entity_id via 'Pass an entity id from search_entities / semantic_search', which is helpful, but it does not describe the optional k parameter (likely number of results). This leaves a gap, so it partially compensates but not fully.

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

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

The description specifies a clear, unique purpose: finding similar entities via 'more like this' for peer discovery, explicitly distinguishing it from search tools. It names the resource (entities/dossier cards) and the action (find similar), and even mentions the input source.

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

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

It provides clear context: use it for peer discovery after obtaining an entity id from search_entities/semantic_search. However, it does not explicitly mention when NOT to use it or compare to alternatives, but the input prerequisite is helpful.

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 of explaining the tool's nature. It portrays a read-only lookup of registration data, listing specific contents like overdue filings and charges, which gives useful context. However, it does not disclose response behavior, error conditions, data freshness, or whether underlying external data sources are used.

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 single, focused sentence with a front-loaded purpose and a concise list of included data elements. Every word contributes meaning, and it avoids unnecessary elaboration.

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 with one parameter and no output schema, but the description only gives a high-level list of content categories. It does not describe the returned data structure or whether the data is a summary, a list, or a full dossier. The description is adequate for a simple profile but leaves some uncertainty about return format.

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 exposes only one required parameter, id, with no description and schema coverage is 0%. The tool description refers to 'a company', which implies id identifies a company, but it does not clarify the id format, source, or how to obtain valid ids. The description adds minimal value 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 clearly states that the tool returns a registered company profile, listing specific data categories (address, status, SIC, incorporation, filings). It does not use a verb, but the tool name and content make the purpose obvious. It is broadly distinguishable from siblings like get_financials or get_sanctions, though less so from get_dossier.

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

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

The description implies the tool is appropriate for retrieving a company's registered profile and compliance details, but it provides no explicit guidance about when to choose this over siblings like get_dossier, get_entity, or lookup_company. There are no when-to-use or when-not-to-use statements.

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 available, the description carries the burden and discloses a key access model: a token from claim_dossier unlocks the full paid depth, implying a preview/full-content tier. It also promises that results are 'fully-cited', setting expectations about return quality. It does not address rate limits or error states, but the main paid-depth behavior is clearly stated.

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 entire description is a single focused sentence that leads with the output definition and ends with the token instruction; no filler or redundant qualifiers.

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 enumerates the main output categories (identity, UBO, risk, financials, provenance) and the token's effect, which is useful given there is no output schema. It does not detail response structure, pagination, or failure modes, but for a dossier retrieval tool this is a reasonably complete picture.

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 already describes the token parameter, so the tool description only repeats that behavior without adding new syntax. The required `id` parameter has no schema description, and the tool description only indirectly implies it is the entity identifier, without specifying the expected format or source.

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

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

The description specifies a 'structured, fully-cited dossier for one entity' and lists exact content domains (cross-source identity, ownership/UBO chain, risk signals, filed financials, provenance), making the tool's function clear and differentiating it from sibling entity tools like get_company_details or get_financials.

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 directly instructs the caller to pass the token from claim_dossier to unlock the purchased depth, establishing a clear two-step workflow. It does not explicitly mention alternatives or when not to use, but the token instruction and scope ('one entity') give solid situational context.

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

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

No annotations are provided, so the description must disclose behavioral traits, but it does not mention any side effects, such as whether the operation is read-only, requires authentication, or has rate limits. It also does not clarify if relationships are limited in depth or if provenance implies any special data handling. The description is too terse to be transparent.

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 extremely concise, a single phrase, and front-loaded with the core purpose. It is not verbose, which is good, but it may be too sparse to be fully effective. Still, the structure is appropriate for a simple tool.

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

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

With one simple parameter and no output schema, the description is minimal but could suffice for a basic retrieval. However, the context signals show 19 sibling tools, many of which are similar (e.g., get_dossier, get_company_details, graph_neighbourhood), and the description does not differentiate from them. It also does not mention the shape of the return (relationships, provenance) in detail, so the agent may not know what to expect.

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 only one parameter with no description, and the schema description coverage is 0%, so the description must compensate. The description mentions 'entity id' but does not elaborate on what format the ID should take (e.g., UUID, URL-encoded identifier) or whether it is the same as identifiers used in lookup functions. This is a clear 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 states the tool retrieves a full record for a given entity ID along with direct relationships and provenance, which is specific about the resource (entity) and the action (get full record with relationships). However, it does not clearly distinguish this from siblings like get_dossier, get_company_details, or lookup_entity, which might also fetch entity data, leaving some ambiguity.

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 mention of when to use this tool versus alternatives. The description does not specify that it is suitable for initial entity lookups or for retrieving full relational data, nor does it exclude scenarios like searching by name (lookup_company, semantic_search) or exploring graph connections (graph_neighbourhood). Without any guidance, the agent is left to guess.

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. It adds content details such as 'year-over-year' and 'iXBRL' but does not disclose operational behavior like read-only safety, return format, or any prerequisites. This is a gap for a tool with no annotation support.

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 single concise sentence, front-loaded with the core purpose and key details (fields, year-over-year, source). Every word adds value with no filler.

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

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

For a one-parameter tool, the description conveys the primary output but omits the meaning of the required 'id' parameter and any behavioral context. It is minimally adequate for an agent to understand the tool's purpose but lacks enough detail for confident invocation.

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 input schema defines a single 'id' parameter with no description, and the tool description does not clarify what 'id' represents (e.g., company ID, filing ID). With 0% schema description coverage, the description fails to compensate, leaving the parameter ambiguous.

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 tool returns filed financials with year-over-year data, listing specific fields (turnover, profit, net assets, cash, employees) and source (Companies House iXBRL). This distinguishes it from sibling tools like get_company_details by its financial focus.

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

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

The description implies the tool is for retrieving financial statements but does not explicitly state when to use it over alternatives or provide exclusions. It relies on the tool's name and sibling context rather than explicit 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?

No annotations are provided, so the description carries the burden. It discloses that links never expire, can be reused, and require no API key or WhiteIntel account. However, it does not mention any side effects or what happens upon redemption, but the known behavior 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?

The description is a single paragraph but well-structured, front-loading the key distinction and then giving practical usage details. Every sentence earns its place, conveying purpose, usage, and parameter behavior without fluff.

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

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

Given no parameters, no output schema, and no annotations, the description fully covers what an agent needs: what the tool does, when to use it, how to bind purchases, and prerequisites. The sibling buy_dossier is referenced for contrast, making it complete in context.

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 are zero parameters, so schema coverage is trivially 100%. The description adds significant meaning by explaining the optional query parameter ?client_reference_id=<entity uuid> and its effect (binds purchase to a company vs. generic credit), which is not in the schema.

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

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

The description clearly states the tool provides permanent, shareable Stripe payment links for one-off dossiers, and explicitly contrasts it with buy_dossier. This distinguishes it from siblings and gives a precise resource and action.

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 explicitly says to use this instead of buy_dossier when you need something to hand to a human, explains why buy_dossier is unsuitable, and notes the optional client_reference_id binding. This provides clear when-to-use and when-not-to-use 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 provided, the description fully carries the behavioral burden. It discloses that the tool is static and makes no network calls, and it specifies the return value ('how_an_agent_buys'), providing a clear and honest behavioral contract.

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 deliver pricing details, the buying flow, return structure, and operational characteristics without wasted words. It is front-loaded with the core resource and readable at a glance.

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-parameter static tool, the description covers purpose, output, and usage guidance completely. The absence of an output schema is compensated by the explicit explanation of what is returned and how it fits into the broader purchase workflow.

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 zero parameters, so baseline is 4. The description adds valuable context about the pricing content and the purchase flow, though no parameter-level detail is necessary.

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 it provides WhiteIntel's price list and the exact machine flow for buying access. It distinguishes itself from siblings by explaining the buy_dossier/claim_dossier/get_dossier sequence, making its scope unambiguous.

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

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

Explicitly instructs the agent to 'check it before recommending a purchase', and clarifies when to use this tool relative to purchase-related siblings. The note 'Static, no network' also signals it is a safe, preliminary lookup.

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 transparency burden and does a good job: it reveals default filtering, citation behavior, the watchlist opt-in caveat, and the fact that watchlist rows have source-url NULL. It does not explain response format or pagination details beyond next_since, but it does disclose the key behavioral surprises.

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 single focused paragraph where every sentence earns its place: it defines the feed, gives streaming usage, describes default citation behavior, and flags the watchlist special case. There is no vagueness or repeated schema 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?

Given the shallow schema and no output schema, the description covers the essential invocation details: default behavior, streaming via since, watchlist caveats, and citation semantics. The only notable gap is the undocumented 'limit' parameter, but its name and type are reasonably self-explanatory against the overall feed use case.

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

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

The schema provides no descriptions (0% coverage), and the description adds semantic value for 'since' as a streaming cursor and for 'kind=watchlist' as an opt-in. However, 'limit' gets no explanation, and the ownership/filing values for 'kind' are only implied by the feed's event-type context, leaving the schema burden partially unresolved.

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 identifies the tool as the corpus activity feed, listing the specific event types (ownership-change, filed-accounts, watchlist). It also notes the citation behavior and streaming parameter, making the tool's purpose concrete and easy to distinguish from the many search and lookup siblings.

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

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

The description provides practical usage context: pass since=next_since to stream new events, the default feed includes only events with source URLs, and watchlist must be explicitly requested via kind=watchlist. It does not state 'when not to use' alternatives, but no sibling tool is an obvious alternative feed, so the guidance is adequate.

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 present, so the description carries full burden. It mentions 'each cited' but does not state that the operation is read-only, any potential side effects, or error conditions. Lacks explicit disclosure of behavioral traits like data scope or citation format.

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 extremely concise, one sentence that directly conveys the core functionality. No redundant words or unnecessary details, making it efficient and easy to parse.

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

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

Given the lack of an output schema, the description gives only a hint of the return content ('each cited'), but does not describe the overall structure, fields, or any limitations. It is adequate for a simple get operation but leaves room for more detail on what data is included or how it is formatted.

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 'id' is in the schema with no description. The description references 'entity' but does not clarify what the id represents (e.g., entity ID, company ID) or its format. The meaning of 'resolved cluster siblings' is also left ambiguous, leaving the parameter semantics under-specified.

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?

Description clearly states the tool returns sanctions data (OFAC/EU/UN/UK) for an entity and its cluster siblings, with citations. The verb 'get' plus specific resource 'sanctions' makes the purpose unambiguous and distinct from siblings like get_company_details or search_companies.

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 when sanctions information is needed, but does not explicitly contrast with alternative tools (e.g., check_offshore_exposure). No guidance on when to prefer this over other lookup tools is provided, though the specific scope ('sanctions' and 'cluster siblings') offers some implicit context.

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

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

With no annotations provided, the description fully carries the behavioral disclosure. It reveals hard caps (depth 3, 300 edges, 25 edges per entity per direction per hop), explains the truncated flag, and normalizes it for hubs with a concrete example (22,000+ edges). This is exemplary transparency.

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 densely packed with essential information: purpose, constraints, and behavioral expectations. It is structured logically—first the main function, then limits, then the interpretation of truncation. Every sentence contributes, with no fluff, though it is longer than typical tool descriptions.

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

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

Given the complexity of the tool and no output schema, the description covers key aspects: what it returns (edges in both directions), the caps, and the truncated flag. It doesn't detail the exact output format, but it conveys enough for an agent to understand the tool's behavior and typical outcomes. A small gap remains on the full response structure.

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

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

Schema coverage is 100% for all 3 parameters, so the baseline is 3. The description adds value by explaining that depth and edges are also capped by the database and the caller's plan, and by clarifying what the edge budget means in practice (truncation). This goes beyond the schema's basic descriptions.

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 tool's function: retrieving ownership/control edges in both directions within a bounded hop count. It specifies the resource (ownership/control edges) and the scope (neighbourhood, both directions), distinguishing it from sibling tools like graph_path or trace_ownership_path that focus on paths.

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 clear context: it's for exploring a neighbourhood around an entity with limits. However, it doesn't explicitly contrast with alternative tools (e.g., graph_path) or state when not to use it, leaving some inference to the agent. The mention of truncation for hubs provides practical guidance on interpreting results.

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 burden of behavioral disclosure. It transparently states the bounded nature (at most 15 edges per entity per direction per hop), the non-exhaustive guarantee, and the fact that exhaustive is always false. It also discloses the performance cost of depth 4. This exceeds what ordinary descriptions provide and fully informs the agent of the tool's limitations.

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 single, dense sentence that starts with a clear purpose and then delivers a crucial caveat with an emoji warning. It is front-loaded and avoids fluff, but the long sentence could be split for readability. Every clause earns its place, so it is appropriately concise without being under-specified.

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

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

Given no output schema, the description covers key return information (e.g., exhaustive: false) and explains the meaning of found: false within bounds. It does not detail the structure of 'ordered hops', but that is likely straightforward. The main risks (bounded search, performance) are fully addressed, making the description adequate for selecting and invoking the tool.

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

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

Schema coverage is 100% for all three parameters, so the baseline is 3. The description adds extra context for max_depth ('Depth 4 is measurably slower... — ask for it deliberately'), which goes slightly beyond the schema's 'Hops, 1–4 (default 3)'. However, from/to are already adequately described as 'Entity uuid.' in the schema, so the description does not substantially enhance parameter semantics beyond that note.

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?

Description clearly states the tool reveals how two entities are connected via a bounded breadth-first search over ownership and control edges. It is distinct from siblings like graph_neighbourhood (neighbourhood exploration) and trace_ownership_path (likely a specific traversal), and the phrase 'how two entities are connected' makes the resource and action unambiguous.

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

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

The description provides critical usage context: it explicitly warns that the search is bounded, that 'found: false' does not imply unconnected, and that the response always carries 'exhaustive: false', cautioning against reporting negative results as a clean bill of health. It also notes performance implications of max_depth=4. However, it does not explicitly compare to alternatives like graph_neighbourhood or trace_ownership_path, so it lacks explicit when-not-to-use 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 provided, the description carries full behavioral burden but only states the action. It does not disclose what 'resolve' returns (full entity, minimal metadata), failure behavior (e.g., not found), or any rate limiting/auth requirements. The only extra context is the format note for br-cnpj, which is semantic rather than behavioral.

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 single, front-loaded sentence that immediately conveys the purpose, followed by a compact enumeration of valid identifiers. Every word contributes; there is no fluff or repetition.

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

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

Given the tool's low complexity (2 params, no output schema), the description provides the essential action and identifier list. However, it lacks guidance on result structure, error handling, or disambiguation from the sibling 'resolve' tool, making it less complete for an agent that must select among many similar endpoints.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'br-cnpj' scheme (root vs full format) and clarifies 'value' as the identifier. However, it merely repeats the enum values for most schemes without explaining their format or nuances, leaving room for ambiguity.

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 action ('Resolve a corpus entity') and the resource/scope ('by a strong identifier'), enumerating a specific list of identifier schemes. This distinguishes it from sibling tools like lookup_company or search_entities, which are typically name- or search-based.

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

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

The description implies when to use the tool: when you have one of the listed strong identifiers. However, it does not explicitly mention alternatives or when not to use it, such as distinguishing from the 'resolve' sibling tool or advising against using it for partial/fuzzy identifiers.

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. It discloses that the output includes a record and a ready-built ownership graph, which indicates a read operation and output structure. However, it does not mention any side effects, permissions, or limitation (e.g., whether it works for non-UK companies, rate limits, or error conditions). Some value added but not deep.

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 extremely concise, using a single arrow-oriented sentence that front-loads the core action and output. No wasted words; every element adds value.

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

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

With only one parameter and no output schema, the description adequately outlines the purpose and output ('record + ready-built ownership graph'). It is complete enough for a simple lookup tool, though it doesn't elaborate on what the 'record' contains or graph details. For its complexity, it's sufficiently informative.

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 only defines 'number' as a string with no description. The description clarifies it as a 'Companies House number', providing essential meaning that the schema lacks. This fully compensates for the 0% schema coverage, though it could also specify the format (e.g., alphanumeric 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 specifies the action (lookup) and resource (UK company by Companies House number), and mentions the output (record + ownership graph). It distinguishes from siblings like search_companies (which searches) and get_company_details (which gets details) by emphasizing the ownership graph, though it doesn't explicitly name alternatives. Clear but not maximally specific.

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

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

No explicit when-to-use or when-not-to-use guidance. However, the phrasing implies this is the tool for when you have a Companies House number and want both a record and an ownership graph. It does not mention alternatives or exclusions, so guidance is implied rather than explicit.

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 full disclosure burden. It reveals that the tool returns 'canonical WhiteIntel entity ids + confidence', that it operates 'in ONE call' (batching behavior), and imposes usage limits ('Up to 25 anon / 100 keyed'). It does not mention error handling or exact response structure, but for a read-oriented resolution tool, it provides solid transparency.

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 purpose and includes the scheme list, use case, and limits. Every word adds value; there is no redundancy or irrelevant information. It is compact and efficient.

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

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

Given the tool's complexity (multiple identifier types, batch processing, output with confidence), the description covers the main aspects: input types, output format, usage context, and batch limits. It lacks details on error handling and exact response schema, but since there is no output schema, the description does a fair job of making the tool usable. A perfect score would require clarifying potential error cases or mixed query handling.

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 input schema already describes queries as 'Names or scheme:value identifiers' (100% coverage). The description adds significant meaning by enumerating the supported schemes (lei/siren/br-cnpj/gb-coh/uen/sec/ofac/eu/un/uk/krs) and specifying batch capacity, which goes beyond the schema's basic description. This enriches the parameter understanding without redundancy.

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 tool's function with a specific verb ('Batch-resolve') and resource ('company names or scheme:value identifiers') to produce 'canonical WhiteIntel entity ids + confidence'. It distinguishes itself from sibling tools like lookup_by_identifier by emphasizing the batch capability ('in ONE call') and the use case ('without one lookup per row').

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

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

The description implies when to use this tool: for batch enrichment of supplier/counterparty lists, contrasting with per-row lookups. It also provides a capacity constraint ('Up to 25 anon / 100 keyed'), which is relevant context. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of an explicit 'use this instead of X' 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?

There are no annotations and the description does not mention any behavioral aspects such as side effects, permissions, rate limits, or read-only nature. The tool appears to be a search operation, but the description does not disclose whether it modifies data or requires special access. Given the lack of annotations, the description fails to provide transparency.

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 very concise and to the point, using a single sentence to convey the core functionality. It avoids unnecessary verbosity. However, its brevity leads to omissions in other dimensions, but structurally it is clean and easily readable.

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

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

Given the minimal schema (no descriptions), absent output schema, and lack of annotations, the description is insufficient for a user to fully understand the tool's behavior. It does not explain the return format beyond 'registration number', nor does it address edge cases like multiple results or errors. In the context of the broader tool suite, it provides only a basic idea.

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 input schema lists 'q' and 'limit' without any description. The tool description does not explain what 'q' represents (presumably the search query) or how 'limit' affects results. With zero schema coverage and no parameter explanation in the description, the semantics of the parameters are entirely unclear.

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 tool performs a free-text search for UK company names and returns registration numbers. It distinguishes itself from sibling tools by specifying 'free-text' and 'UK Companies House', which implies a distinct functionality. However, it could be slightly more detailed about the exact nature of the search (e.g., partial matches, case sensitivity).

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 does not explicitly state when to use this tool versus alternatives like 'search_entities' or 'lookup_by_identifier'. It implies usage when a user has a company name and wants a registration number, but lacks explicit guidance on scenarios or exclusions. No mention of when not to use 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, the description carries the transparency burden. It discloses scope ('every node ... companies AND people') and output ('Returns entity ids'), but it does not explain match semantics (exact vs. fuzzy), optional filter behavior, read-only status, or why the schema includes an 'asset' type while the description only mentions companies and people.

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 short sentences with no filler. Every phrase adds meaningful information: scope, search dimension, and return purpose.

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

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

Given five parameters, no annotations, and no output schema, the description is too sparse to fully prepare an agent. It covers the main use case but omits optional filter semantics and introduces ambiguity by omitting 'asset' despite the schema's type enum. Additional details about return structure or matching behavior would be needed for confident invocation.

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 compensate. It clarifies only the core 'q' parameter as a name search and partially implies 'type' via 'companies AND people,' but risk, juris, asset type, and limit are left unexplained. Most parameters still rely on inference from bare enums or 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?

The description uses a specific verb and resource: 'Search every node in the corpus — companies AND people — by name.' It also states the return value and downstream use ('Returns entity ids for get_dossier / trace_ownership_path'), which clearly distinguishes it from sibling tools like search_companies.

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 establishes clear usage context: use this for broad name-based entity search across companies and people when you need entity IDs for get_dossier or trace_ownership_path. It does not explicitly name exclusions or alternative tools, but the downstream-target framing provides practical 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?

No annotations are provided, so the description carries the full burden. It transparently discloses partial coverage (~1.9% of the corpus is embedded), warns that thin/empty results are not proof of unknown entities, and explains the implication for result interpretation. This goes beyond basic metadata to give actionable behavioral context.

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

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

The description is front-loaded with the core purpose and then provides important caveats. However, the coverage warning is slightly verbose with extraneous details like the percentage and growth status. Still, every sentence earns its place—the coverage warning is critical—but it could be tightened for clarity.

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?

Although there is no output schema or annotations, the description covers the tool's functionality, limitations, filters, and usage guidance, providing a complete operational picture. For a moderately complex tool like this, it gives sufficient context for correct invocation and result interpretation, especially with the alternative tool recommendation.

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 0% schema description coverage, the description must compensate. It explains 'query' as a natural-language query, and mentions optional kind and jurisdiction filters, which adds meaning. However, 'k' is not explained (likely top-k number, but unclear), and the filters are not detailed in terms of allowed values or behavior. This covers most parameters but leaves 'k' ambiguous, so I give 3.

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

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

The description clearly states the tool's purpose: meaning-based entity search using vector ANN over resolved dossier cards. It specifically contrasts with lexical/keyword search and provides a clear scope ('companies/people') and methodology (BGE-M3 vector ANN), distinguishing it from sibling search 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?

The description explicitly states when to use this tool (for semantic matches without keyword overlap) and when to complement it: it advises pairing with search_entities (lexical/name) before concluding an entity does not exist. This provides clear usage context and a precise exclusion, making it excellent.

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 full burden. It mentions walking upward and ultimate beneficial owners, but doesn't disclose details like cycle handling, depth semantics, or output structure. Minimal behavior disclosure.

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

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

One sentence, no fluff, front-loaded with action. However, it's so short that it lacks necessary nuance, but conciseness itself is fine.

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 complex traversal (ownership chain) with no annotations or output schema. The description fails to explain behavior like cycle handling, return structure, meaning of 'ultimate beneficial owner' (stopping condition), or how max_depth influences results. For an evaluator to invoke this blindly, it's incomplete.

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

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

Schema coverage is 0% (no parameter descriptions) and the description does not explain what 'root' is (e.g., entity ID, format) or what max_depth does. It adds no value over the bare parameter 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?

The description clearly states the action: 'Walk ownership upward' from a 'root entity' to identify 'ultimate beneficial owner(s)'. This is a specific verb-resource combination that distinguishes from siblings like graph_path or search_entities, as it focuses on ownership traversal.

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

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

No guidance on when to use this tool versus alternatives. It doesn't mention use cases, prerequisites, or exclusions. The description only states what it does, not when to choose it over sibling tools like graph_path or get_entity.

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