Skip to main content
Glama
p1xelapp

solana-nft-mcp

by p1xelapp

Who holds every item in a collection

get_collection_holders
Read-only

Get every asset in a Solana Core collection with its current owner, directly from the chain. Includes unlisted items invisible to marketplace tools; filter by trait or name prefix.

Instructions

CENSUS of a Core collection: every asset grouped under it, with its current owner, straight from the chain's asset index. This is the only tool that sees items NOBODY HAS LISTED - every other collection-wide tool reads a marketplace's listing book, so an unsold item is invisible to them. Answers 'who won the 36 packs from that drop', 'is one wallet holding half the supply', 'how many are still with the issuer', 'which wallets hold this set'. Filter to part of a collection with trait/value (e.g. Item Type = Pack) or namePrefix (e.g. 'Gold Series - Aces'). Returns the rows plus a holder count per address, largest first. Every holder row carries a ROLE: issuer (the collection's update authority, read from the chain: the issuer's key, which says nothing about how an item got there), venue-escrow (listed), wallet, or unknown (the collection account could not be read, so nobody could be checked against the issuer's key). An item currently listed for sale shows the MARKETPLACE'S ESCROW as its owner, not the seller: call get_asset_provenance on that mint to see who handed it over.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxNoMost assets to read from the index before truncating. Default 2000.
traitNoTrait name to filter on, e.g. 'Item Type'. Case-insensitive. Needs `value` too.
valueNoTrait value to keep, e.g. 'Pack'. Case-insensitive.
collectionYesCore collection ADDRESS. Use identify or search_collections to turn a name into one.
namePrefixNoKeep only assets whose name starts with this, e.g. 'Gold Series - Aces'. Case-insensitive.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.17.2

TDQS

A4.8/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint and openWorldHint annotations. It discloses that listed items show the marketplace's escrow as owner rather than the seller, that holder rows carry a ROLE field with specific meanings (issuer, venue-escrow, wallet, unknown), and that the issuer role is read from the chain and says nothing about how an item got there. It also explains the 'unknown' role condition. This is rich behavioral context that an agent needs to interpret results correctly.

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?

The description is dense but well-organized, front-loading the core purpose and key differentiator. Every sentence adds information, and the examples are useful. It is longer than average, but the length is justified by the behavioral nuances (roles, escrow ownership) that are essential for correct interpretation. Slight redundancy in the role explanation could be tightened, but overall it earns its length.

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?

For a read-only census tool with 100% schema coverage and no output schema, the description is remarkably complete. It covers what the tool returns (rows plus holder count per address, largest first), how filtering works, how to interpret roles, and the escrow caveat. It even points to a sibling tool for follow-up provenance questions. There is no critical missing information an agent would need to invoke or interpret this tool correctly.

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 description coverage is 100%, so the schema already documents all five parameters. The description adds meaningful context beyond the schema: it explains the purpose of trait/value filtering with a concrete example ('Item Type = Pack') and namePrefix with an example ('Gold Series - Aces'). It also clarifies that collection is an ADDRESS and how to obtain one. This adds value beyond the schema, though the schema already carries most of the parameter documentation.

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?

The description opens with a precise verb and resource: 'CENSUS of a Core collection: every asset grouped under it, with its current owner, straight from the chain's asset index.' It clearly distinguishes itself from sibling tools by stating it is the only tool that sees unlisted items, and it provides concrete example questions. This makes the tool's purpose unmistakable and differentiates it from collection-wide tools that read marketplace listing books.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool versus alternatives: it is the only tool that sees items nobody has listed, while other collection-wide tools read a marketplace's listing book. It also names a specific alternative, get_asset_provenance, for seeing who handed an item over when it is listed. This gives clear when-to-use and when-not-to-use guidance.

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