This article walks through the Argos MCP server we built and how we used it to investigate a real money laundering operation on Ethereum, from Tornado.Cash deposits through a collector wallet to a THORChain cross-chain exit. We also show how gas fingerprinting can de-anonymize mixer users.
Why We Built an MCP Server for Argos
Argos is our blockchain intelligence platform. It aggregates data from multiple sources (our own OCaml analysis backend, Arkham Intel, Blockscout, Etherscan, Sourcify) to help compliance teams and forensic analysts investigate on-chain activity.
But a web UI, however well designed, has limits. An investigation involves dozens of lookups: check an address, look at its transactions, follow the money to the next hop, check that address, decode a transaction, look at the tags, trace fund flows backward... Each step is a page load, a click, a mental context switch.
What if you could just ask?
"Is this address linked to a mixer?"
"Where did the funds from this Tornado.Cash deposit end up?"
"Do these wallets share the same gas fingerprint?"
That's what the Model Context Protocol (MCP) enables. MCP is an open standard created by Anthropic that lets AI agents (Claude, Cursor, or any MCP-compatible client) call external tools programmatically. We built an MCP server that exposes the entire Argos API as a set of tools an AI agent can use autonomously.
How It Works
The architecture is straightforward: the MCP server is a lightweight HTTP proxy between the AI agent and the Argos API.
The MCP server sits between the AI agent and the Argos API, forwarding authentication and enriching every response with known tags.
The server exposes 17 tools covering address analysis, transaction decoding, MEV detection, fund tracing, clustering, token approvals, and multi-chain portfolio, along with 4 prompt templates for common investigation workflows.
Each tool call hits the Argos API, which automatically enriches every address in the response with its known tags and aliases. When the AI agent asks for an address's transaction history, it doesn't just get raw 0x... addresses, it gets "Tornado.Cash", "OKX", "THORChain Router" labels inline. This is the key differentiator: the AI agent can reason about entities, not just addresses.
Authentication is simple: the client sends its Argos API key in an x-api-key header, and the MCP server forwards it to the API. No additional account needed.
The Investigation: A Tornado.Cash Laundering Case
To demonstrate the MCP in action, let's walk through a real investigation. We start with a single Ethereum address and follow it to its conclusion.
Step 1 — A Clean-Looking Address
We begin with address 0xf198c3a784f0435ce0178407cd53d29693f02c44. Asking the MCP:
"Give me info on this address."
The get_address_info tool returns: no tags, no aliases, not a contract. An anonymous address. But anonymous doesn't mean innocent, it means we need to look at behavior.
Step 2 — The Behavior Reveals Everything
We pull the transaction history with get_address_transactions. The result speaks for itself:
Transaction history of 0xf198c3...: nine Tornado.Cash deposits in ~2 minutes, then a dust cleanup to an unknown address.
Nine deposits into Tornado.Cash, 8 × 0.1 ETH + 1 × 1 ETH = 1.8 ETH mixed, all within approximately 2 minutes. Then a final transfer of 0.019 ETH (the leftover dust) to an unknown address.
The Argos API automatically enriched the destination addresses with their Arkham Intel labels. We didn't need to look up each address separately, "Tornado.Cash" appeared directly in the transaction response.
The red flags are textbook: identical round amounts imposed by Tornado pool denominations, rapid consecutive deposits that indicate automation rather than manual interaction, and a dust cleanup sending the leftover to a separate wallet.
Step 3 — Following the Leftover
Tornado.Cash uses zero-knowledge proofs to break the on-chain link between deposits and withdrawals. You cannot directly trace which withdrawal corresponds to which deposit. But there's a blind spot: the leftover.
The address 0xf198c3... sent its remaining 0.019 ETH to 0xd08697... after depositing into Tornado. This is a cleanup wallet. And cleanup wallets lead somewhere.
We query get_address_transactions on the collector 0xd08697... and find it receives from ~10 different addresses within a few blocks, all with non-round amounts typical of Tornado withdrawal leftovers and relayer fees. It then consolidates everything into a single transfer of 0.573 ETH to 0x42dc29....
Step 4 — The Cross-Chain Exit
We check 0x42dc29... with get_address_transactions:
100% of outgoing transactions go to THORChain Router (0xd37bbe...), identified by Arkham Intel, including a massive swap of 554 ETH.
Using get_transaction_decode on the THORChain transaction, we can read the decoded function call:
transferOut(
to: 0xae194d89...
asset: 0x0000...0000 (ETH)
amount: 554.21 ETH
memo: "MIGRATE:25626031"
)
THORChain is a decentralized cross-chain bridge: the funds leave Ethereum and become untraceable on the destination chain (likely Bitcoin). The trail ends here.
The Full Picture
The entire operation follows a classic three-stage laundering pattern. First, Tornado.Cash to break the deposit-withdrawal link. Then a collector wallet to re-aggregate the scattered withdrawals. Finally, THORChain to exit the Ethereum chain entirely.
The Mistake: Why the Mixer Didn't Help
The whole point of Tornado.Cash is to break the on-chain link between deposits and withdrawals. But the operator made a critical error: they sent the leftover dust to the same collector that received the Tornado withdrawals.
The operator's critical error: sending the leftover directly to the collector reconnects what Tornado had broken.
By consolidating into a single collector, the operator reconnected what Tornado had disconnected. It's like wearing a mask to rob a bank and taking it off in the parking lot.
This is surprisingly common. The human instinct to not "leave money behind", even 0.019 ETH, repeatedly defeats the mathematical anonymity guarantees of zero-knowledge proofs.
Gas Fingerprinting: The Definitive Link
Beyond the fund flow, we used gas fingerprinting to definitively prove that all wallets in the operation are controlled by the same entity.
Every Ethereum transaction includes gas parameters set by the sender's wallet software. Two fields in particular, maxPriorityFeePerGas and maxFeePerGas, vary between different wallets, scripts, and tools. They act as a behavioral fingerprint.
We extracted gas parameters from every transaction in the operation using get_transaction_decode:
Gas fingerprinting: 9 wallets share an identical and unusual maxPriorityFeePerGas value, while an unrelated Tornado user shows completely different values.
The deposit transactions from 0xf198c3... (our source wallet) use 0xf as their priority fee because deposits go through the Tornado relayer, which uses its own gas settings. But the moment the same wallet sends a direct transaction (the leftover to the collector), it switches to the same unusual value found on all withdrawal wallets. Same wallet, same person, but the tool changed.
What the Gas Tells Us
The gas fingerprint proves that all ~10 withdrawal wallets are controlled by the same entity through identical and unusual gas parameters. The source wallet and the withdrawal wallets are linked because the source's direct transactions share the same distinctive fingerprint. The control group confirms this is not a Tornado or relayer artifact, and the non-round values suggest hardcoded parameters in a custom script rather than a standard wallet UI.
Even after routing funds through a zero-knowledge mixer, the operator's software configuration betrayed them.
Is This a Laundering Service?
One detail raises an important question. The exit wallet 0x42dc29... sent 554 ETH to THORChain, far more than the 1.8 ETH our source address deposited. This suggests two hypotheses.
Hypothesis A: a single operator managing a large amount across multiple source wallets.
Hypothesis B: a laundering-as-a-service operation, where the withdrawal/consolidation/exit phase is handled by a professional operator for multiple clients. This would explain why 554 ETH exits through THORChain while our source only deposited 1.8 ETH, why all withdrawal wallets share the same gas fingerprint from the same bot, and why the collector receives from many addresses in rapid succession as part of batch processing.
The volume disparity strongly favors Hypothesis B. This gas fingerprint may identify not just one laundering operation, but an entire service infrastructure.
What Argos MCP Enables
This investigation was conducted entirely through natural language queries to the Argos MCP server. No manual blockchain explorer lookups, no copying addresses between tabs, no decoding hex values by hand.
The key MCP tools we used were get_address_info to check for known tags like CEX, mixer, or sanctions flags; get_address_transactions as the core investigation tool since behavior reveals intent; get_transaction_decode to extract gas parameters, function calls, and event data; get_sourcify_info to confirm contract identity via verified source code; trace_funds for backward fund flow analysis; and get_cluster to find linked wallets belonging to the same entity.
The real power is in the automatic enrichment: every address in every API response is tagged with its known aliases and labels from multiple intelligence sources. The AI agent sees "Tornado.Cash" and "THORChain Router", not raw hex. It can follow the money, reason about entities, and build a narrative in minutes rather than hours.
What's Next
The Argos MCP server is currently in internal use at Functori. We are opening a closed beta soon for compliance teams, forensic analysts, and law enforcement partners who want to try AI-assisted blockchain investigation. The server is compatible with any MCP-enabled client, including Claude Desktop, Claude Code, and Cursor.
If you're interested in early access, reach out to us.