BlockchainAnalysis.io

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

Goes well beyond the readOnly/openWorld annotations: states the result is the observed on-chain fact at check time, explicitly disclaims reporting the cause of a freeze, and discloses the prior-freeze-then-unfrozen ledger signal. That is meaningful boundary-setting an agent could not get from annotations alone.

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 question (has a wallet been blacklisted) and the mechanism, then the behavioral caveats. Every sentence adds information; the chain list duplicates the schema enum but reads as one compact clause, not 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 annotations covering safety and an output schema covering return shape, the description supplies exactly what is missing: what is read, what the result means, what it deliberately does not tell you, and the 15-chain scope. Nothing an agent needs to invoke it correctly is absent.

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

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

Schema coverage is 100% and the address format constraint (0x…/T…/base58) is already documented in the schema; the description adds no new syntax detail. It does reinforce that both parameters are required by describing the check per chain, but the 15-chain enumeration merely duplicates the enum.

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?

Specific verb+resource: checks whether USDT/USDC issuers have blacklisted a given wallet, with the exact mechanism (reading the issuer's blacklist function on-chain) and scope (15 named chains). It is clearly distinguishable from siblings like screen_address, get_freeze_events, or check_token_security.

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?

Implicitly routes usage: it explains the freeze-ledger prior-freeze signal vs. the live on-chain read, which helps separate it from get_freeze_events, and it flags the zero cost ("Free."). However it names no alternative tool or explicit when-not condition, so the agent must infer the boundary.

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 only mark this as a read-only, open-world call, and the description adds substantial operational context beyond that: payment is required per call via x402 in USDC on Base, missing addresses return an explicit not-found with a reason rather than an empty result, and an absent label is explicitly not evidence of safety. It also discloses ordering rules (labels lacking evidence.verified listed last), which an agent needs to interpret the result correctly.

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 definition is long but front-loaded: the core action and return contents come first, with behavioral caveats after. A few clauses edge toward marketing ('the only way to buy it per call with no account and no API key'), but the payment fact is genuinely needed, so little is truly wasted.

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-shape burden and does so — naming the label categories, threat-level scale, provenance fields, and the not-found behavior. Combined with full schema coverage for the two required inputs, an agent has everything needed to call and interpret this 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% and both parameters (chain, address) are fully documented in the schema, so this is the baseline case. The description reiterates the single-address scope but adds no format or validation detail beyond what the schema already states.

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

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

States a specific verb and resource ('Look up ... entity labels for a single address') and enumerates exactly what comes back (category, threat level, provenance). It contrasts itself with the higher-level 'BA Intel' product but never names a sibling tool such as screen_address, so an agent must infer the boundary itself.

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 it fits — the 'raw label read' for a single address, payable per call with no account — but it never states when a sibling like screen_address or kyt_risk is the better choice. Usage is inferable from the framing rather than explicitly guided.

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 and openWorldHint, and the description adds genuinely non-obvious behavior: the call is paid per invocation via x402 in USDC on Base, and results carry a normalized verdict plus confidence tier. That cost/auth context is exactly what annotations cannot convey. It stops short of noting latency or what happens on unindexed chains.

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

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

Two tight sentences: the first front-loads the deliverable, the second the answering question and the payment model. No filler 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?

With a rich output schema present, the description needn't re-explain return fields, and it correctly focuses on the question it answers plus the x402 payment requirement. Only marginal gaps remain (unknown-chain behavior, per-call cost amount, latency), so it is complete enough to invoke 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 both parameters are documented inline (chain IDs with examples, address format matching chain). The description adds no further parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource (normalized safety verdict for a wallet or contract) and enumerates the payload: verdict value, 0-100 score, confidence tier, plain-language reasons. It does not name or distinguish itself from close siblings like screen_address, kyt_risk, or check_token_security, so an agent must still infer which oracle to 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?

Usage is implied rather than stated — 'Answers is it safe to interact with this address?' frames the question the tool answers. There is no explicit when-to-use vs the many screening/risk siblings, and no when-not or prerequisite guidance beyond the payment note.

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

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

The description discloses significant behavioral traits beyond the annotations. It mentions the tool is 'Paid per call via x402 (USDC on Base)', details the not-found behavior ('returns an explicit not-found with the reason, never an empty result'), and explains the provenance and confidence metadata in each answer. These are not captured in the readOnlyHint or openWorldHint annotations, so the description carries the full burden and does so thoroughly.

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, then efficiently covers output details, exclusions, and pricing. It is dense but every sentence adds value, and there is no fluff or redundancy. It is slightly longer than minimal due to the complexity, but 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 the tool has only 2 parameters and no output schema, the description must explain what the tool returns. It does so comprehensively: it lists the data fields (issuer, asset class, ISIN, jurisdiction, permissioned, chains), the provenance details, and the not-found behavior. It also covers exclusions and cost, providing a complete picture for an agent to decide whether to call this 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?

The input schema already provides complete descriptions for both parameters (address and chain), including formats and examples. The description does not add any parameter-specific information beyond what the schema offers. With 100% schema coverage, a baseline score of 3 is appropriate; the description does not need to compensate.

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 'Identify a tokenized real-world asset from its token address' and enumerates the specific attributes returned (issuer, asset class, ISIN, jurisdiction, permissioned transfers, chains). This distinguishes it from sibling tools like check_stablecoin_freeze or check_token_security, which focus on different concerns. It is not a tautology but a precise, resource-specific statement.

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 clearly implies when to use the tool (for RWA identification) and explicitly states what it does NOT cover: 'Does NOT cover the issuer's control over a balance (pause, blocklist, seizure).' This exclusion guides agents away from using this tool for balance-control queries. However, it does not explicitly name alternative tools for those cases, so it falls short of a perfect 5.

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

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

The annotations already declare this is a read-only, open-world operation, and the description adds meaningful behavioral context: paid per call via x402 in USDC on Base, threat levels with source and confidence, and the ordering rule for accusations lacking verifiable evidence. It does not describe rate limits or a complete response shape, but it contributes useful traits 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 a single dense paragraph that front-loads the core purpose and then layers in dataset coverage, chain support, evidence behavior, and payment. It is appropriately sized for a multifunction screening tool, though some clauses are packed tightly together.

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

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

With a simple two-parameter schema, read-only annotations, and no output schema, the description supplies enough context about dataset scope, threat levels, evidence verification, chain coverage, and payment to call the tool correctly. It could be more complete by explicitly clarifying sibling selection and the returned result structure, but the core operational context is present.

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 address and chain are already documented in the input schema. The description mentions supported chains, but this largely repeats examples already present in the chain parameter description and adds no new formatting or validation guidance 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 the specific action and resource: screen a wallet against a named entity-label dataset, with examples of covered labels and chains. It does not explicitly differentiate itself from nearby siblings such as screen_agent_wallet, screen_agent_wallet_attested, or kyt_risk, so it lands at clear but not sibling-differentiating.

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

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

Usage is implied by the purpose and by listing the sanctioned/scam/phishing/exploit/mixer/exchange categories, but the description gives no explicit when-to-use rules, exclusions, or comparison to alternatives. An agent can infer that this is for wallet risk screening, but must still decide on its own when to choose it over siblings.

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 only declare readOnly/openWorld; the description adds substantive behavior: data sources (1B+ entity labels, live freeze state), the flagging policy for exchanges and unverified accusations, and the presence of unverified_count. This is context beyond what annotations provide.

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 verdict and result set, then the flagging rules, then the sibling routing. Dense but every clause carries information; slightly long for a single paragraph but 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 an output schema present, return-value explanation is unnecessary, and the description still covers data sources, flagging policy, and the free-vs-paid boundary. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% and fail_mode's enum semantics are fully documented in the schema, so the description need not repeat them. The description adds no parameter-level syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Boolean compliance verdict for an agent wallet') and enumerates the exact return values (clear/flagged/unknown plus top risk category). It explicitly distinguishes itself from screen_address, kyt_risk, and screen_agent_wallet_attested by scoping those to paid/detailed output.

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 this free verdict-only tool versus the paid alternatives for label detail, freeze history, scores, and attested proofs. It also names exclusions (exchange/service labels and unverified accusations do not flag) so the agent knows what a 'clear' does and does not mean.

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.