This MCP server has critical definition quality gaps. While both tools are named with action verbs (wallet_socials, batch), the descriptions lack specificity for LLM decision-making. The wallet_socials tool description (53 chars) is borderline adequate but doesn't explain WHEN to use it vs batch, or what the output structure contains. The batch tool description (76 chars) is similarly vague about expected output format and pagination behavior. Most critically: NO input parameter descriptions are visible in the provided source code. The wallet_socials input shows 'address' parameter with type string and a brief hex format note, but lacks context (e.g., checksummed vs lowercase, what happens with invalid input). The batch tool's 'wallets' parameter has no description beyond the array declaration. Output schemas are completely undocumented, we cannot see what fields are returned by each tool. The WalletLookupTool.tsx component reveals the response structure includes fields like 'wallet', 'found', 'checked_at', 'data.twitter', 'data.farcaster', etc., but this is inferred from UI code, not explicit in tool definitions. No error handling guidance is documented. No pagination parameters despite batch operation. The server appears to be primarily a Next.js frontend with embedded MCP tools, not a proper MCP server with formal tool registration.

• Add explicit descriptions to every input parameter. For wallet_socials: 'address: EVM wallet address in checksummed hex format (0x...), 42 characters including 0x prefix. Will fail if lowercase or invalid checksum.' For batch: 'wallets: Array of EVM addresses. Max 100 per request. All addresses must be checksummed hex format.'
• Document output schemas formally. Example for wallet_socials: 'Returns {wallet: string (checksummed address), found: boolean, checked_at: ISO8601 timestamp or null, data: {twitter: {handle, url, verified, reachability}, farcaster: {username, url, fid, verified}, ens_name?: string, ...}}'.
• Expand tool descriptions to 100-150 characters and include selection guidance. E.g., wallet_socials: 'Look up social accounts for a single EVM wallet address. Returns Twitter/X and Farcaster handles if linked. Use batch() for bulk operations (10+).'
• Add pagination and result capping to batch. Specify max array size, document whether results are paginated or truncated, and return a total_checked count. E.g., 'Accepts up to 100 wallets. Returns all results in a single response; no pagination. Limit total response size by capping wallets array or implementing result streaming.'
• Document error cases explicitly. Example: 'If address is invalid (not 42-char hex or failed checksum), returns 400 with error: "Invalid address format". If rate-limited, returns 429 with Retry-After header. If no social accounts found, returns 200 with found: false.'
• Specify idempotency guarantees. Confirm that repeated calls with the same wallet return identical results. Document whether the tool caches or always hits upstream APIs.