Loading ToolBench
Solana NFT MCP Server for AI agents to interact with Solana NFT ecosystem
This HTTP-based server exposes 7 tools with inconsistent definition quality. Tool names follow verb_noun convention, but parameter schemas are partially visible and descriptions lack LLM-optimization detail. The server is NOT an MCP server, it is a custom REST API that mimics MCP tool semantics. Critical issues: (1) No MCP protocol implementation, this is plain Express.js serving REST endpoints, not MCP. (2) Tool definitions are scattered across route files and example files; no centralized, machine-readable tool registry. (3) Parameter descriptions in examples (chatgpt-function-call.js) show minimal detail ('The collection symbol, e.g. madlads'). (4) No documented output schemas, tools return API responses without documented structure. (5) No error recovery guidance. (6) Secrets (Helius API Key, Magic Eden API Key) are injected via env vars (good), but no per-tool permission scopes declared. Six tools are READ_ONLY; delist_nft and ai_query are WRITE but lack idempotency markers or confirmation patterns.
Process a natural language query for NFT operations
Delist an NFT from sale
Gets statistics for an NFT collection on Solana
Gets floor price of an NFT collection on Solana
Gets metadata for a specific NFT
Get trending NFT collections on Solana
Gets all NFTs in a Solana wallet
NOT AN MCP SERVER. This is a custom HTTP REST API, not an MCP (Model Context Protocol) server. It does not implement the MCP spec, has no tool registration via MCP, and cannot be used with standard MCP clients or hosting services. The repository claims to be an 'MCP Server' but the implementation is a plain Express.js app serving REST endpoints.
No documented output schemas for any tool. Tools return JSON responses but the structure (fields, types, nested objects) is not documented. LLMs cannot plan downstream operations without knowing what fields to expect.
Tool definitions are split across route files (src/routes/*.ts) and example files (examples/*.js). No centralized tool registry or machine-readable manifest. Tool schemas are inferred from route handlers, not explicitly declared.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Descriptions lack LLM-optimization depth. Example: 'Gets floor price of an NFT collection on Solana' (58 chars) does not explain when to call it vs get_collection_stats, what fields it returns, or expected format. Baseline is 194 chars with context on use case and dependencies.
ai_query is vaguely named and described. 'Process a natural language query for NFT operations' (52 chars) does not clarify: is this a general LLM relay? Does it make autonomous decisions? What are the guardrails? This violates the principle that tool names should unambiguously convey what happens when called.
Destructive/write tools (delist_nft, ai_query) lack confirmation patterns or dry-run support. No indication that these are irreversible. No error recovery guidance (e.g., 'If delisting fails, check if NFT is escrowed').
No input validation rules documented in parameter descriptions. Example: wallet_address parameter has no format hint (Solana addresses are base58, 32-88 chars). collectionSymbol has no enum or allowed values list. LLMs will guess valid formats.
No pagination documented for list results. get_trending_collections accepts limit (default 20) and offset (default 0), but no documentation of total count, next_cursor, or whether results are exhaustible. get_wallet_nfts does not document pagination behavior.
No per-tool permission scopes or role requirements declared. delist_nft and ai_query require Magic Eden API key (only needed for listing/delisting), but this is not exposed as a permission gate or scope declaration in the tool definition.
Example shows sample collection symbol 'madlads' in parameter description. This trains LLMs to reuse the example literally rather than adapt to the actual context.