coin-scout

Overview Schema Source Related Servers Discussions Admin

Trace fund flow

trace_funds

Read-onlyIdempotent

Follow fund flows from a Solana wallet forwards or backwards across up to five hops to map nodes, weighted edges, terminal sinks, and circular flows for theft or laundering investigations.

Instructions

Breadth-first fund-flow graph from a wallet, forwards (where money went) or backwards (where money came from), up to N hops. Returns nodes, weighted edges, terminal sinks and detected circular flows. The core tool for following stolen or laundered funds.

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": "trace_funds"
  }
}

Input Schema

Name	Required	Description	Default
`case`	No	Save the result into this case file (created if missing) so later work and exports can use it
`hops`	No
`mint`	No	Restrict the trace to one token mint
`address`	Yes	Base58 Solana address
`direction`	No	out = follow money leaving; in = follow money arriving	out
`followEvm`	No	For crossings to an EVM chain, trace the destination address 2 hops further on that chain (up to 3 destinations)
`minAmount`	No	Ignore transfers below this UI amount — key for cutting dust noise
`sinceUnix`	No
`usdAtTime`	No	Value every edge in USD at the time of each transfer (DefiLlama historical prices)
`branchFactor`	No	How many highest-value children to expand per hop
`followBridges`	No	Stop at Wormhole/deBridge/Mayan/Circle CCTP transactions and resolve the destination chain and address
`maxEdgesShown`	No
`maxNodesShown`	No
`perNodeTransfers`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.0Nov 6, 2026

changedInput schema / properties / followBridges / description

Previous value: -"Stop at Wormhole/deBridge/Mayan transactions and resolve the destination chain and address"New value: +"Stop at Wormhole/deBridge/Mayan/Circle CCTP transactions and resolve the destination chain and address"

addedInput schema / properties / followEvm

Added value: +{
+  "default": false,
+  "description": "For crossings to an EVM chain, trace the destination address 2 hops further on that chain (up to 3 destinations)",
+  "type": "boolean"
+}

First observedv0.0.0-developmentOct 17, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish it as a read-only, idempotent, open-world operation. The description adds genuine context beyond that: the BFS traversal strategy, the default forward direction, and the fact that a case file and graph outputs (nodes, weighted edges, terminal sinks, circular flows) come back. It does not disclose runtime cost or result-size limits, which for a multi-hop graph query would be valuable.

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

Conciseness5/5

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

Three sentences, each doing distinct work: what the traversal is, what it returns, and why it matters. The direction semantics are front-loaded and there is no filler.

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

Completeness4/5

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

With no output schema, the description usefully names the return shape, and it frames a 14-parameter graph tool well enough to invoke. The remaining gap is routing versus trace_evm and follow_bridge, which an agent facing near-duplicate fund-following siblings would benefit from.

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

Parameters3/5

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

Schema coverage is 64% across 14 parameters, and the richer parameters (branchFactor, followEvm, followBridges, minAmount) already carry their own descriptions. The prose only echoes hops and direction, both of which are fully documented in the schema, so it adds marginal meaning beyond structured fields. Baseline 3 is appropriate.

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

Purpose4/5

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

States a specific resource and operation: a breadth-first fund-flow graph from a wallet, with forward/backward direction and hop depth. An agent can immediately grasp what it produces. It stops short of distinguishing itself from the sibling trace_evm or follow_bridge, so it is clear but not sibling-differentiated.

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?

The phrase 'core tool for following stolen or laundered funds' implies the investigative context in which it should be picked, but there is no explicit when-not-to-use or alternative routing. With trace_evm and follow_bridge in the sibling list, the definition should say which chain or crossing case belongs to whom; it leaves that to inference.

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