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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true) by disclosing the consequence of the write: the attestation is published so payers can see it before settling, no account or key is required, and false answers are tolerated rather than rejected. The authorisation warning and publication audience are exactly the behavioural context annotations cannot carry.

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 action, then the sibling contrast, then the operational facts (free, prerequisite, gap handling, authorisation). Every sentence carries distinct information; the terse 'No account, no key, one call.' is efficient signalling 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 5-parameter, nested-object mutation with no output schema, it covers prerequisites, authorisation, publish consequences, and gap semantics. It stops short of saying whether re-filing replaces a prior attestation or how a filed attestation can be corrected, though idempotentHint gestures at repeat-call behaviour.

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 the baseline is 3, but the description adds workflow meaning the schema lacks: control ids must come from baseline_controls, gaps are answered false, and gapPlan is the companion field for those falses. It does not clarify the entity-vs-agentId relationship beyond what the schema says, keeping it 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+resource ('File your operator's control-baseline attestation') and immediately distinguishes it from the named sibling counterparty_control_baseline by direction of disclosure ('that tool asks what controls the OTHER side runs; this one publishes what YOUR side runs'). An agent can select correctly without opening either 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?

Explicitly routes the agent: get control ids from baseline_controls first, use counterparty_control_baseline when you want the other side's controls, and only file for a party you are authorised to speak for. It also pre-empts the 'what if a control isn't in place' case (answer false, explain in gapPlan), so no major decision is left to 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 read-only and idempotent behavior, so the bar is lower. The description adds real context beyond them: the controls are pre-money-movement gates, each is yes/no answerable, and each discloses its enforcing layer, which tells the agent what the payload contains.

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 tight sentences, front-loaded with the resource definition followed by the call-ordering instruction. 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?

No output schema exists, but the description compensates by explaining the return payload (yes/no controls with enforcing layers). For a zero-param read tool with annotations, 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?

Zero parameters, so the baseline is 4. The description correctly adds nothing about inputs and instead describes what the output conveys.

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 (Fetch) plus a named resource (OceanAlt Agent Control Baseline) described as controls an agent operator runs before money movement, each answerable yes/no. That concrete framing distinguishes it from siblings like attest_control_baseline and counterparty_control_baseline.

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 call it: before attest_control_baseline, so the agent files against real control ids. This is a genuine ordering dependency that routes the agent correctly.

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 readOnlyHint=false and openWorldHint=true; the description carries the critical extras — it moves REAL money, needs OCEANALT_PAYER_KEY, costs $0.01 USDC on Base mainnet (eip155:8453), the price/network should be confirmed at a live URL, and a dedicated low-balance wallet is advised. This is exactly the beyond-annotation disclosure that matters for an irreversible paid call.

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?

Well front-loaded: purpose first, then return shape, then cost rationale, then the payment mechanics. The $0.01 figure appears in both the title and body, and the payment block is dense, but nearly every clause earns its place given the money-at-risk.

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 specifies the return contract (verdict enum, risk score, blocked flag, top signal, summary counts, risky-first ordering) and adds the irreversible-cost context an agent needs before calling. Nothing material is missing for a one-parameter paid batch 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?

Only one parameter and schema description coverage is 100%, so the schema already documents the 25-item cap, address formats, and duplicate/blank handling. The description's mention of the 25 limit and address formats is a restatement rather than added 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 (screen), resource (blockchain addresses), and scope (up to 25 in a single call), then enumerates the exact return fields. The 'up to 25' batch framing implicitly separates it from the single-address sibling, so an agent can place it 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?

'Cheaper per address than screening one at a time' gives a clear cost-based reason to prefer this tool over the one-at-a-time alternative, and the supported address formats (EVM 0x…, Tron T…) frame applicability. It never names the alternative tool explicitly nor states when NOT to batch, so it falls short of the 5 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?

Annotations only cover readOnly/idempotent/openWorld; the description adds substantial context beyond them: that it is free with no API key, what it decodes per chain, the meaning of each decision outcome, and a genuine caveat that address-lookup-table accounts yield 'unknown' rather than a safe verdict. With no output schema, this return-value disclosure is exactly what the description should carry.

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 anti-blind-signing purpose, then structured by chain with parenthetical enumerations. It is dense but nearly every clause carries information a caller needs; the decoded-operation lists are the only slightly padded part.

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 does the heavy lifting on return semantics and unknown-handling, and it labels chain-specific parameters. It stops short of stating which parameter combinations are required (0 are marked required) or what happens on undecodable/malformed input beyond the lookup-table case.

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

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

Schema description coverage is 83%, so the schema already documents parallel EVM-only vs Solana-only fields, the base-units convention for amount, and network semantics. The description echoes the chain split ('EVM: ...', 'Solana: ...') but adds no format or validation detail beyond what the schema provides. Baseline 3 for high coverage 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?

Opens with a precise framing ('Anti blind-signing') then states the exact verb and resource: decode calldata / a base64 Solana transaction and compare against declared intent. It enumerates the specific decoded operations (ERC-20 transfer/approve/permit, setApprovalForAll, SPL TransferChecked, SetAuthority, etc.), which clearly separates it from siblings like verify_payment_requirements or payment_decision.

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 clear decision rule tied to the tool's use: match = proceed, mismatch = 'do not sign', unknown = not the same as safe. This tells an agent how to act on the result. It does not, however, explicitly contrast when to reach for this versus siblings such as verify_payment_requirements or payment_decision.

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 flag readOnlyHint=false and openWorldHint=true; the description goes far beyond them, disclosing the HTTP 402 handshake, that real USDC on Base mainnet moves, the required OCEANALT_PAYER_KEY, the $0.002 cost, and the alternative OCEANALT_CREDIT_TOKEN path with its credit-pack economics. It even advises confirming live price/network and using a low-balance wallet.

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?

Purpose and usage are front-loaded in the first two sentences, followed by the payment mechanics. It is long, but the length is justified by the real-money payment flow; a couple of clauses about credits and network confirmation could be tightened.

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 contract and does sketch it ('DECISION — allow | review | decline — plus advice and verifiable evidence'). Payment/auth prerequisites are fully covered; the shape of the advice/evidence payload and failure modes remain unstated, which is the only material gap.

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

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

Schema description coverage is 100%, so the schema already documents to, network, purpose, and amountUsdc, including address formats, enum chains, and the 'optional, ignored for Tron' note. The description adds no parameter-level detail 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 and resource ('Run OceanAlt's full compliance gateway on a proposed payment') and names the concrete outcome ('allow | review | decline plus advice and verifiable evidence'). The 'not just raw data' framing plus the mention of combining AML screening with RAP gate checks separates it from raw-screening siblings like screen_address.

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?

'Use this when an agent needs a go/no-go call before releasing funds' gives a clear triggering condition. It implies the raw-data alternative exists but does not explicitly name which sibling to use when a decision is not needed, nor does it state 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 only cover readOnly/idempotent/openWorld; the description goes well beyond by disclosing the free/no-API-key terms, the critical found:false semantics ('no information, not a bad signal'), and that results split into verified_by_oceanalt versus self_claimed with the latter unverified. These are exactly the behavioral traits 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?

Dense but every sentence carries load: positioning, control enumeration, verified vs. self-claimed split, and the found:false caveat. The opening 'Answers a different question from address screening' front-loads the differentiator, though the paragraph is long enough that the found:false warning arrives late.

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, so the description must explain return values, and it does: verified_by_oceanalt, self_claimed, and a found flag with interpreted meaning. For a read-only lookup with no required parameters, nothing an agent needs to call and correctly interpret it 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% and both parameters (entity, agentId) are documented in the schema itself. The description adds no lookup syntax, precedence, or fallback guidance beyond what the schema 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?

States a precise resource and the exact question it answers: a counterparty's self-attestation against the OceanAlt Agent Control Baseline, including what controls are checked (spending ceiling, payee restriction, credential revocation). It explicitly distinguishes itself from the sibling screen_address by framing screening vs. control-baseline as different questions.

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 clear usage context (checking controllable damage exposure before paying) and an explicit when-not rule: a found:false result is not a bad signal and must not be the sole basis for declining a payment. It does not name the write-side sibling attest_control_baseline or clarify entity vs. agentId lookup preference, so it stops short of full alternative routing.

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

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

Annotations only carry readOnlyHint=false and openWorldHint=true; the description adds substantial behavioral context beyond them: PAID via x402, moves REAL money, requires OCEANALT_PAYER_KEY, costs $0.01 USDC settled on Base mainnet, recommends a dedicated low-balance wallet, and states the analysis limits (main path only, depth ≤3, no hit does not prove cleanliness). This is far richer than the 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-loads purpose, then payment mechanics, then limitations, with no filler sentences. It is dense and slightly long, mixing four concerns (scope, payment, cost, caveats) into one paragraph, but every clause carries operational weight.

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?

Covers the operation, payment model, network, cost, key requirement, and limitations thoroughly — the critical facts for safe invocation. With no output schema, it does not describe the return structure (hop details, hit categories), which is the one remaining gap for a paid tracing 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?

Single required parameter with 100% schema description coverage, so the schema already documents the address format. The description confirms the Tron-only constraint and reaffirms 'USDT' semantics, adding marginal value over the schema but nothing on syntax. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Trace a Tron (TRON) USDT address up to 3 hops back along its largest incoming transfers') and precisely what it checks for (Tether-frozen, sanctioned, mixer, scam upstream). It explicitly distinguishes itself from a single-address screen ('deeper than a single-address screen'), routing the agent away from the sibling screen_address.

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 clear context for when this is the right call versus a shallow screen ('deeper than a single-address screen') and scopes applicability ('Tron only (T…)'). It stops short of an explicit when-not or directly naming screen_address as the lighter alternative, but the comparative framing is unambiguous.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: discloses that output is Ed25519-signed and offline-verifiable, that OceanAlt assumes a witness posture with no person attribution, that all data is already public with no privileged channel, and gives an explicit rate limit. This is exactly the extra context annotations cannot carry.

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-loads the deliverable and its contents, then layers in the epistemic stance and rate limit. Slightly long, and the 'witness, not a plaintiff' framing is more positioning than operational detail, but nothing is redundant.

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

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

With no output schema, the description usefully enumerates what the bundle contains, so an agent knows the shape of the response. Missing only guidance on error cases (unresolvable address, unknown network) and size/pagination expectations for a large bundle.

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 formats and the optional network field are already documented in the schema. The description adds no format syntax, defaults, or semantics 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 ('Everything OceanAlt can say about an address, in one Ed25519-signed bundle') and enumerates the payload contents (verdict, profile signals, one-hop relations, receipt stats). This cleanly distinguishes it from siblings like screen_address (single verdict) and deep_trace (graph traversal).

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

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

Provides useful operational context — free, 10 per minute, anyone may request — but never states when to prefer this bundle over screen_address, deep_trace, or batch_screen. Usage is implied by the payload description rather than stated as a selection rule.

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?

Adds substantial context beyond the annotations: it is rule-based (not model judgement), readiness derives from the public registry enforcement ladder, the payer address is screened in reverse, and details the response shape (statuses, reason codes, requested_fields only on hold, evidence, signature). It does not explain the non-read-only/non-idempotent side effects implied by readOnlyHint=false and idempotentHint=false, which is the remaining gap.

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 purpose and the settle-time trigger, then progressively adds statuses, behavior, and cost. It is dense with parenthetical URLs and multi-clause sentences, but essentially every sentence carries information, so little is 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 correctly enumerates the return values and their conditional fields, and states the cost/auth posture (free, no API key). The only omission is the reason behind the non-read-only annotation, but for a query-style decision tool this leaves nothing an agent needs to call it 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 coverage is already 100%, but the description adds meaning: payee is a registry sid (with a reference), payerAddress is reverse-screened, and amount/purpose/KYA requirements are driven by the payee's own policy rather than fixed rules. This contextualizes the parameters beyond their schema prose.

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: asking the registered payee (by registry sid) whether it accepts an incoming payment, and explicitly frames itself as 'the other half of a safe agent payment,' distinguishing it from the payer-side siblings. An agent knows exactly what this does without opening the 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?

Gives a clear trigger ('before settling, ask the registered payee') and a strong retry exclusion ('decline is final — re-paying does not change it'). It stops short of naming a specific alternative tool (e.g. payment_decision) for the complementary side, so the when-vs-what routing 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 already declare readOnlyHint, idempotentHint and openWorldHint, so the bar is lower, yet the description adds real context: free, no API key, no signup, machine-executable decision values, verifiable evidence, retry semantics, and the attachable compliance attestation. It stops short of describing latency, coverage limits, or what evidence fields look like.

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

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

Front-loaded with the core instruction ('Before your agent pays, call OceanAlt once') and ordered by decision-critical information before the free/pricing aside. Slightly dense, but nearly every clause (decision values, attestation, sibling pointer) earns its place.

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

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

There is no output schema, so the description carries the return-value burden and does so — it names the three decision outcomes, verifiable evidence, retry semantics and the attestation. Combined with the annotations, an agent has everything needed to call and interpret this correctly.

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

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

Schema description coverage is 100% and the schema already documents address formats, the network enum, lang, purpose and amountUsdc. The description only reiterates that the payee address is the input, adding no format or constraint detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource — decide whether to pay a given address before an agent pays — and enumerates the exact output values (allow | review | decline). It also names the sibling it is not (compliance_decision), so an agent can distinguish it without opening schemas.

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 frames usage as a gate in an autonomous payment flow, gives the deciding condition ('if the decision is not "allow", do not pay'), and routes to compliance_decision when settlement on x402 rails is also needed. When-to-use and when-to-use-something-else are both covered.

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, so the safety profile is partly covered. The description adds important behavior beyond that: the returned set is a 'representative sample' rather than an exhaustive list, includes source category and reason per address, takes no arguments, and is free with no API key. It does not mention rate limits or response size limits.

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 tight sentences with no filler. It front-loads the core purpose, then use cases, then the no-argument/free constraint, so an agent can parse the key facts 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?

For a simple zero-argument list tool with no output schema, the description is complete enough: it names the resource, the categories, the per-address return fields (source category and reason), and the sample/no-argument/free constraints. Pagination details are not relevant because it returns a representative sample rather than a paginated full 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?

With zero parameters and 100% schema description coverage, the baseline is 4. The description confirms 'Takes no arguments', which is consistent with the empty schema but adds no parameter-level meaning beyond it.

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

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

The description states a specific verb and resource: 'Return a representative sample of addresses on OceanAlt's reviewed risk list', and breaks the list into concrete categories (OFAC-sanctioned, mixers, scam/phishing). This is clearly a read/list tool rather than a screening tool, but it never names a sibling like screen_address or batch_screen to make the distinction 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?

It gives clear usage contexts — grounding, showing what gets blocked and why, and a quick read on the threat surface — which tells an agent when this tool is a good fit. It does not, however, state when NOT to use it or name the screening alternatives for checking a specific address.

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

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

Beyond the annotations (readOnly, idempotent, openWorld), it discloses rich behavioral semantics: completeness is a factual count not a score, a broken link marks where accountability stops, publication is opt-in with only posture exposed (ceiling existence, never its value), and found:false means absence of information rather than a negative signal. This is exactly the extra context annotations can't convey.

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

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

The description is on the longer side but front-loads the purpose before moving into behavioral nuance, and each sentence (completeness semantics, opt-in publication, found:false meaning, free/no-key) carries distinct information. Minor redundancy with the title's 'free' claim keeps it from a 5.

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 must explain return values, and it does: the per-link hold status, the completeness count, and the meaning of found:false. For a single-parameter resolution tool this is complete enough to call and interpret 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?

With a single parameter and 100% schema description coverage, the schema already defines agentId fully. The description explains what the resolved subject is but adds no syntax, format, or constraint 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?

The description states a specific verb (resolves) and resource (the chain of accountability behind a paying agent), enumerating the chain links agent → principal → mandate → credential → wallet. This is more specific than a bare restatement, but it does not distinguish itself from siblings such as deep_trace or payee_decide, so no routing help is offered.

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

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

It gives a clear use context — gathering what you need before accepting a payment from an autonomous agent — which implies the trigger condition. However, it names no explicit alternative tool or when-not-to-use case, so an agent must still infer when another sibling is a better fit.

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 safety (readOnly, idempotent, openWorld), yet the description adds substantial context beyond them: what data sources are checked (OFAC, mixers, scam lists, issuer freezes, on-chain heuristics), the three verdict values, a 0-100 score and blocked flag, the important caveat that 'clear' is not a safety guarantee, and chain-dependent screening depth. It also discloses no auth or cost barrier.

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?

It is a dense block rather than short sentences, but it is front-loaded with the action and trigger, and nearly every clause carries distinct information. The trailing 'Free, no API key, no signup' slightly duplicates the title and cost framing already stated, a minor 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 must describe the return payload, and it does precisely: verdict enum, 0-100 risk score, blocked flag, and clickable evidence. It also flags the critical interpretive limit of a clear verdict and points to an external coverage document for chain depth.

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

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

Schema description coverage is 100%, so the schema already documents address formats, lang, and the network enum (including auto-detection behavior). The description restates the supported address families (EVM, Tron, Solana) but adds no new format or syntax detail, 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 and resource — 'Run an AML compliance screen on a single blockchain address' — and the word 'single' implicitly separates it from the sibling batch_screen. An agent knows exactly what this tool does and at what granularity without opening the 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?

Gives a clear trigger condition ('BEFORE paying or receiving from it') that tells the agent when in the workflow to call it. It does not explicitly name batch_screen as the alternative for multiple addresses, but the 'single address' scoping makes the division of labor inferable.

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, idempotent, open-world), and the description adds substantive behavior beyond them: what is actually checked (hostname and parent domains vs. public phishing lists plus shape signals), the four-value return vocabulary with language-independent signal_keys, and the crucial caveat that 'clear' means no match was found, not that the endpoint is safe. It also discloses cost and no API key requirement.

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 action and the sibling distinction, and each sentence carries information — the x402 flow sentence justifies why endpoint-level screening is needed. It is somewhat dense and the threat narrative could be tightened, but nothing is pure 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?

No output schema exists, so the description takes on the burden of explaining the return values, and it does so precisely: the four-level verdict, the meaning of signal_keys, and the critical semantics of 'clear'. Combined with the flow context and cost disclosure, an agent has everything needed to call and interpret this correctly.

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

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

Schema description coverage is 100% and the single 'url' parameter is fully documented in the schema (full URL or bare domain, with examples). The description's 'URL or domain' phrasing merely restates the schema, adding no format, normalization, or edge-case guidance beyond it, 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 (screen) and resource (payment ENDPOINT: URL or domain) and explicitly positions itself against the sibling screen_address — 'the half that address screening cannot answer.' An agent can route between the two without opening either 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?

Gives clear timing ('before calling it') and the x402 discovery context in which the URL arrives, plus an explicit pairing instruction ('Use together with screen_address'). It stops short of stating when this tool should NOT be used or what to do with a 'caution' result, so it is clear context rather than full when/when-not 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 cover readOnly/idempotent/openWorld, and the description adds genuinely new behavioral detail: the full reason-code enumeration (ok | no_signature | digest_mismatch | signature_invalid | key_unavailable | payto_mismatch | amount_mismatch), the guarantee boundary, and 'Free, no API key'. Strong added context beyond 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?

Front-loads the threat model, then the mechanism, then the input contract and outcome vocabulary, closing with cost and limitations. Every sentence carries selection-relevant information with no filler.

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

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

With no output schema, the description still specifies the return shape ('verified true/false with a reason code') and the enumerated codes, plus auth (no API key) and the limits of the guarantee. Nothing an agent needs to call or interpret it 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%, so the baseline is 3; the description adds marginal value by tying the optional expect.payTo/expect.amount inputs to specific outcome codes (payto_mismatch, amount_mismatch) and clarifying that keys_url falls back to the value inside the signature. It reinforces rather than replaces 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 (verify) and resource (signed x402 402 payment requirements) and explains the concrete attack it guards against (transit tampering of payTo). It is clearly distinguishable from sibling screening/tracing/decision tools, which do not touch x402 signing.

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 clear context for use ('Sellers who sign their payment requirements with OceanAlt...') and an explicit scope boundary: it defends against in-transit tampering, not a compromised seller origin. It stops short of naming an alternative sibling when the seller does not sign, but the when-to-use condition is unambiguous.

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