Trace fund flow

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety bar is low. The description adds real behavioral value beyond that: breadth-first expansion, USD valuation via DefiLlama at transfer time, and resolution of bridge transactions to destination chain/address. It omits cost, latency, and result-size caps, which matter for a multi-hop graph expansion.

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

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

Three sentences, no filler. The mechanism and return shape are front-loaded before the use case, so the agent gets the what before the why.

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

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

With 13 parameters, no output schema, and mid coverage, the description does the important work of describing return contents and traversal semantics. It leaves node/edge sizing limits (maxNodesShown, maxEdgesShown, perNodeTransfers) unexplained and gives no guidance on choosing hops, which is the main tuning decision for this tool.

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

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

Schema description coverage is 62%, a middle band where the schema carries most parameter meaning. The description adds concept-level semantics for direction ('forwards = where money went, backwards = where money came from') and hop depth, but says nothing about branchFactor, perNodeTransfers, or the case-save parameter. Baseline 3 fits.

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

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

States a specific verb and resource ('Breadth-first fund-flow graph from a wallet') plus scope (forwards/backwards, up to N hops), which clearly separates it from siblings like get_transfers or find_counterparties. It also enumerates what comes back (nodes, weighted edges, terminal sinks, circular flows), so an agent knows the shape of the result without opening any schema.

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

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

Names the primary use case ('following stolen or laundered funds'), which is real context, but never says when to prefer a sibling — e.g. get_transfers for a flat transfer list, follow_bridge for a single bridge hop, or analyze_wallet for general profiling. Usage is implied by the scenario rather than explicitly routed.

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