Onyx AML

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

With no annotations provided, the description carries the full disclosure burden. It usefully states this call is "Free" (no credit consumed) and implies read-only access scoped to "your API key", but says nothing about authentication requirements, rate limits, or behavior on an exhausted/invalid key — a notable gap for a billing-adjacent endpoint.

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 short clauses with zero filler, front-loading the primary return value (remaining credit) before the secondary one (prices). Nothing is padded or repeated from the title.

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 zero-parameter, no-output-schema tool, the description adequately covers what comes back at a high level. It is slightly thin on the nature/format of "current prices" and on failure modes, but an agent has enough 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly declines to invent any input requirements.

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

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

The description names the concrete resource returned (remaining credit for the API key) plus a secondary output (current prices), so an agent knows exactly what this call yields. It does not, however, differentiate itself from the nearby onyx_payment_info sibling, which the agent may conflate with billing/credit queries.

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

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

There is no statement of when to call this versus onyx_payment_info or the other siblings, and no prerequisites or sequencing guidance. The word "Free" implies cost-free invocation but is not framed as usage 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?

With no annotations, the description carries the full burden and does well: it names the data sources checked (USDT/USDC blacklists, sanctions across six EVM chains plus OFAC, scam DBs, community reports, behavioural patterns) and warns 'Costs credit', which is important for agent budgeting. It omits auth requirements and rate limits, so it falls short of 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?

Three short sentences, front-loaded with the return values, then the usage trigger, then the cost warning. Every sentence earns its place 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 and no annotations, the description must stand alone, and it communicates the return shape (allow/review/deny with named reasons) and the credit cost. Given the nested policy object and multiple risk sources, it covers the essentials, though the interaction between policy and default behaviour could be spelled out more.

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, amount_usd, and the nested policy object including the conservative default. The description adds only a passing reference to 'your own risk policy' and no syntax or semantics beyond the schema, 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 ('Return allow / review / deny for a counterparty address') and names the exact output vocabulary, which no sibling provides. An agent can tell this is the decisioning tool versus the screening siblings 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?

'Use this before every outbound transfer' gives a clear triggering context. However, it does not explicitly distinguish itself from onyx_screen, onyx_screen_batch, or onyx_preflight, so the agent must infer the routing.

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

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

With no annotations, the description carries the full burden and usefully discloses the auth profile: no account, no signup, no key required. This is real behavioral context an agent needs before calling. It stops short of covering rate limits, response format, or whether the data is static — acceptable for a zero-parameter info tool.

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

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

Two short sentences with the payload (what terms are returned) front-loaded. The second sentence slightly overlaps ideas – 'no account or signup', 'free', 'works without a key' restate the same no-auth point with some 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?

No output schema exists, but the description enumerates the returned fields (asset, network, address, prices, claim instructions), so an agent knows what to expect. For a zero-param informational tool with no annotations, this is nearly complete; sequencing relative to payment/screening siblings is the only missing piece.

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 zero parameters, so the baseline is 4. There is nothing for the description to compensate for, and the schema is empty as expected.

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 specific resource – machine-readable payment terms – and enumerates its content (asset, network, address, per-operation prices, API key claim). It clearly distinguishes this informational tool from operational siblings like onyx_screen or onyx_watch, though it never states the verb explicitly (e.g., 'returns'/'fetches').

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 implies the tool is the entry point for payment/key acquisition ('how to claim an API key'), but gives no explicit when-to-use-vs-alternatives guidance or sequencing (e.g., call this before onyx_screen). Usage is left to inference from the sibling set.

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?

No annotations are provided, so the description carries the burden, and it does disclose meaningful behavior: the check is orthogonal to risk screening, coverage is partial even for dedicated transaction-security services, and one detection mode is inert unless known_addresses is supplied. It stops short of describing what a result looks like or what happens on an inconclusive address, 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?

Core capability is front-loaded in the first two sentences and the call-to-action lands last. The live-traffic statistic sentence is persuasive padding rather than operational guidance, costing it a point, though it does reinforce why the tool matters.

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 annotations and no output schema, the description should say what a caller gets back — a verdict, a list of findings, a boolean — and it does not. The inputs, when to use it, and why it matters are all covered, so it is viable but leaves the agent guessing at the return shape.

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 would be 3, but the description adds genuine meaning beyond the schema by explaining that known_addresses is the switch that turns on poisoning detection and that omitting it degrades the check. That is causal information the schema's 'Strongly recommended' does not convey.

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 ('operational safety check for a payment') and enumerates exactly what it detects: address poisoning, contract recipients that swallow tokens, and chain-dependent behavior. It explicitly separates itself from risk screening, which distinguishes it from onyx_screen and the AML-flavored siblings.

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 direct usage rule — 'Run this together with onyx_decide before every payment' — plus a conditional instruction that known_addresses is what enables poisoning detection. It also carves out the alternative space by noting AML screening does not cover this class of loss.

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 no annotations, the description carries the full burden and does disclose a real behavioral trait: the call costs credit (a billing/quota constraint) and returns raw data rather than a verdict. It still omits error behavior for unsupported chains, rate limits, and auth requirements, but read-only semantics are strongly implied by 'return the raw risk markers'.

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, the return payload front-loaded followed by the usage cue and the cost note. No filler, no repetition of the title, and every clause carries information.

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

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

