Skip to main content
Glama
Sign In

Onyx AML

by trade.onyxprotocol
OverviewDiscussionsAdmin

Check this is the address you mean, before paying

onyx_preflight

Operational safety check for a payment, separate from risk screening. Detects address poisoning (a lookalike planted in your history so it gets copied instead of the real address), burn addresses, token contracts and other contract recipients that would swallow the tokens (a Safe multisig or an EIP-7702 delegated wallet is reported as a wallet, not a trap), and addresses that behave differently on different chains. Pass known_addresses (the counterparties you already use) to enable poisoning detection. Verdicts: stop, caution, clear, or unknown: on EVM chains the recipient check could not run (retry, not charged); on TRON and Solana only the lookalike check exists (partial: true) and known_addresses is required. In our live-traffic sample this class of loss came up far more often than sanctioned counterparties. Dedicated transaction-security services cover part of it; no AML screening does. Run this together with onyx_decide before every payment.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "onyx_preflight"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNoThe chain you are about to pay on. The recipient is then judged on that chain (a Safe or a contract exists only where it was deployed). Without it Ethereum and Base are read.
addressYesBlockchain address (TRON, Ethereum or other EVM, Solana)
known_addressesNoAddresses you have used before, so a lookalike can be spotted. Strongly recommended.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / chain
      Added value: +{
+  "description": "The chain you are about to pay on. The recipient is then judged on that chain (a Safe or a contract exists only where it was deployed). Without it Ethereum and Base are read.",
+  "enum": [
+    "ethereum",
+    "base",
+    "bsc",
+    "polygon",
+    "arbitrum",
+    "optimism",
+    "avalanche"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden and does disclose verdict categories, EVM 'unknown' retry behavior with no charge, TRON/Solana partial coverage, and the requirement for known_addresses. It also explains which recipient types are treated as traps versus legitimate wallets, which is unusually rich behavioral context for an unannotated tool.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and organized by threat class, verdicts, and chain caveats. It is dense but largely earns its length; the live-traffic comparison is the most expendable sentence.

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

Completeness5/5

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

For a three-parameter, no-output-schema preflight check, it covers return verdicts, partial results, and chain-specific failure modes, which is what an agent needs to call and interpret it. Output fields beyond the verdict are not detailed, but the essential decision semantics are present.

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

Parameters4/5

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

Schema coverage is already 100%, but the description adds operational meaning: known_addresses enables poisoning detection and becomes required on TRON/Solana, and chain selection determines which validation path and coverage apply. Some chain details repeat the schema, so it adds value without fully replacing it.

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

Purpose5/5

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

States a specific function — operational safety check before payment — and enumerates threats such as address poisoning, burn addresses, token/contract recipients, and cross-chain differences. It explicitly distinguishes itself from risk/sanction screening and tells the agent to pair it with onyx_decide, making its role clear among siblings.

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

Usage Guidelines4/5

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

Says to run it together with onyx_decide before every payment and to pass known_addresses to enable poisoning detection, with chain-specific conditions. It does not spell out when not to use it or contrast it by name with onyx_screen, so guidance is strong but not exhaustive.

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

All Onyx AML toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources