37 tools with minimal quality. All tools lack parameter descriptions in the schema (critical violation). Most descriptions are under 20 chars, failing the baseline. No output schemas documented. No error handling guidance. Tool names are verb-prefixed but descriptions are too terse to guide LLM selection. Example: 'Follow a user by their Farcaster ID' (34 chars) lacks context on when to use vs alternatives. Parameters like 'fid' and 'cast_hash' have no type info in schema definitions visible in code. No distinction between read-only and write operations in descriptions. Async tools (get_channel, etc.) mix direct client calls with httpx, creating inconsistent patterns.

• Add parameter descriptions to all @mcp.tool() decorators. Use FastMCP's InputModel or explicit docstrings to document each parameter's purpose, type, constraints, and format. Example: 'fid (integer, 1-999999): Farcaster ID of the user to follow. Required.'
• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. Example: 'Follow a user on Farcaster. Use this to add a user to your following list. Requires authentication. Returns success status and updated follower count.'
• Document output schemas for all tools. Specify which fields are returned, their types, and which are safe to pass to downstream tools. Example: 'Returns {user_id: int, username: str, follower_count: int, following_count: int}'.
• Add error handling with recovery guidance. Catch exceptions and return structured errors like '{error: "User not found", suggestion: "Try search_users() with a partial name", retryable: false}'.
• Implement confirmation for destructive operations. Add a 'confirm' parameter to delete_cast, delete_cast_likes, and delete_recast. Or wrap them in a separate confirm_delete_cast(cast_hash) tool that returns a confirmation token.