Server has 6 tools with mixed quality. Tool names follow verb_noun pattern (gemini_get_*, gemini_reset, gemini_doctor), which is good. However, descriptions are inconsistent: some are very brief (e.g., 'Reset client' = 11 chars, below 20-char threshold), and several lack actionable context for LLM selection. Input schemas are present for all tools with proper type definitions and enums, but descriptions for parameters are minimal or missing context. Output schemas are not documented. Error handling is present via domain_error_boundary but recovery guidance is limited. Tool annotations (READ_ONLY_LOCAL, MUTATES_LOCAL) are correctly applied, which is a positive signal for current spec alignment.

• Expand gemini_reset description to 50-100 chars: 'Reset the Gemini client session, clearing cached state and authentication. Use this if the client becomes unresponsive or after credential changes.'
• Add explicit output schema documentation to all tools. E.g., 'Returns: {status: string, has_cookie: boolean, needs_refresh: boolean, source: string}' in gemini_get_cookie_status.
• Enhance parameter descriptions with constraints and context. E.g., 'browser (string, default=chrome): Browser type to extract cookies from. Valid: chrome, firefox, safari, edge. Chrome is most commonly used for Gemini Web UI.'
• Implement error classification in responses: include 'error_type' field (retryable|user_fixable|fatal) and 'recovery_hint' with actionable next steps. E.g., 'error_type: user_fixable, recovery_hint: Run gemini_doctor to diagnose cookie issues.'
• Document when to use each cookie-related tool. Add a discovery note to gemini_get_cookie_status: 'Use this first to check if cookies are available. If not, call gemini_list_browser_cookie_profiles to see available profiles, then gemini_get_cookie_from_browser to load them.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry