This server has significant definition quality gaps. Tool names are reasonably clear (verb_noun pattern), but descriptions lack depth and actionability. Most critically, NO tools have documented output schemas, LLMs cannot predict what fields to expect or chain tools together. Parameter descriptions are minimal (often 1-2 sentences). The 'FREE' vs 'PREMIUM' labeling in descriptions is informal and doesn't guide LLM behavior. Error handling is generic ('Error: {e.message}') with no recovery guidance. Tools 1-3 are read-only wrappers around public data with no actual API integration, making them low-value. Tools 4-5 require DEESEEK_API_KEY but don't validate its presence or provide clear error messages when missing.

• Add explicit output schemas to all tools. Document the structure, field names, types, and example values. E.g., search_public_profiles should return [{profile_name, headline, company, profile_url}].
• Replace instructional text responses with actual data. search_public_profiles should call a real API or scraper and return structured profile objects, not 'Copy this query into Google'.
• Expand tool descriptions to 100-200 characters. Include WHAT (what does it do?), WHEN (when should the LLM call it?), and WHAT IT RETURNS (what structure?). Example: 'Optimize a LinkedIn post for engagement using AI. Call this after draft_connection_request to refine messaging. Returns: {optimized_text, engagement_score, suggested_hashtags}'.
• Add explicit validation and error recovery for DEESEEK_API_KEY. Check for presence at tool call time and return: 'DEESEEK_API_KEY not configured. Set it in environment variables to use premium features.' This is retryable and actionable.
• Add min/max constraints to numeric parameters. E.g., count: {type: 'number', minimum: 1, maximum: 20, default: 10}. Validate in code and return: 'count must be 1-20, got {value}'.

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

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