Loading ToolBench
Complete pre-blockchain NFT preparation workflow including AI image generation, IPFS storage, and metadata creation
The server defines 4 tools with explicit schemas and descriptions visible in src/index.ts. Tool naming follows verb_noun convention (generate_image, upload_to_ipfs, create_metadata, build_complete), which is good. However, descriptions are terse (10-20 words each, well below the 50-200 char LLM-optimized baseline), and critical parameter documentation is sparse. The build_complete tool conflates multiple operations (image generation + IPFS upload + metadata creation), violating single-responsibility. Input schemas are present for all tools but parameter descriptions are minimal or missing. Output schemas are not documented at all, forcing LLMs to guess what fields are returned. Error handling, validation guidance, and recovery instructions are absent from the tool definitions.
Complete NFT preparation pipeline: generate/upload image, create metadata, upload to IPFS. Full workflow solution.
Create NFT metadata JSON and upload to IPFS
Generate AI image for NFT using free APIs (Pollinations.ai, FLUX.1, Stable Diffusion)
Upload image to IPFS using Pinata, NFT.Storage, or Web3.Storage
Tool descriptions are too brief (10-20 words). LLM-optimized descriptions should be 50-200 characters and answer WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'Generate AI image for NFT' lacks context for LLM selection vs other image tools.
nft_pipeline_build_complete combines image generation, IPFS upload, and metadata creation, three distinct operations. This violates single-responsibility (pattern:tool). Split into separate tools so agents can compose them independently: generate_image → upload_to_ipfs → create_metadata.
No output schemas documented for any tool. LLMs cannot plan multi-step workflows without knowing what fields are returned. Example: does upload_to_ipfs return {hash, url, gateway_url}? Document this so agents can chain tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Parameters lack descriptive context. The 'service' parameter (pinata, nftStorage, web3Storage) has no description explaining how to choose between them, whether API keys are required, or expected response times. Parameter descriptions should be 50+ chars and include constraints.
Mutual exclusivity is undocumented. In nft_pipeline_upload_to_ipfs, both 'imageUrl' and 'imagePath' are present with no note that exactly one should be provided. LLMs will pass both, causing ambiguous behavior.
API keys exposed as parameters. The 'apiKey' and 'ipfsApiKey' parameters should never appear in tool definitions, agents log all parameters, leaking credentials into traces. Use server-side secret injection via environment variables instead.
No error handling guidance. Tool definitions include no hints for recovery, retryability, or actionable error messages. Example: if image generation fails, should the agent retry? Fallback to a different model? Call a different tool?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). These help LLMs reason about side effects and retry safety. nft_pipeline_upload_to_ipfs and create_metadata perform writes and should be marked destructiveHint=true.