There is no output schema, so the description must describe return values, and it does so thoroughly via the marker list. Remaining gaps are edge-case behavior such as unsupported address formats or partial data, which are minor for a single-argument read 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?

One parameter with 100% schema description coverage, so the schema already documents the address and its supported chains (TRON, Ethereum, EVM, Solana). The description adds no syntax, format, or validation detail beyond what the schema provides, making baseline 3 correct.

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 (return) plus the exact resource (raw risk markers for one address) and enumerates the constituent markers: risk zone, blacklists, sanctions, scam DBs, reports, age, balance, exchange attribution. The phrase 'one address' cleanly separates it from the sibling onyx_screen_batch, and 'the facts rather than a decision' separates it from onyx_decide.

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 names the selection condition: use it when you want raw facts rather than a decision, which routes the agent away from onyx_decide. The batch alternative is only implied by 'one address' rather than named, so the when-not guidance is slightly incomplete.

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 no annotations, the description carries the full burden and does well: it discloses the pricing model ('priced per address, and only addresses actually screened are charged') and partial-result semantics via the facts_complete field. It omits auth requirements, rate limits, and how invalid or failed addresses are handled, but the cost and completeness disclosures are meaningful beyond the 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?

Three front-loaded sentences with no filler: batch scope first, then cost, then the result-completeness signal. Each sentence carries distinct information, though the phrasing could be marginally tighter.

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, no-output-schema tool with no annotations, the description covers the key agent-facing concerns: batch size, cost, and how to detect incomplete screening results. Missing only failure/error behaviour and what the result payload contains beyond facts_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?

There is a single parameter with 0% schema description coverage, and the description only restates the limit ('up to 50 addresses') that maxItems already encodes. It adds no meaning about address formats or accepted chains, though the schema's items description covers those formats.

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 ('Screen') and resource ('addresses') plus a batch scope ('up to 50 addresses in a single call'), which implicitly distinguishes it from the singular onyx_screen sibling. It does not name onyx_screen explicitly, so an agent must infer the single-vs-batch split from the scope wording.

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 offers one usage scenario ('for example before a mass payout'), which implies the intended context, but gives no explicit when-not guidance and never names onyx_screen as the alternative for one-off lookups. Usage is implied 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?

With no annotations, the description must carry the full behavioral burden. It usefully discloses directionality (outgoing only), attribution/labelling behavior, and a relative cost signal, but says nothing about hop depth limits, latency, rate limits, or authentication requirements.

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

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

Three short sentences, front-loaded with the operation and scope, then usage, then cost. No filler and every clause carries decision-relevant 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?

For a single-parameter trace tool with no annotations and no output schema, the description covers operation, direction, attribution, and cost. The notable gap is trace depth/boundaries (how many hops) and what a result contains, though return-value detail is largely exempted here.

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 coverage is 100%, so the schema already documents the address and its supported chains. The description adds no format or syntax detail beyond what the schema provides; 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 (trace) and resource (outgoing flows from an address), and adds the distinguishing traits 'multi-hop' and 'attribution where a node is known'. It is clearly separable from onyx_balance or onyx_watch, though it never names a sibling explicitly, only implying onyx_screen via 'screening 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?

Gives an explicit use case ('establish provenance after receiving funds') and a relative-cost cue ('costs more than a screening call') that lets an agent choose it over a cheaper screen. It does not state when not to use it or what a trace cannot resolve.

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 no annotations, the description carries the full burden and does well: it discloses the delivery mechanism (signed POST to callback), the cost model (billed per address per day) and a hard constraint (callback must be public https). It omits lifecycle details such as how the subscription is cancelled or whether retries occur.

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?

Four tight sentences, front-loaded with the core action and trigger, then rationale, then billing and the callback constraint. Every sentence adds signal; no 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?

For a two-parameter subscription tool with no annotations and no output schema, the description covers purpose, trigger conditions, delivery, cost, and constraint. It leaves the subscription lifecycle (unsubscribe/response value) unaddressed, a minor 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 coverage is 100%, so both parameters are already documented in the schema; the description's 'callback must be public https' largely restates the schema's 'Public https URL to receive events'. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

States a specific verb+resource ('Subscribe to an address') and immediately defines the trigger semantics (blacklist/sanctions/scam list). It also distinguishes itself from the one-off screening siblings by stating that a single check 'cannot warn you about a freeze that has not happened yet'.

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?

Clearly signals when to reach for this tool (continuous monitoring to catch future events) versus a one-off check, but it never names the alternative sibling (e.g. onyx_screen) or states explicit when-not conditions.

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