Skip to main content
Glama
Nomad07

nftdata-mcp

by Nomad07
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

nftdata-mcp

An MCP server that exposes the NFT Data API to AI clients (Claude Desktop, Cursor, etc.) as a single tool. It handles the x402 payment flow automatically.

Tool

get_collection_data

Returns OpenSea collection market data in one call.

Parameter

Type

Description

collection

string

OpenSea collection slug, from opensea.io/collection/<slug> (e.g. azuki)

Returned fields: name, slug, contracts, floor_price, floor_price_currency, one_day_sales, one_day_volume, seven_day_sales, seven_day_volume, thirty_day_sales, thirty_day_volume, total_sales, total_volume, num_owners, total_supply, created_date. Volume and price currencies are given in the matching *_currency fields (ETH, USDC, HYPE, ...).

Each call costs $0.002 (USDC on Base, paid via x402).

Related MCP server: nft-floor

Requirements

  • Node.js 20+

  • A wallet private key funded with a small amount of USDC on Base

Use a dedicated wallet with only a small balance. Never use your main wallet.

Quick start (npx)

No cloning required. Add to claude_desktop_config.json:

{
  "mcpServers": {
    "nftdata": {
      "command": "npx",
      "args": ["-y", "nftdata-mcp"],
      "env": {
        "EVM_PRIVATE_KEY": "0x..."
      }
    }
  }
}

Restart Claude Desktop, then ask for example: "What is the floor price and 7-day volume of azuki?"

If the package is published under a scope, use that name instead (e.g. @your-scope/nftdata-mcp).

Run from source

npm install
EVM_PRIVATE_KEY=0x... npm start

To use a local checkout with Claude Desktop, point args to ["tsx", "/absolute/path/to/nftdata-mcp/server.ts"] with "command": "npx".

Build

npm run build   # compiles server.ts to dist/server.js

Configuration

Variable

Required

Default

Description

EVM_PRIVATE_KEY

yes

–

Private key of the wallet that pays for calls

NFTDATA_MAX_REQUESTS

no

100

Max paid requests per session

NFTDATA_URL

no

https://www.nftdata.app/api/get-collection-data

Override the API endpoint

Behavior

  • Sends POST /api/get-collection-data with body {"collection": "<slug>"}.

  • On 402 Payment Required, signs an x402 payment (Base, USDC) and retries.

  • Caches responses for 5 minutes per slug to avoid paying twice.

  • Stops after NFTDATA_MAX_REQUESTS paid calls per session.

  • Returns clear errors for 400 (invalid slug), 404 (collection not found) and 429 (rate limit, with Retry-After).

Limitations

  • Only x402 on Base is supported. Solana and MPP payment methods are not implemented in this wrapper.

  • The x402 client libraries change quickly; if imports fail, check the current x402 docs.

API reference

Available Tools

1 tool
get_collection_dataA

Get OpenSea NFT collection market data in one call: name, contracts, floor price, 1/7/30-day and lifetime sales and volume, unique owners, total supply, creation date. Costs $0.002 per call (x402). collection is the OpenSea slug from the collection URL: opensea.io/collection/ (e.g. 'azuki', 'basedpunks'). Prices are in the currency given in the *_currency fields (ETH, USDC, HYPE...).

NameRequiredDescriptionDefault
collectionYesOpenSea collection slug, e.g. 'azuki'

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the per-call price and payment mechanism (x402), the fact that currency varies per field (*_currency fields may be ETH, USDC, HYPE), and the full set of returned data. It does not cover freshness (real-time vs cached), rate limits, or failure behavior for an invalid slug, which keeps it out of the top band.

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

Conciseness5/5

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

Front-loaded with the purpose, then cost, then parameter format, then a currency caveat — each sentence carries distinct information and none repeats the schema or annotations. The field enumeration is long but justified because there is no output schema.

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?

For a one-parameter read tool with no annotations and no output schema, the description covers returns, cost, parameter derivation, and price-currency semantics, which is nearly everything an agent needs. Only data freshness and error behavior on a bad slug are left unstated.

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 coverage is 100% so the baseline is 3; the description earns above baseline by explaining how to derive the value ('the OpenSea slug from the collection URL: opensea.io/collection/<slug>') and adding a second example beyond the schema's 'azuki', which is operational knowledge the schema does not supply.

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 ('Get OpenSea NFT collection market data') and then enumerates the exact payload (floor price, 1/7/30-day and lifetime sales/volume, unique owners, supply, creation date), so an agent knows precisely what it receives. No siblings exist to disambiguate against, and none is needed.

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?

The description makes the call context clear ('in one call', market-data snapshot for a given collection) and discloses the $0.002 x402 cost, which is a real usage consideration for an agent deciding whether to call. It stops short of stating when not to use it or naming an alternative, but with no sibling tools that omission costs little.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedget_collection_data
Deploy Server
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

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

With a single tool there is no possibility of misselection; the tool targets one clear resource (an OpenSea collection by slug) and one action (fetch aggregated market data).

Naming Consistency4/5

The name follows a clean verb_noun convention (get_collection_data), which is readable and predictable. With only one tool there is no broader pattern to reinforce, so it falls just short of exemplary.

Tool Count2/5

A single tool is a very thin surface for a server named 'nftdata'; agents will hit dead ends whenever they need anything beyond one collection's aggregate snapshot. The domain implies multiple query types but only one is exposed.

Completeness2/5

The tool covers one snapshot of one collection but there is no way to discover or list collections, search by name, compare collections, or retrieve historical/time-series trends. This is a significant gap for anything resembling an NFT data server.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • santyvv-data-mcp

    santyvv1993
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to fetch crypto market and on-chain data, including prices across venues, token facts, OHLC candles, market overview, DeFi TVL, and wallet balances, with two free tools and the rest paid per call in USDC on Base via x402.
    8
    18 npm
    MIT