io.github.p1xelapp/solana-nft-mcp

Plain-words explanation of how a standard or a marketplace actually handles an asset: why an NFT moved to an unknown wallet (escrow), whether a project can take it back (permanent delegates), why it cannot be listed (freeze), who gets paid on a sale and where royalties are enforced, why two sites show different floors, what a wash trade looks like, what changes in a standards migration. Covers Metaplex Core plugins, Token Metadata and programmable NFTs, compressed NFTs, and the Solana marketplaces (Magic Eden order book and pools, Tensor, OpenSea, Candy Digital, Collector Crypt). Every entry cites the documentation or program source it came from and says when observed behaviour differs from what is documented. Answers 'what does frozen mean', 'can they burn my card', 'is Magic Eden custodial'.

Search MANY collections at once for a specific edition number. DC comics on Candy are 272 separate collections, one per issue, so 'is any DC #1 or #100 listed, and how close to floor' cannot be asked of one collection - this asks a batch of them and hands back a cursor for the rest. Answers 'any #1 for sale across DC', 'cheapest low serial in the MLB set', 'which issues have a #100 listed under 1 SOL'. Each match names its collection, its ask, that collection's floor and how far above floor it is. Use groups from search_collections, or name the collections yourself.

What is for sale in a collection right now, cheapest first, with optional trait filters, a name filter, and a lowest-serials mode that reads the whole book and sorts by edition number. Answers 'cheapest Rex', 'find #1390', 'is a #1 or #100 for sale', 'lowest serial I can buy and what it costs versus floor', 'is there a deal on a Judge card', 'what is listed under 1 SOL', 'which traits are cheap right now'. Several trait filters mean all of them. Rarity ranks appear when the marketplace publishes them (Core collections usually carry none). Prices are asks on Magic Eden, not what buyers pay; get_collection_sales shows that.

Everything known about one asset by mint address: marketplace metadata (name, image, collection, traits, listing state) plus the on-chain owner read from the Core account for Metaplex Core assets, and the chain's asset index for every other standard. Each reader's freshness is reported; the two owners are only called agreeing when both were read live.

BOUNDED on-chain ownership history of a Metaplex Core asset: mint -> transfers (with marketplace labels) -> current owner. Decoded from TransferV1 instruction accounts - data most NFT APIs return EMPTY for on Core assets. Ideal for Candy Digital cards and any Core collectible. This decodes at most `depth` transactions, so on a heavily traded asset the earliest ownership can be outside the result: ALWAYS read `historyComplete` before describing the trail as the whole story, and `skippedTransactions` for how much was left out. Raise `depth` to cover more. A bounded walk keeps the newest transactions and the mint and drops the middle, which is where a recently minted asset's sale usually sits: any hole appears in `events` as an `unread_gap` row IN ITS PLACE in the order, so never read across one as though the trail were continuous. Lowering `depth` to save time is how a 'who bought it' question gets the wrong answer. Ownership events only: traits live in get_asset (marketplace attributes) and get_asset_trust (the on-chain Attributes plugin), so an empty trait picture here means nothing.

Decode the Metaplex Core plugins on an asset and translate them into custody facts: can the issuer move or burn it without the holder's signature (permanent delegates - normal on packs, a red flag on keepers), is it frozen, are royalties enforced by a program rule set or merely advisory, is the metadata mutable, is the serial an on-chain edition or just printed text. Plugins set on the COLLECTION apply to every asset in it and are read too, marked inherited. Marketplaces show the picture and the price; this shows the rules attached to the account. Use before a purchase, when a listing 'cannot transfer', or when someone asks whether a pack burns on open. Read-only, decoded from raw bytes, no indexer.

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.

Sales for a collection over the last N days, as Magic Eden recorded them, with every sale named by the chain's asset index so it can be filtered and grouped by player, character or issue: how many sold, total volume, highest and lowest sale, median and average, unique buyers and sellers, the biggest buyers, a per-day series for charts, a per-name breakdown, and the split between the order book and Magic Eden's AMM pools. Answers 'how many sales this week', 'how many Ohtani cards sold', 'which player sold the most', 'what was the top sale', 'is volume up', 'chart the last month', 'who is buying'. The result says how far back the feed was read and whether older sales exist beyond the page budget; it never fills a gap with an estimate. Magic Eden's API feed only: each row carries the execution marketplace that feed reported, and fills it did not index are not here.

Market + supply stats for a collection. Accepts a registry id, a Magic Eden symbol, or a Metaplex Core collection ADDRESS. Addresses are decoded straight from the chain (name, minted, current size) - works for collections no marketplace indexes, e.g. Candy Digital drops. If OPENSEA_API_KEY is set, an OpenSea cross-marketplace view is added (pass openseaSlug, or rely on registry entries that carry one): OpenSea's floor, supply and royalty, plus its 7-day floor trend and the largest holders with their share of supply. Answers 'is the floor up or down this week', 'who holds the most', 'is one wallet holding half of it'.

