AgentFeed

Solana holder clusters

get_sol_holder_clusters

Read-onlyIdempotent

Use when an agent needs to know whether a Solana token's holders are one owner. Returns the account that first funded each of the top 20 wallets, the clusters sharing a funder and their supply share. A shared funder can be an exchange. Costs 0.008 USDC per call (x402, USDC on Solana, Base, Polygon, Arbitrum or Arc).

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": {
      "mint": "<mint>"
    },
    "name": "get_sol_holder_clusters"
  }
}

Input Schema

Name	Required	Description	Default
`mint`	Yes	the SPL token mint address

Output Schema

Name	Required	Description	Default
`data`	Yes	the get_sol_holder_clusters payload; a real captured example is free at https://x402.ochinimus.app/api/sample/get_sol_holder_clusters
`tool`	Yes	the tool that produced this payload

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026
- addedInput schema / properties / mint / maxLength
```
Added value: +44
```
- addedInput schema / properties / mint / minLength
```
Added value: +32
```
- addedInput schema / properties / mint / pattern
```
Added value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$"
```
AddedOct 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent/non-destructive safety profile, so the bar is lower. The description still adds non-obvious operational context the schema cannot: a per-call cost of 0.008 USDC via x402 across five settlement chains, and the caveat that a shared funder may be an exchange, which prevents misreading the output. It does not discuss failure modes or what happens for tokens with fewer than 20 holders.

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?

Three sentences, front-loaded with the usage trigger and immediately followed by the return semantics. Mostly tight, though the chain enumeration in the pricing sentence adds bulk that could be collapsed.

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?

Output schema exists, so return shape need not be explained, and annotations carry the safety profile; purpose, output gist, scope limit (top 20) and price are all present. Minor gaps remain around small-holder tokens and how clusters are derived, but nothing an agent needs to invoke it correctly is missing.

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?

With a single required parameter at 100% schema description coverage, the schema already documents 'mint' as the SPL token mint address with a base58 pattern. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('know whether a Solana token's holders are one owner') and then names exactly what is returned: the funder of each of the top 20 wallets, the clusters, and their supply share. That is distinguishable at a glance from sibling holder tools such as get_token_holders or get_sol_token_check.

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

Usage Guidelines4/5

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

Opens with an explicit trigger ('Use when an agent needs to know whether...'), which gives a clear selection condition. It stops short of naming alternatives or exclusions (e.g. 'for a full holder list use get_token_holders'), so it is strong context but not full routing guidance.

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

All AgentFeed tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.