hyde MCP demonstrates solid fundamentals: all 5 tools have clear action-verb names (discover_, get_, quote_, build_), substantive descriptions (100-200 chars), and complete Zod schemas with typed parameters. Descriptions explain WHAT each tool does and WHEN to use it (e.g., 'Use before buying a fresh coin' for get_signal). All parameters are typed and described. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling is minimal (generic JSON parse fallback). No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. Missing pagination guidance for discover_coins despite potentially large result sets.

• Document output schemas for all tools. Example: 'Returns { coins: [{address, price, marketCap, category, age, reflection_stock}], total: number, nextCursor?: string }'. This enables LLM planning and chaining.
• Add tool annotations via MCP SDK. Mark discover_coins, get_coin, get_signal, quote_trade with readOnlyHint: true. Mark build_trade with destructiveHint: true and idempotentHint: false (unsigned tx, not idempotent if broadcast multiple times).
• Add pagination to discover_coins: default limit=20, document that results are newest-first, return total count and next_cursor for large result sets.
• Enhance error handling in api() function. Return structured errors: { error: string, code: string, recovery: string }. Example: { error: 'Invalid token address', code: 'INVALID_ADDRESS', recovery: 'Token address must start with 0x and be 40 hex chars' }.
• Clarify build_trade response structure in description and document approvals parameter behavior. Example: 'Returns { tx: {to, data, value, chainId}, minOut: string, approvals: [{token, spender, amount}] }. Send approvals to token.approve() before broadcasting tx.'