Map a token's funding-source graph to trace wallet origins and exchange attributions, revealing how holders first received their funds.
Funding-source graph for a token: nodes are wallets, edges are first-funding relationships, labeled with exchange attributions where known.
Price: $0.01 (paid in USDC on Solana via x402).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It does usefully disclose the output structure and the monetary cost of $0.01 via x402, which is important contextual behavior. However, it does not state whether the operation is read-only, how first-funding is computed, what happens if the mint is invalid, or whether any authentication or balance is required.
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?
The description is compact and front-loads the core purpose and graph semantics before adding pricing details. Every sentence contributes distinct information, and there is no filler or redundant restatement of the tool name.
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?
For a single-parameter tool with no output schema verdict, the description gives a reasonable picture of what the agent receives: a graph with wallets and funding relationships. The pricing and payment route are unusual and helpful to include. It could be more complete by explaining the response format or first-funding definition, but the essential call-time information is present.
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 100%, so the baseline is 3. The description's reference to 'a token' aligns with the mint parameter but does not add new semantic detail beyond the schema's existing 'Solana mint address (base58)' explanation. The description therefore neither improves nor harms parameter understanding.
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?
The description clearly identifies the tool's output as a funding-source graph for a token, with nodes as wallets, edges as first-funding relationships, and exchange attributions. It distinguishes itself from sibling tools like token_stats or holder_analysis by emphasizing graph structure rather than aggregate stats or list-like data, though it does not use an explicit verb like 'get' or 'build'.
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?
No explicit guidance is given about when to use this tool versus alternatives. The description implies it is for exploring funding sources, but it does not mention when a user should prefer it over holder_analysis, token_details, or network_details_wallets. There are no exclusion criteria or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.