Purple Flea Public Wallet is an HTTP-based MCP server with 16 tools. Overall definition quality is below average. Critical issues: (1) Tool names do NOT follow verb_noun convention, most are HTTP route paths (GET /v1/wallet/chains/gas/:chain) rather than action-oriented names like get_gas_price_by_chain. (2) Descriptions are present but many are extremely short (e.g., 'Health check endpoint with database and agent registration status' = 71 chars for /health, 'Ultra-lightweight uptime check returning pong' = 45 chars for /ping). (3) Input schemas ARE present and typed (string, number), but parameter descriptions are often generic or missing depth ('Chain name (ethereum, base, arbitrum, bsc)' for /chains/gas/:chain is acceptable but minimal). (4) Output schemas are NOT documented, the code returns JSON objects but the response structures are not formally specified in tool definitions. (5) Error handling is present at the HTTP level (global error handler in server.ts catches errors and returns JSON responses), but tool-level error guidance is minimal, no recovery hints like 'If X fails, try Y' are embedded in tool descriptions. (6) The 'GET /health' and 'GET /ping' tools are redundant utility endpoints that should not be exposed as primary tools. (7) Path-based parameter extraction (e.g., ':chain' in /v1/wallet/chains/gas/:chain) is not ideal for tool schemas, the parameter should be explicit in the input schema. (8) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, though risk levels ARE marked (READ_ONLY, WRITE, DESTRUCTIVE). (9) Several tools (token-info variants, alert-check) could be better composed, listing all tokens then filtering by symbol is less efficient than a direct lookup. (10) The /v1/public-stats endpoint returns basic counts but no pagination or filtering, acceptable for a small endpoint but the pattern is not generalizable.

• Rename tools to follow verb_noun convention: 'GET /v1/wallet/chains' → 'list_blockchain_chains', 'GET /v1/wallet/chains/gas/:chain' → 'get_gas_price_for_chain', 'GET /v1/alerts' → 'list_price_alerts', 'DELETE /v1/alerts/:id' → 'delete_price_alert', 'GET /v1/token-info/:symbol' → 'get_token_details', 'GET /v1/public-stats' → 'get_public_wallet_stats', etc. This enables LLMs to infer intent from the name alone.
• Document output schemas for every tool. Include field names, types, and brief descriptions. E.g., for GET /v1/wallet/chains, specify: {chains: [{id: string, name: string, symbol: string, decimals: number, isActive: boolean}], totalCount: number}. For GET /health, specify: {status: string, service: string, version: string, uptime_seconds: number, database: string, registered_agents: number, timestamp: string}.
• Expand tool descriptions to 50-200 characters and include WHEN to use the tool and any prerequisites. E.g., instead of 'Get current gas prices across EVM chains', write: 'Fetch real-time gas prices (in gwei) for Ethereum, Base, Arbitrum, and BSC. Use this before sending transactions to estimate fees. Call get_gas_price_for_chain(chain_name) for a specific chain.'
• Mark path parameters as 'required' in input schemas and add minimum/maximum string length constraints where applicable. E.g., for 'chain' parameter in get_gas_price_for_chain, specify: 'one of: ethereum, base, arbitrum, bsc (case-insensitive).'
• Add tool annotations to the MCP tool definitions: readOnlyHint: true for GET endpoints, destructiveHint: true for DELETE endpoints, idempotentHint: true for POST /v1/auth/register and GET queries (they are safe to retry).