xhs-mcp has well-structured schemas and clear descriptions for all 5 tools. Tool names follow verb_noun convention (xhs_search, xhs_detail, xhs_creator, xhs_login, xhs_status). All tools have descriptions (194 - 250 chars, within baseline 34 - 392 range). Input schemas are complete with types and enums. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling is minimal; no recovery guidance or actionable error messages visible. The xhs_login tool accepts sensitive parameters (cookie_str) which violates secret-injection pattern. Missing per-parameter descriptions in some cases (e.g., xhs_status has empty properties object). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications.

• Document output schemas for all tools. For xhs_search, specify: {notes: [{note_id, title, stats, xsec_token, ...}], total_count, next_page}. For xhs_detail: {notes: [{note_id, content, images, comments, ...}]}. For xhs_creator: {users: [{user_id, profile_info, recent_notes, ...}]}.
• Move cookie_str to server-side secret injection. Accept only action parameter; load cookies from environment or secure vault. Remove cookie_str from inputSchema entirely.
• Add tool annotations: xhs_search/xhs_detail/xhs_creator get readOnlyHint=true; xhs_login gets destructiveHint=true (modifies auth state); xhs_status gets readOnlyHint=true.
• Populate xhs_status inputSchema with at least one parameter (e.g., 'include_cache_stats': boolean) or document why it accepts no input. Add description: 'Check server health: browser connection, cookie validity, cache size, last request time.'
• Add error recovery hints to descriptions. E.g., xhs_login: 'If QR code scan fails, try action=from_browser to extract from installed Chrome/Edge. If cookies expire, call xhs_login action=check to verify state.'

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

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