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

Annotations already declare read-only, non-destructive, open-world behavior, so the bar is lower; the description still adds real context by disclosing the $0.75 per-call cost and noting that open ERC-8004 feedback is returned but not scored. It does not say what happens when a wallet is unregistered or has no sanctions match, which would round this out.

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 core action and cost-conscious detail, with every clause mapping to an actual returned check. The long parenthetical nesting makes it slightly harder to scan, but nothing is padding.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating all four result components plus pricing. Missing only edge-case behavior (invalid/unregistered wallet, partial results), which is minor for a read-only lookup.

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

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

Schema description coverage is 100%, so the baseline is 3; however the description goes beyond the schema by explaining what agent_id actually unlocks (that agent's owner and payment wallet), which the schema does not state. The optional 'domain' parameter is never mentioned, leaving one small 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?

States a specific verb ('Check') plus the exact resource ('a counterparty agent's EVM wallet') and enumerates the four sub-checks performed, which is far more informative than a generic 'verify' tool. It does not explicitly distinguish itself from close siblings like verify_wallet or sanctions_screen/wallet_sanctions_preview, so an agent must infer the composite nature of this call.

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 'counterparty agent's EVM wallet' implies the scenario (vetting an agent you may transact with), but there is no explicit when-to-use, when-not-to-use, or named alternative among the many overlapping sibling tools. Usage must be inferred from the enumerated checks rather than stated.

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

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

Annotations already declare readOnly, openWorld, non-idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful context the annotations cannot carry: which registries and screening sources are queried, and how to read the output flags ('trust_score 0-100, 100 = best', 'trust_level high means low risk'). It stops short of disclosing latency, cost, coverage limits, or why the call is non-idempotent.

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 what is checked and followed by what comes back, with no filler or repetition of the title. The output list is dense but each clause adds a distinct fact about coverage or return values.

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 correctly assumes the burden of naming the return keys (trust_score, trust_level, cluster, recommendation, confidence, top_factors, sources_checked) and explaining the two that would otherwise be ambiguous. The remaining gap is routing completeness — it never states when this beats get_trust_score or sanctions_screen for the same entity.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and the baseline is 3. The description only marginally extends this by tying the KVK register to NL companies and flagging the domain as conditional ('when you send it'); entity_name and country get no extra meaning beyond their schema text.

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 ('Company check on a business') and enumerates the exact data sources consulted (sanctions screening, country risk, Dutch KVK register, website domain). That implicitly separates it from the wallet-oriented siblings (verify_wallet, check_agent_wallet), but it never explicitly positions itself against close cohorts like get_trust_score, sanctions_screen, or get_risk_score, which also return risk/trust signals.

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

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

There is no when-to-use, when-not-to-use, or alternative-routing guidance despite nine siblings with overlapping risk/trust semantics. The only conditional language, 'the website domain when you send it', describes an optional parameter rather than a usage condition, and nothing tells the agent which tool to pick for a wallet versus an entity.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, and 'built from one real check' plus the per-source ok/unavailable/error table add real context: this performs an actual external check that can partially fail. It still does not explain the cost/side-effect implied by readOnlyHint=false, nor whether a report is persisted or reusable.

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 sentence that front-loads the resource and scope, then lists report sections compactly. It is dense but each clause enumerates a distinct output component, which earns its place given 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, enumerating the report contents (identity, screens, risk score with fired rules, ranked findings, source status table, hash) is genuinely necessary and is done thoroughly. What is missing is operational context: when to use it versus sibling checks and what the non-read-only, non-idempotent behavior implies.

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% across all 10 parameters, so the schema already documents identifiers, formats and the check_id alternative. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description names the resource ('Per-entity report') and enumerates exactly what the report contains, so an agent knows this produces a comprehensive per-entity artifact rather than a single score. However, it never explicitly contrasts itself with siblings like check_entity, get_risk_score, or sanctions_screen, which it partly subsumes, so the agent must infer the boundary.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many overlapping siblings (check_entity, get_risk_score, sanctions_screen). The phrase 'built from one real check' hints at a trigger but never says when an agent should pick this over a cheaper single-purpose tool.

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

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

Goes well beyond the annotations (readOnlyHint/openWorldHint) by disclosing the exact data sources used, the fields returned, and critically that risk_level polarity is inverted relative to check_entity's trust_level — a subtlety that would otherwise cause misinterpretation. It also states what is deliberately absent (recommendation, factors).

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

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

Two dense sentences, front-loaded with the scope boundary and the differing-from-sibling caveat. Every clause conveys load-bearing information (scope, return fields, polarity warning, exclusions) 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?

With no output schema available, the description compensates by enumerating the return fields and their meaning. Combined with the scope restriction and the polarity warning, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema description coverage is 100% (country as ISO 3166-1 alpha-2, entity_name as full legal name), so the schema already carries parameter meaning. The description adds no format or constraint detail beyond that, which matches the baseline of 3 when structured data does the heavy lifting.

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

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

States a specific verb+resource ('risk score from sanctions screening and country risk') and immediately bounds the scope against a named sibling ('without the register or domain lookups of check_entity'). An agent can distinguish it from check_entity, get_trust_score and sanctions_preview without opening any 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?

The phrase 'without the register or domain lookups of check_entity' implicitly tells the agent to pick this tool when the lighter sanctions+country check suffices, and names the alternative. It stops short of an explicit 'use this when / avoid this when' statement or cost/latency rationale, so it is clear but not fully prescriptive.

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?

Beyond the annotations (readOnlyHint, openWorldHint false, destructiveHint false), it adds that no new check runs, no data source is called, and the operation is free ($0). It also lists the returned fields, which matters since no output schema exists, though it does not cover error cases such as having no stored check.

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

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

Three front-loaded sentences with zero waste: purpose and scope first, then the no-new-check constraint, then cost. The field list is compact and every sentence earns its place.

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

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

For a simple read-only lookup with full schema coverage and annotations, the description covers purpose, constraints, cost, and return fields (necessary because no output schema exists). 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?

Schema coverage is 100% and the single entity_id parameter is already documented as 'Entity name, as sent to check_entity.' The description reinforces that the entity must have been checked before, but adds no syntax or format detail 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 states a specific verb (look up), resource (your own most recent trust score), and scope (for an entity you checked before, from your stored checks). It distinguishes itself from sibling tools like check_entity by explicitly noting it 'Runs no new check and calls no data 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 clearly states the usage context: only for entities previously checked, pulling from stored checks. It also implies when not to use it by noting no new check runs, but it never names check_entity or another alternative for fresh 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: it enumerates the exact return fields, states it never returns an entry, notes screening is against *local* lists, and publishes a rate limit of 10 per caller per UTC day — all things annotations cannot convey.

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

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

Three short sentences with zero filler; the core purpose and the free/preview constraint are front-loaded, and the return-field list and rate limit follow in descending order of importance. Every sentence earns its place.

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

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

There is no output schema, so the description carries the return burden and does so by naming the four fields returned. What remains unexplained is the semantics of the fields (e.g. what list_note contains) and what an agent should do on a positive possible_match; these gaps are minor for a preview 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 description coverage is 100%, so both parameters (name, country) are already documented, including the important note that country only orders matches and never excludes one. The description adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb (yes/no preview) and resource (local OFAC SDN, EU and UN sanction lists), and the phrase 'never an entry' signals it differs from a full screening tool. It is clear without opening the schema, but it never names the sibling sanctions_screen or wallet_sanctions_preview, so the differentiation remains implicit rather than explicit.

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

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

The 'Free yes/no preview' framing plus the 10/caller/day cap implies this is the cheap first-pass check and that a heavier tool is needed for actual entries, but no alternative is named and no when-not-to-use condition is stated. Usage is inferable but not spelled out.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real value by naming the specific list sources screened and by including the 'a name match is not a determination' disclaimer, which shapes how an agent should interpret a hit. It omits any mention of match-score thresholds or how openWorld access affects latency/results.

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 what is screened and what is returned; the caveat comes last where it belongs. The field enumeration in sentence one is dense but each item earns its place given 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 compensates by listing the returned fields (list, entry id, programmes, countries, listing date, match score). The main remaining gap is that 'match score' is not explained (scale or threshold), which an agent would need to interpret results correctly.

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

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

Schema description coverage is 100%, and the schema already explains the non-obvious behavior of country ('orders matches, never excludes one'). The description adds nothing about parameters, so the baseline of 3 applies when the schema does all the work.

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

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

The description gives a specific verb (screen) and resource (sanctions lists: OFAC SDN, EU, UN) and even enumerates the returned fields, so the purpose is unambiguous. However, it never differentiates itself from the closely named siblings sanctions_preview and wallet_sanctions_preview, so an agent cannot tell them apart from the text alone.

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

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

There is no statement of when to use this tool versus sanctions_preview, wallet_sanctions_preview, or check_entity. The only guidance-like sentence, 'A name match is not a determination,' is an interpretive caveat about results, not usage direction, leaving the agent to infer selection context from the name alone.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false), so the bar is lower. The description adds genuinely useful context beyond them: the $0.27 cost, that it hits external registers, and the composite 0-100 output. It stops short of disclosing latency or what a partial/failed match returns.

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 scope and enumerates the checks without waste. No filler, nothing repeated from annotations or schema.

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

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

For an 11-parameter tool with nested objects and no output schema, the description names the output (0-100 lead score) and the verification domains, which is what an agent needs at selection time. Missing only edge-case/failure behavior, which is minor given the rich schema.

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 each parameter (IBAN partial return, email domain-only, phone rejection, VAT/VIES) is already well documented in the schema. The description adds no parameter-level syntax or format guidance beyond what is structured, so the baseline 3 applies.

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

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

States a precise verb (Verify) and resource (NL/BE sales lead) and enumerates the five checks performed plus the 0-100 lead score output. It differentiates by region and 'sales lead' framing, though it never names which sibling (check_entity, sanctions_screen) it supersedes despite overlapping on 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?

The phrase 'in one call' implies this consolidates multiple checks and is preferable to calling several sibling tools separately, which is useful implied guidance. There is no explicit when-to-use/when-not or prerequisite statement, so an agent must infer the routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: a $0.11 cost, that agent reputation signals are descriptive and 'never scored', that advice is capped at 3 items, and that ERC-8004/agent reporting only applies on Base. It omits that results are time-sensitive (idempotentHint=false), which would be useful for a screening 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?

Front-loaded with the core verb and result composition, then layered detail. Every sentence carries information (signal list, scoring caveat, price, address support), though the on-chain signal enumeration is dense.

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

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

With no output schema, the description must convey what is returned, and it does so thoroughly: the signal categories, the advice-item cap, the descriptive-only agent reputation, and chain coverage. The main omission is any note that results change over time, but overall it is sufficient for correct 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 100% (chain_id documents CAIP-2 format and defaults, wallet_address is documented), so the schema carries the parameter burden and baseline is 3. The description adds only light context — 'Supports EVM and Solana addresses' and Base-specific behavior — without new syntax or format detail.

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

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

The description gives a specific verb (screen) and resource (wallet) and enumerates exactly which signals are produced (OFAC SDN match, on-chain signals, named risk rules, advice items), so the agent knows precisely what the tool yields. It does not, however, name or contrast itself with the heavily overlapping siblings (sanctions_screen, wallet_sanctions_preview, check_agent_wallet), so sibling differentiation is left to inference.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named despite several siblings that also screen wallets for sanctions/risk. The mention of EVM and Solana support and Base-specific behavior implies scope but does not route the agent between this tool and its near-duplicates.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false), so the bar is lower; the description adds real value on top with a precise rate limit ('10 per caller per UTC day'), the exact fields returned and withheld, and the cost of the deeper alternative. It stops short of describing failure/latency behavior or what a non-match response looks like.

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?

