Agent Risk Desk

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), but the description adds traits annotations cannot express: a $0.02 USDC per-call price via x402 (a hard prerequisite before invocation) and the verdict taxonomy itself. It also discloses the actual evidence sources (OFAC SDN, Chainalysis oracle) and detection windows, so the agent knows what a 'block' really means.

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

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

One dense paragraph, front-loaded with the output, identifiers and chain scope, then the use case, then the checks, then price. The long list of checks is the core value proposition and each item earns its place by signaling verdict drivers.

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

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

No output schema exists, and the description compensates by stating the return shape ('allow, warn or block, with reasons'). With the cost, the evidence sources and the chain set all present, an agent has everything needed to decide and call 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 optional parameters carry their own defaults and bounds, so the schema does the work here. The description only loosely gestures at them ('account age', 'code changes in the last 72 h') without naming minAgeDays or codeWindowHours, so it adds nothing an agent could not read from 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?

States a specific verb and resource — a counterparty-risk verdict (allow/warn/block) for an EVM address — and enumerates the five supported chains, which separates it from the NEAR sibling by chain scope. It does not explicitly differentiate itself from enrich_evm_address, so sibling routing relies on the agent inferring 'verdict' vs 'enrichment'.

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?

"For use before paying, approving or trusting it" gives a clear, concrete decision context, which is exactly the trigger an agent needs. There are no exclusions and no named alternatives, so the agent gets positive guidance but no guidance on when to pick a sibling instead.

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 readOnly/idempotent/openWorld, and the description adds genuinely non-obvious behavior: the three verdict outcomes with reasons, the exact checklist of sources consulted, and, critically, the $0.02 USDC x402 cost per call. It does not describe failure behavior (e.g., what a verdict looks like if the account is unreachable), which is why it isn't a 5.

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

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

A single front-loaded sentence leads with the verdict and its allowed values, then the checks, then price. It is dense but every clause carries a distinct signal; only the parenthetical price note could have been folded in more tightly.

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 still specifies the return shape (allow/warn/block with reasons) and the inputs that modulate it. Combined with annotations and full schema coverage, an agent has everything needed to decide to call it and interpret the result.

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

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

Schema coverage is 100%, so all five parameters, including the vault/account/network/minAgeDays/codeWindowHours defaults, are already documented in the schema. The description restates the vault behavior and the 72 h code window but adds no syntax or edge-case guidance beyond that, 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 (counterparty-risk verdict for a NEAR account) and enumerates the signals it checks (OFAC SDN, deny-lists, account existence/age, contract code churn, publisher-upgradeable contracts, vault denylist/payment history). The NEAR scope directly distinguishes it from sibling counterparty_risk_evm.

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?

"For use before paying it" gives a clear triggering context, and the NEAR naming plus the vault parameter show when it applies. It never explicitly names counterparty_risk_evm as the alternative for EVM accounts, so the routing is inferred from the suffix 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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered by structured data. The description adds genuinely new behavioral facts beyond that: the tool is pay-per-call at $0.01 USDC via x402, meaning a payment/auth flow is required, and supported networks include base-sepolia, which the prose omits. It does not mention rate limits or whether failed lookups are still billed.

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 core payload is front-loaded in a single dense but purposeful sentence, followed by a short usage clause and the price tag; nothing is redundant. The middle sentence is very long, packing a dozen sub-items, which slightly hurts scannability but every item 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?

With no output schema, the description carries the burden of describing return values, and it does so thoroughly by enumerating the fields and noting the risk verdict comes 'with reasons'. Remaining gaps are minor: response shape/ordering and error behavior (e.g. unknown address) are unstated, and base-sepolia is missing from the prose network list.

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 schema already spells out the address pattern and the chain enum with its default. The description restates the network list (minus base-sepolia) but adds no syntax, format, or checksum guidance 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 a precise resource (an EVM address) and enumerates exactly what is returned (EOA/contract/EIP-7702 classification, age, tx count, balances, Sourcify source, proxy info, labels, risk verdict), which is far beyond a restatement of the name. It does not explicitly contrast itself with siblings such as counterparty_risk_evm or screen_transaction, both of which also produce risk-flavored output, so the boundary is left implicit.

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?

"Useful to know who an address is before paying, listing or trusting it" gives concrete decision contexts for calling it. There is no explicit when-not guidance and no named alternative (e.g. when to prefer counterparty_risk_evm for a pure risk check), so it falls short of the full when/when-not/alternatives bar.

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 is fully consistent with readOnlyHint=true and openWorldHint=false, and adds value beyond them: it discloses that this call is free and that results carry pricing, network/asset, and endpoint metadata. It stops short of describing result ordering or format, but for a zero-cost read the key behavioral facts are present.

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

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

One sentence with zero waste, and the most decision-relevant fact ('Free.') is front-loaded so an agent sees the cost profile immediately.

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 parameters, no output schema, and only two annotations, the description carries the needed weight by enumerating the fields returned (prices, network, asset, endpoints). It could go one step further and say what an agent should do with that output, but nothing essential is missing.

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

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

The tool takes no parameters, so the baseline is 4; there is nothing for the description to compensate for. The empty schema is consistent with a simple catalog read.

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 'Lists' plus a precise object: the paid tools of this server, including prices, payment network/asset, and HTTP endpoints. This is unmistakably a discovery/catalog tool, distinct from the sibling risk and screening tools, though no sibling is named.

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

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

'Free.' implicitly signals this is the cheap entry point to call before invoking paid tools, which is useful context. However, it never states that explicitly, nor does it name which tools are paid or when to prefer this over trying a paid tool directly.

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 (readOnly/openWorld/idempotent), and the description adds substantial context beyond them: robots.txt compliance, a per-call price of $0.02 USDC via x402, no interaction support, and proof-of-exit-IP metadata. Cost and payment protocol disclosure is exactly the kind of operational detail an agent needs before invoking.

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 core action and scope are front-loaded, then returns, then use case, then constraints, then price — a logical order with no filler. It is dense as a single block but every sentence 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 fully enumerates the return payload, and for a paid, open-world fetch tool it discloses cost, payment mechanism, robots.txt behavior, and interaction limits. Nothing an agent needs to decide or call 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 description coverage is 83% and each parameter (url, country, device, waitMs, waitUntil, include.*) is already documented in-schema. The description only loosely reinforces that the country is user-chosen and that HTML/screenshot are optional, adding little beyond the schema — 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 and resource ('Loads a public web page in a real Chromium browser') plus the distinguishing scope: JavaScript executed, residential IP, user-selected country. It also enumerates what comes back (visible text, title, final URL, HTTP status, optional HTML/screenshot, exit IP proof), so an agent knows exactly what it gets.

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

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

Gives a concrete use case ('see prices, content or availability as a visitor in that country sees them') and hard capability boundaries ('no clicks, logins or CAPTCHA solving'). It doesn't point to a sibling alternative, but no sibling in this toolset is a comparable render/fetch tool, so the gap is minor.

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, idempotent and openWorld, so the safety profile is covered for free. The description adds genuinely non-redundant context: the per-call price ($0.04 USDC via x402), the supported chain set, and that unlimited approvals are flagged — economically important for an agent deciding to call. No return format or latency details, but the bar is lower with annotations present.

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

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

Front-loaded with the capability and output contents in one dense sentence, followed by scope, use case and price. Every sentence earns its place, though the chain enumeration is somewhat redundant with the enum and could be trimmed.

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 well by enumerating result fields (status, method, native/token transfers, approvals, fee, per-counterparty risk verdict, summary). It also discloses cost and chain coverage, leaving nothing essential missing 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% with an enum on chain, so the schema already carries the parameter burden and baseline is 3. The description's chain list duplicates the enum rather than adding semantics, and it says nothing about the conditional `sender` requirement beyond what the schema states.

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

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

States a specific verb and resource ('Plain-language explanation of an EVM or NEAR transaction') and enumerates exactly what the explanation contains: status, method, transfers, approvals, fee, risk verdict. An agent can distinguish it from verify_allowance_receipt (a targeted allowance check) and counterparty_risk_* (address-level risk) without opening a 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 sentence 'Useful to check what a payment or approval really did' implies the usage context but never states when to prefer this over the overlapping siblings verify_allowance_receipt or counterparty_risk_evm. There are no exclusions or prerequisites, so routing still requires inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), yet the description adds substantive context beyond them: verification happens 'at final finality', the vault code hash is read at the same block, and the call costs $0.005 USDC via x402. Pricing and finality semantics are exactly the kind of behavior an agent cannot infer from 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 core check is front-loaded in the first clause and the parenthetical reason list packs the failure modes into one sentence. The pricing sentence is separate and earns its place, though the main sentence is dense enough to be slightly hard to parse on a first read.

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 entire return-value burden — and it does, specifying 'valid' versus the specific rejection reasons plus the returned vault code hash. With 8 parameters at full schema coverage, nothing essential about calling or interpreting this tool 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 description coverage is 100%, so the baseline is 3, but the description adds meaning: minAmount is framed as a floor ('at least a given amount') rather than an exact match, and the receipt is 'bound to the seller request hash', clarifying the role of requestHash. It does not mention the nonce alternative to requestHash, so it falls short of a 5.

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 — a seller-side verification that an Allowance vault receipt on NEAR paid an account at least a given amount — plus the binding to the seller request hash and final finality. None of the siblings (risk, screening, listing, enrichment) overlap with receipt verification, so the scope is unambiguous.

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

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

'Seller-side check' establishes the caller context clearly, and the enumerated failure reasons (not paid yet, wrong payee, amount, asset or request, unknown receipt, not a vault) implicitly tell the agent what conditions it is testing. It does not name alternatives or state when NOT to use it, which keeps it short of a 5.

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