Current floor price in SOL for up to 10 collections, read from MAGIC EDEN ONLY - it takes Magic Eden symbols and returns Magic Eden rows, with no other marketplace and no other currency, whether or not an OpenSea key is configured. For a cross-marketplace floor comparison use get_collection_stats, which quotes each marketplace in its own currency and refuses to compare across them. Use search_collections first if you only know a human name.

Use when the user wants to BUILD something with collectible data - a sales bot, a floor dashboard, a provenance page, a wallet tracker, a pack-pull watcher - rather than just look a number up. Returns the verified endpoints and their real rate limits, a runnable skeleton, the steady-state running cost, a pre-launch checklist, and the specific ways this kind of integration fails SILENTLY. The pitfalls come from production incidents on live trackers (a feed capped too low silently dropped 8,409 real records; an idle two-minute cron cost $180 in a month) and are not in any API documentation. Read this BEFORE writing integration code, not after it breaks.

Most recent completed sales for a collection (price in SOL, buyer, seller, tx signature). Accepts a registry id or Magic Eden symbol. With OPENSEA_API_KEY set and an openseaSlug, OpenSea sales are included for a cross-marketplace picture.

Live health of every data source this server reads, with tier, what each answers, what it cannot see, which need a key, and the fallback order. Answers 'is Magic Eden down', 'why is a number missing', 'what does this tool read', 'which sources need a key'. Use it when a result came back partial.

The wallets with the most volume in a collection as Magic Eden counts it (its own fills, all time). Answers 'who are the whales', 'biggest buyers', 'is one wallet moving this market'. Volume on other marketplaces is invisible here, and a high-volume wallet can be a market maker or a wash trader; get_wallet_activity on a wallet shows which.

Magic Eden's own trending collections for a time range. Answers 'what is hot', 'top collections today', 'what is moving this week'. The marketplace has been observed to answer with an empty list; when that happens the result says so rather than implying the market is quiet. Ranking is the marketplace's, by its own volume.

How a wallet trades: buys and sells with SOL totals, net flow, listings and bids, which marketplace (Magic Eden order book vs AMM pools; OpenSea with a key), the collections it trades most, every flip (bought then sold: hold time and P&L before fees), a behaviour label (flipper / holder / mixed / lister / quiet) with the reason, and the first purchase inside the window. With OPENSEA_API_KEY set, plain transfers are included so 'was this airdropped, gifted or bought?' gets an evidence-based answer. Every figure says which feed it came from and what that feed cannot see. Read-only; needs no key.

Collectibles held by a wallet, from two independent readers: Magic Eden's index (names, collections, images, listing state) and the chain's own asset index (every standard, including compressed and unlisted items a marketplace may not carry). Answers 'what does this wallet hold', 'what is in my wallet', 'does this address own anything'. The two counts are compared and any gap is named. Read-only - this server never asks for keys and cannot move anything.

What a wallet holds and what that means: items grouped by collection with counts and share of the wallet, which collection dominates, how many are listed or compressed, the creator royalty each collection asks for, share of total supply where a supply is known, a floor-times-count CEILING (never called a value) for the largest holdings, and the wallet's age and transaction count from the chain. Answers 'what do they collect', 'how much of X do they own', 'how big a holder are they', 'is this a fresh wallet', 'what is it worth at floor' - with each number labelled for what it is. Read-only; needs no key.

START HERE when you do not already know what an identifier is. Takes ANY string a user might paste - a Solana address, a marketplace symbol or slug, or a plain collection name - works out what it actually is, which marketplaces list it, and which tools to call next. Works on collections that launched today and are in no registry, because it probes live sources rather than matching a hardcoded list. Returns the evidence: every source checked INCLUDING the ones that found nothing, what was not checked and why, and a confidence rating. Never report 'this does not exist' from an empty result - report what was searched.

Find digital-collectible collections by name (e.g. 'candy gold series', 'batman', 'mad lads'). Returns curated entries with the identifiers other tools need (Magic Eden symbol, Core collection address). Collections not in the registry still work: pass a Magic Eden symbol or a Metaplex Core collection address directly to the other tools.

Check whether something a user was TOLD is actually true. Use this whenever a claim about a collection or asset carries stakes - a project announcing a supply, a seller saying a card has never been traded, a post claiming a wallet holds something, a quoted floor price. Returns confirmed, contradicted, or unverifiable, together with the exact numbers observed, where they were read, and instructions to reproduce the check independently - so the answer does not require trusting this server either. Willingly answers UNVERIFIABLE rather than guessing; a tool that always returns true or false will eventually return false with confidence.