Compressed into two sentences with the core purpose front-loaded and no filler. The middle clause ('sanctioned, lists, the list date and its freshness') is telegraphic and slightly strained to parse, which costs a point, but overall density is high and every clause carries information.

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

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

With no output schema, the description compensates by enumerating the returned fields and exclusions, plus rate limits and the paid alternative. An agent has enough to call it correctly and interpret the result, though the handling of the optional chain_id default in a sanctions context is left entirely to the schema.

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 (wallet_address, chain_id) are documented in the schema, including CAIP-2 format and accepted chains, so the description need not repeat them. It adds no parameter-level meaning beyond the schema, which is the baseline-3 case.

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

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

States a specific verb+resource (yes/no check of a wallet address against the OFAC SDN list) and explicitly scopes the output fields ('sanctioned, lists, the list date and its freshness') while naming what is excluded ('no programmes or entry ids'). It also distinguishes itself from siblings by flagging 'separate from sanctions_preview' and pointing to verify_wallet for the full screen.

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 concrete routing context: free tier, 10 per caller per UTC day, and an explicit alternative ('The full wallet screen is verify_wallet ($0.11)') so the agent can trade cost against depth. It doesn't state an explicit when-not-to-use condition or the quota interaction with sanctions_preview beyond noting they are separate.

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