Skip to main content
Glama

trace

Read-only

Follow the money out of one transaction on BNB Smart Chain, Ethereum, Base or Arc, wallet to wallet: native coin anywhere in its call tree (so a drainer contract's payouts count) and every token transfer it logged, then each receiving wallet's outgoing transfers that pass that amount on (first in, first out, wallets funded twice followed once for the sum), up to depth hops (1 to 5, default 3). A swap doesn't end the trail: it continues with what came back. Each trail ends at a mixer (Tornado Cash pools and routers on Ethereum and BSC, labeled with the pool), a contract (exchange, bridge, router, pool; known ones labeled), a busy exchange or service wallet, a wallet still holding the funds, a burn, or the depth limit; ends lists which, with the amount that reached it. Up to 80 hops. Not charged if the transaction isn't found (404) or moved nothing (422). Costs $0.01 per successful call in USDC on Base, Polygon, Arbitrum, Avalanche, BNB Smart Chain (USDT) or Solana, paid with x402 in the call's _meta; failed calls are free.

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": {
      "hash": "<hash>"
    },
    "name": "trace"
  }
}

Input Schema

NameRequiredDescriptionDefault
hashYesTransaction hash on the chosen chain
chainNobsc (BNB Smart Chain, the default), eth (Ethereum) or base (Base)
depthNoHow many hops to follow, 1 to 5 (default 3)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond the readOnlyHint/openWorldHint annotations: it discloses cost ($0.01 per successful call), the x402 payment mechanism and accepted chains/tokens, that failed calls and 404/422 responses are free, the 80-hop cap, and exactly how a trail terminates (mixer, contract, exchange wallet, holder, burn, depth limit).

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?

Front-loaded with the core action and scope, and every clause carries substantive information. It is a single very dense paragraph with long parenthetical chains, which slightly hurts scannability, but there is no filler.

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?

With no output schema in play, the description still explains the shape of the result ('ends lists which, with the amount that reached it'), the hop cap, and the failure/billing semantics. For a complex multi-hop tracing tool, an agent has everything needed to call it and interpret results.

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 baseline is 3, but the description adds meaning the schema does not: depth is defined as fund-flow hops with the FIFO re-funding rule ('wallets funded twice followed once for the sum'), and chain is framed as the chain of the traced transaction. The only gap is the description naming 'Arc' while the schema's chain description lists only bsc/eth/base.

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?

Opens with a specific verb and object: 'Follow the money out of one transaction' on named chains, wallet to wallet. It clearly delineates the resource (native coin call tree + logged token transfers) and scope (up to depth hops, up to 80 hops), which distinguishes it from read-only snapshot siblings like transaction-preview or scan.

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

Usage Guidelines3/5

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

It richly describes how the trace behaves once invoked (swap continuation, FIFO re-funding, terminus types) and notes billing exemptions for 404/422, but never states when to choose this over a sibling such as transaction-preview or scan, nor any precondition beyond having a hash. Usage context is implied by the semantics rather than stated as guidance.

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