Skip to main content
Glama

Iris

Trace a transfer through a mixer, exchange or swap service

trace_transfer
Read-only

Follow one transfer through the mixer (Privacy Cash, Cloak, Umbra, encrypt.trade, MagicBlock Private Payments, ShadowWire...), exchange, or instant-swap service (SideShift, ChangeNOW, FixedFloat, SimpleSwap, StealthEX, Changelly...) on its other side, by timing and amount: for a deposit, the withdrawals that match it after; for a withdrawal, the deposits that match it before. Gives the likely wallets with a confidence, and how many transfers of the same amount could also fit (the anonymity set). A swap service pays out in another asset, often on another chain: a deposit into SideShift is matched exactly from SideShift's public record of completed shifts (the coin, network and amount it paid out, and the Solana recipient), any other by value at the prices of the time (1 of N candidates). One-time deposit addresses that sweep to the service count as the service. Give the wallet and the signature (transaction hash) of a transaction where it sent money to, or received money from, a mixer, an exchange or a swap service (analyze_address and get_connections list them). Off Solana: on Tron through an exchange or an instant exchange, on an EVM chain through an instant exchange or a privacy pool (Tornado Cash, Railgun, Privacy Pools), on Bitcoin through a CoinJoin or an instant exchange. The chain is read from the wallet's address (pass chain for an EVM chain other than Ethereum). Costs 1 trace (or 3 pack credits), or without an API key $0.25 paid per call with x402; refunded (never settled) if it fails. Results are leads, not proof.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoThe transfer's chain, when the wallet's address doesn't say it: an EVM chain for a 0x wallet (ethereum by default).
walletYesThe wallet whose deposit or withdrawal is traced (not the exchange or the mixer).
directionNoOptional, with counterparty: out when the wallet paid it (a deposit), in when it paid the wallet (a withdrawal).
signatureYesThe transaction: a Solana signature (base58), an EVM or Tron transaction hash, or a Bitcoin txid.
counterpartyNoOptional: the exchange, swap service or mixer wallet (or pool contract) on the other side, when the transaction moved money with several. Iris picks the one it knows otherwise.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses matching heuristics, confidence output, anonymity set size, exact matching for SideShift versus value-based matching for other services, chain inference, cost/credits/x402 behavior, refunds on failure, and that results are leads rather than proof. There is no contradiction with readOnlyHint, openWorldHint, or idempotentHint.

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 core purpose is front-loaded and the description is dense with useful behavioral detail. It is quite long and list-heavy, especially the parenthetical service examples, so it could be tightened without losing essential meaning.

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?

There is no output schema, and the description explains what the agent gets back: likely wallets with confidence, anonymity-set size, exact swap-service matches versus candidates, and the caveat that results are leads. It also covers supported chains, cost, failure behavior, and scope constraints.

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 100%, so the parameters are already documented. The description still adds useful interpretation for tracing direction, deposit-versus-withdrawal matching, and chain inference from the wallet address, though it adds little beyond the schema for the counterparty parameter.

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 verb and resource: following one transfer through a mixer, exchange, or swap service to the matching deposits or withdrawals on the other side. It also distinguishes the tool from siblings by noting that analyze_address and get_connections identify the relevant transactions, while this tool traces a specific one.

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?

The description clearly says to provide the wallet and signature of a transaction where the wallet sent money to or received money from a mixer, exchange, or swap service, and it names supported contexts such as Tron, EVM chains, and Bitcoin. However, it does not give an explicit decision rule for when to use analyze_address/get_connections first versus when to call this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources