BlockchainAnalysis

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavioral details: it reads the issuer's blacklist function directly across 15 chains, reports the observed on-chain fact, never the cause, includes a prior-freeze signal from the freeze ledger, and states it is free. These go beyond the annotations and set accurate expectations. No contradiction.

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, well-structured paragraph that front-loads the core purpose, then elaborates on scope, behavior, and clarifications. Every sentence adds value: the chain list, the effect of a freeze, the prior-freeze signal, the 'never the cause' caveat, and the free status. No fluff or redundancy.

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

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

With no output schema, the description explains what the result reports (frozen/not at check time, prior-freeze signal) and explicitly states what it does not report (cause). Given the tool's complexity (15 chains, two issuers, historical ledger), the description fully covers the necessary context. It even notes the free status, which might affect agent decisions.

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 both parameters (address, chain) are described with formats and enum values. The description reiterates the chain list and address format, but adds little beyond the schema. It does mention that the check reads the blacklist function, but that's purpose, not parameter semantic value. Baseline 3 is appropriate.

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

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

The description states the specific action: checking whether USDT or USDC have blacklisted a wallet address on-chain. It clearly distinguishes from sibling tools like check_token_approvals or kyt_risk by focusing on stablecoin freeze status. The tool's scope (15 chains, both issuers) and the output (frozen/not plus prior-freeze signal) are 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 description implies when to use: to verify if a wallet is currently frozen for a stablecoin. It provides context like 'a frozen address can no longer send or receive that stablecoin' and clarifies it reports the observed fact, not the cause. It doesn't explicitly exclude alternatives, but the sibling tools have different purposes (approvals, security, KYT), making the usage clear enough.

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 and openWorldHint, and the description adds behavior beyond them: risk-scoring against entity labels, flagging unlimited allowances and stale grants, and the 'Free' cost signal. It does not contradict the annotations; 'Read-only' reinforces readOnlyHint.

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, purposeful sentences. The first sentence front-loads the verb, resource, and key value; the remaining fragments ('Read-only. Ethereum only. Free.') are compact and useful rather than 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 single-parameter, read-only listing tool with no output schema, the description provides enough contextual completeness: it names the asset type, chain, output scope ('who can move its funds'), risk-scoring behavior, and safety/cost profile.

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 covers 100% of the single parameter with a clear description, regex pattern, and Ethereum-only constraint. The tool description adds little parameter-level meaning beyond what the schema already provides, so baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'List a wallet's active ERC-20 token approvals on Ethereum and who can move its funds.' It clearly distinguishes itself from siblings like check_token_security or screen_address by focusing on approval-based attack surface and risk scoring.

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 clear context for use ('The wallet's attack surface at a glance') and states an important exclusion ('Ethereum only'). However, it does not explicitly name alternatives or contrast with sibling tools, so it stops short of full 5-level guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description's mention of simulation (buy-and-sell) aligns and adds context that it reports observed facts rather than verdicts. It also discloses network coverage and cross-referencing against entity labels, providing useful behavioral insight beyond the annotations.

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

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

The description is succinct, well-organized, and includes purpose, scope, and alternatives in a few sentences. No fluff or redundancy; 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?

The description covers purpose, simulation behavior, networks, and exclusions, which is well above the minimum. It lacks explicit mention of rate limits or authentication, but those are less critical given the readOnlyHint annotation. Overall complete for an effective selection.

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 has 100% coverage of parameters, so the description doesn't need to restate them. The description implies buy/sell parameters and token address via the context, but doesn't add extra detail beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb-action ('Simulate a buy-and-sell') and clearly states the resource (ERC-20 token) and the specific checks (honeypots, taxes, impersonation, mint authority). It distinguishes itself from sibling tools by naming exact alternatives for other use cases.

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

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

Explicitly tells the agent when to use this tool vs. alternatives: 'To check for freeze authority or stablecoin-specific risks, use check_stablecoin_freeze instead. To check general approvals, use check_token_approvals. For address-level risk, use screen_address.' This provides clear decision guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds that it's the event history (not current state), sources from issuers' on-chain blacklist, and that each row is a verifiable fact that never states the cause. This is valuable behavioral context beyond the annotations.

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

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

Two sentences, dense with information, front-loaded with the query action and scope. Every clause adds value; no 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?

The description provides complete context: it's history, not current state; lists the event kinds, sources (issuers and chains), filter options, default behavior, and limitation (does not state cause). No output schema, but it indicates what each row is. This is fully complete for a read-only history 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 covers 100% of parameters with descriptions, so baseline is 3. The description adds the usage note about omitting filters for most recent events aid default behavior, which is extra. But it doesn't detail each parameter beyond the schema. So 4.

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 ('Query') and resource ('canonical stablecoin freeze ledger'), enumerates the issuers (Tether, Paxos, etc.), and explicitly distinguishes itself from the sibling tool (check_stablecoin_freeze) by focusing on event history. This is unambiguous and distinguishes it from alternatives.

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 states when to use: querying event history, and explicitly points to the alternative: 'to check whether an address is frozen right now, use check_stablecoin_freeze instead.' Also provides guidance on filtering and omitting filters for recent events, covering usage context and exclusions.

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

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

Annotations already provide readOnlyHint and openWorldHint, so the description does not repeat that. It adds a significant behavioral detail: the call is paid per call via x402, which is not in annotations and informs cost/usage decisions. It also clarifies the output is a single verdict with flags, giving behavioral expectations beyond the annotation 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 a single, information-dense sentence that leads with the action ('Assess'), details inputs, and specifies output categories and cost. No filler or repetition; every phrase 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?

The tool has no output schemaational schema, so the description must convey expected output. It mentions 'risk verdict' with categories and flags, but does not explain what the flags mean or how the verdict should be interpreted. Given the complexity of KYT risk, an agent might need more detail to act on results. Sibling tools exist but no comparative guidance is provided.

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

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

Schema coverage is 100% with clear descriptions for both parameters (chain ID and address). The description does not add extra meaning beyond the schema, but it reinforces that address is a wallet address scroll. It is minimally adequate, meeting the baseline for well-documented schema.

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

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

The description explicitly states the tool assesses a wallet's KYT risk and enumerates its components (sanctions, entity classification, VASP/jurisdiction score, cluster context) and the output (risk verdict with flags). It clearly distinguishes from siblings like kyt_tx (transaction-level) by specifying wallet-level assessment.

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 guidance on when to use this tool versus siblings like kyt_tx or screen_address. The only context is that it is 'paid per call via x402', which hints at cost but does not help an agent choose between alternatives. The description implies wallet-level scope, but does not state exclusions or alternatives.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds the paid-per-call x402 payment detail, the dual-checks of counterparties, and the interpretation of the result as a cross-check across sanctions, entities, VASPs, and clusters. It stops short of describing failure modes or exact recommendation semantics, but it adds meaningful 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 two sentences with no filler: it states the core behavior, the output, and the cost model. Every clause carries relevant selection and invocation information, making it efficient and well-structured.

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 that there is no output schema, the description appropriately states return values, including the combined risk level, recommendation type, and directional flags. It also covers the screening scope and payment mechanism, making it sufficiently complete for an agent to select and invoke the 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?

The schema already covers the parameters fully with per-parameter descriptions, so the baseline is 3. The prose adds value by defining the relationship between 'from' and 'to' as a single transfer and linking them to the directional FROM:/TO: flags, which strengthens parameter meaning beyond the schema alone.

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 leads with 'Transaction KYT' and uses a specific verb ('screens'), clearly targeting both counterparties of a transfer (from → to) against sanctions, entity, VASP, and cluster data. It also names the concrete outputs — combined risk level, block/review/allow recommendation, and directional FROM:/TO flags — distinguishing it from sibling tools like screen_address or kyt_risk.

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 usage context: this is for transaction-level screening of a transfer's two parties, not single-address lookups. It does not explicitly describe when not to use it or name alternatives, so it provides the context but not full exclusionary guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe, read-only nature is known. The description adds that it is 'Free' (no cost), which is not in the annotations, and explains it returns capabilities and pricing, adding transparency about what the tool provides without relying on the structured fields.

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

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

The description is three sentences, each earning its place: it states what is listed, instructs to call it first, and mentions it is free. It is succinct and front-loaded with the purpose, with no wasted words.

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 simplicity (0 params, no output schema) and the annotations (readOnlyHint, openWorldHint), the description is sufficient. It specifies the output content (chains, tools, pricing) and the free status. It could optionally mention that the output list is exhaustive, but that is minor given the low complexity.

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

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

The tool has 0 parameters, so there is no parametric detail to add. The schema coverage is 100% by virtue of having no properties. The description instead focuses on what the tool returns (chains, tools, pricing), which is more relevant. A baseline of 4 is appropriate for a no-parameter tool.

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

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

The description clearly states the tool lists the BlockchainAnalysis MCP tools, supported chains, and pricing, and it explicitly says to call it first to discover server capabilities. This distinguishes it from the sibling tools, which perform specific blockchain analysis actions (e.g., check_stablecoin_freeze, kyt_risk), while this one provides an overview.

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 'Call this first to discover what the server can do (and which calls are free vs paid) before invoking a tool.' This provides clear when-to-use guidance and sets expectations for a discovery-first workflow. It also implicitly distinguishes it from the analytic tools by positioning it as a prerequisite step.

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 (no mutation) and openWorldHint=true (results may vary based on external data). The description adds that the tool is 'Paid per call via x402 (USDC on Base)', which is a significant behavioral disclosure not in annotations. It also describes the output structure (normalized verdict, score, confidence tier, reasons). This adds value beyond annotations by revealing the external payment requirement and output format. However, it doesn't disclose potential latency, failure modes, or data sourcing, but given annotations cover the safety profile, a 4 is appropriate.

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 sentence with excellent structure: it starts with the tool's promise (consumer-protection verdict), explains the output components, answers a question, and ends with a critical usage caveat (payment). Every clause earns its place, no filler. It is front-loaded with the primary purpose and scannable. Perfectly concise for the information conveyed.

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 2 parameters, full schema coverage, and no output schema, the description covers the key aspects: purpose, output structure, and payment requirement. It doesn't explain the meaning of the 0-100 score or confidence tier, but that's likely implicit. It also doesn't clarify what happens if the chain is not supported, but that's a peripheral concern. Since annotations cover safety, the description is complete enough for an agent to understand what the tool does and what to expect. A 4 is appropriate; it could have explained edge cases like invalid addresses, but for a simple 2-param tool, this is nearly complete.

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

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

Schema coverage is 100%, so both parameters (address and chain) are described in the schema. The description does not add additional parameter semantics beyond the schema, but it doesn't need to: the schema provides concise descriptions (e.g., chain ID examples, address format). The description adds a high-level context of what the tool returns, but not parameter-specific details. Since schema already covers parameters well, baseline is 3, and the description adds a bit of context about the tool's purpose, so a 4 is justified for adding value in the form of clarifying that the address is a wallet or contract and that the chain must be supported.

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: providing a consumer-protection verdict for a wallet or contract, with normalized verdict (safe/caution/high_risk), 0-100 score, confidence tier, and reasons. It answers a specific question ('is it safe to interact with this address?') and includes payment details via x402. This clearly distinguishes it from sibling tools like screen_address or check_token_security, which likely focus on different aspects (e.g., risk screening or token-specific checks).

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: when you need a consumer-protection verdict for an address, answering 'is it safe to interact with this address?' It provides context about the tool being paid via x402, which is a usage caveat. However, it does not explicitly state when to use this tool over siblings like screen_address or kyt_risk, nor does it mention alternatives. The distinction from siblings is implicit through the focus on consumer-protection verdicts, but not explicit exclusions are provided.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds value by specifying the dataset size (1B+ entities), threat levels (SAFE→CRITICAL), and the cost mechanism (x402, USDC on Base). It does not contradict annotations and provides additional behavioral context like the types of labels returned.

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

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

Two sentences, front-loaded with the core purpose, then adding critical context (labels, chains, cost). Every clause adds value—no filler or repetition. The structure is tight 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?

With no output schema, the description compensates by describing the output format ('each label carries a threat level, source, and confidence'). It also covers supported chains and payment method. Missing details like error handling or pagination are minor given the tool's simplicity.

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

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

Schema description coverage is 100% for both parameters (address and chain), and the schema already explains their meaning. The description adds no extra param-level detail beyond what's in the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function: 'Screen a wallet against BlockchainAnalysis's 1B+ entity-label dataset.' It lists specific label categories (sanctions, scam, phishing, etc.), identifies the chains supported, and notes the cost model. This is specific and distinct from sibling tools like kyt_risk by focusing on entity-label screening.

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

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

The description implies usage for wallet screening but does not explicitly state when to use this tool versus alternatives. It mentions the chains it works on and that it is paid per call, but lacks direct guidance such as 'use this for risk assessment' or 'for transaction-level analysis, use kyt_tx.' The usage context 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?

Annotations provide readOnlyHint=true and openWorldHint=true, so the read-only safety is known. The description adds substantive context: the data sources (BA's entity labels, live stablecoin freeze state), the three possible verdicts, and the distinction from detailed/attested tools. However, the phrase 'Boolean compliance verdict' is inconsistent with the three-state output (clear/flagged/unknown), which is a minor transparency flaw.

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

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

Three sentences, each earning their place: outcome, data sources, differentiation from paid tools, and pricing. Front-loaded with the verdict type and not a single wasted phrase.

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 tool with no output schema, the description adequately explains what is returned (verdict and risk category) and what it screens against. It does not mention the fail_mode parameter's effect on verdict semantics, but that is covered in the schema. The minor 'Boolean' wording issue slightly reduces completeness, but overall the description is strong.

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 has 100% coverage with descriptive text for all three parameters (chain, address, fail_mode). The description does not add parameter-specific semantics beyond the schema, but it also does not need to since the schema already explains each field. Baseline 3 is appropriate.

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

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

The description clearly states what the tool does: returns a compliance verdict (clear/flagged/unknown) plus top risk category, screened against entity labels and stablecoin freeze state. It also distinguishes from siblings by noting that screen_address and kyt_risk provide detail, and screen_agent_wallet_attested provides a signed proof.

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 says 'Deliberately a verdict only' and points to paid tools for detail, making the trade-off clear. It also mentions the tool is free, adding a cost/benefit consideration for choosing it over the paid 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 readOnlyHint and openWorldHint annotations, the description adds valuable behavioral context beyond those: it discloses that the tool generates a signature (EIP-712/ secp256k1), anchors to a BA Stamp, is paid per call via x402 on Base, and supports offline verification via ecrecover. It does not contradict any annotation, and these details are not implied by the annotations or schema.

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

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

The description is two sentences, front-loaded with the core action and output, then adds the differentiator from the free sibling. It packs key information without any wasted words or redundancy.

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

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

Given that there is no output schema, the description adequately specifies the return type (verdict + signature + anchor) and verification method. It also addresses payment, trust model, and relationship to the free sibling. The tool has moderate complexity, and this description covers the essential aspects completely.

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?

Parameter descriptions in the input schema already cover 100% of parameters (address, chain, fail_mode). The tool description adds no extra parameter-specific details beyond what the schema provides. It does not elaborate on formats or examples, so based on the high coverage, a baseline of 3 is appropriate.

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

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

Description clearly states the verb ('Screen') and the resource ('an agent wallet'), and specifies the output: a signed, on-chain-anchored compliance attestation. It explicitly distinguishes itself from the sibling tool 'screen_agent_wallet' by noting the free version returns only the verdict, while this one returns a signed attestation for verification.

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 says 'The free screen_agent_wallet tool returns the verdict only' which tells the agent when to use this paid alternative (when a signed attestation is needed) versus the free one. It also mentions the x402 payment mechanism and that it is 'Paid per call', giving clear context for selecting this tool over its siblings.

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