The server defines 2 search tools with identical schemas and reasonable descriptions. However, there are significant issues: (1) naming duplication, 'web_search' and 'search' are synonymous, forcing LLM reasoning overhead with no functional distinction; (2) descriptions are adequate but generic, missing actionable guidance on WHEN to use each tool or what differentiates them; (3) parameter documentation is present but minimal, no guidance on query length, language support, timeout behavior, or what 'engines' do if unresponsive; (4) output schema is not formally documented, the code returns formatted text rather than structured data, forcing LLM to parse plain-text results; (5) error handling returns only text messages with no recovery guidance; (6) no tool annotations (readOnlyHint present via Risk field, but not in MCP schema). Both tools are READ_ONLY (appropriate for search), but this is not declared in the tool definitions. The implementation is functional but lacks production-grade documentation and composition clarity.

• Remove the 'search' tool and keep only 'web_search' (or rename 'search' with a distinct name if intentional variants exist). Document the difference in descriptions if both are necessary.
• Return structured JSON output instead of formatted text: {results: [{title, description, url, engine, score?}], total_results, query, engines_used, unresponsive_engines}. This enables downstream tool composition and eliminates parsing ambiguity.
• Expand parameter descriptions: 'query' should state max length (e.g., ≤500 chars recommended) and any language constraints. Document that 'engines' array is optional and defaults to [google, brave, duckduckgo].
• Add output schema documentation in the tool definition. Either embed a JSON example or reference a type definition that shows expected fields (title, description, url, engine for each result).
• Implement actionable error messages. Instead of 'API request failed: 500', return 'Search API unavailable (HTTP 500). Check CF_SEARCH_URL is correct and accessible. Retry in 10s or try a different search engine.' This guides LLM recovery.
• Add toolAnnotations to the MCP server response. Mark both tools with readOnlyHint=true to explicitly declare search-only access.
• Document timeout behavior: if engines are slow to respond, does the tool timeout partial results or fail entirely? Current code has DEFAULT_TIMEOUT=3000ms but no documentation of what happens if exceeded.