Loading ToolBench
MCP server for Shape blockchain data - gasback analytics, NFT insights, network monitoring, etc.
The shape-mcp server exposes only ONE tool: 'curateNftsByThemes'. While the tool has a basic schema and description, it falls significantly short of production-grade quality. The description is generic and does not explain WHEN to use this tool, WHAT it returns, or any prerequisites. The input schema is present but lacks depth: parameters have descriptions but no explicit type validation, enums, or constraints. The tool name violates verb-first conventions (should be 'curate_nfts_by_themes' not 'curateNftsByThemes'). Most critically, there is NO documented output schema, no error handling guidance, no pagination support despite likely returning multiple NFTs, and no indication of idempotency or side effects. The codebase shows the tool is implemented in 'public-site/app/api/curate-nfts/route.ts', but that file is not included in the source sample, making it impossible to verify actual schema structure or error handling. Per the hard scoring rules, when tool definitions are inferred rather than directly visible, the tool scores at 50 max, but additional gaps push it lower.
Curate NFTs by themes with sentiment analysis and count
Tool name violates verb-first convention (curateNftsByThemes instead of curate_nfts_by_themes). LLMs parse intent from name prefixes, camelCase + no leading verb reduces discoverability.
Description is generic and incomplete (54 chars: 'Curate NFTs by themes with sentiment analysis and count'). Does not explain WHEN to call this vs other NFT tools, WHAT structure is returned, or any prerequisites. Baseline for good descriptions is 50-200 chars with clear purpose and context.
No output schema documented. LLMs cannot plan downstream operations or extract required fields (e.g., NFT IDs, metadata) without knowing the return structure. This forces guesswork and failed chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Input parameters lack type constraints and validation hints. 'sentiment' is a free-form string, no enum of valid values (positive, negative, neutral?). 'themes' is an array but no min/max length, no item type constraints. 'count' is a number but no min/max bounds (what prevents count=999999?).
Parameter descriptions are minimal and lack actionable detail. E.g., 'Sentiment filter for NFT curation' does not explain which sentiment values are valid or how sentiment affects results. 'Array of themes to filter NFTs' does not clarify format (strings? IDs? case-sensitive?).
No pagination support visible. If this tool returns multiple NFTs, there is no limit parameter or cursor/offset mechanism. Large result sets risk exceeding context windows and degrading LLM reasoning.
No error handling guidance. Does the tool fail gracefully if wallet is invalid? If no NFTs match the filters? If sentiment service is unavailable? LLM receives no recovery hints.
Tool definition not directly visible in source sample. The actual implementation in 'public-site/app/api/curate-nfts/route.ts' is not provided, forcing inference of schema and behavior. Per hard scoring rules, inferred tools cap at 50.
No idempotency, side-effect, or read-only hint declared. Tool has 'Risk: READ_ONLY' metadata, but this is not reflected in tool annotations (readOnlyHint) in the schema or description.