Single tool 'search' has a well-structured input schema with proper types, enums, and defaults. Description is adequate (194 chars) but lacks actionable guidance on when to use it vs alternatives or how to interpret results. Parameter descriptions are present but minimal. Output schema is not documented, LLMs cannot predict the response structure. No error handling guidance. Tool naming is clear and verb-based, but composition is limited (only 1 tool; TODO comment suggests incomplete implementation).

• Document the output schema explicitly. Define response structure: { results: [{ title: string, url: string, description: string, source: string }], total_count: number }. This lets LLMs plan downstream parsing.
• Expand tool description to 150-250 chars. Add: 'Use this to find web information when you need current data. Returns up to [limit] results with title, URL, snippet, and source. Supports multiple search engines for redundancy.'
• Add parameter guidance for 'engines': 'If multiple engines specified, results are merged and deduplicated by URL. If empty, uses server default engine from config.'
• Include error handling in description: 'Returns empty results if no matches found. May timeout if engines are slow; retry with fewer engines or simpler query.'
• Implement and document the planned fetchArticle tool to enable multi-step workflows (search → fetch full content).

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained