Critical failures across all three tools. No input schemas visible in source code (pkg/exa/tools.go shows only tool names in DefaultTools array, no schema definitions). Descriptions are minimal (10-30 chars), far below the 50-200 char baseline for LLM-optimized tools. No parameter documentation, no output schema specification, no error handling guidance. Tools appear to be stub registrations without implementation details. This server cannot be used by agents without substantial schema and documentation work.

• Add complete JSON Schema definitions for each tool's input parameters. Include type, description, enum constraints, and min/max bounds. Example: {"type": "object", "properties": {"query": {"type": "string", "description": "Search query (1-500 chars)", "minLength": 1, "maxLength": 500}}, "required": ["query"]}
• Expand tool descriptions to 80-150 characters. Explain WHAT the tool does, WHEN to use it vs alternatives, and what it returns. Example: 'Search the web using Exa API. Returns up to 10 ranked results with title, URL, and snippet. Use for general queries; use web_search_advanced_exa for complex filters.'
• Document output schema with field names, types, and descriptions. Specify pagination (limit, offset, total_count) and whether results are ranked or filtered.
• Clarify the distinction between web_search_exa and web_search_advanced_exa. Add parameters to the advanced variant (e.g., filter_type, date_range, domain_filter) and document them explicitly.
• Add error handling guidance. Document what errors can occur (rate limit, invalid query, API key missing) and what the agent should do (retry, ask user, use fallback tool).