Single tool 'web_search' has a basic description and partial schema, but critical gaps prevent production use. Description is adequate (54 chars, within 10-1024 range) but lacks WHEN to use it and prerequisites. Input schema visible with 'query' (required, string) and 'num_results' (optional, integer, default 5), but NO output schema documented, LLMs cannot plan downstream calls. Parameters lack detailed format/constraint descriptions (e.g., what constitutes a valid query? max length?). Tool implementation is a placeholder returning mock results, not functional. No error handling guidance, no recovery paths. No tool annotations (readOnlyHint, etc.). Naming 'web_search' is acceptable (verb_noun) but generic.

• Document the output schema explicitly. E.g., 'Returns {results: [{title: string, snippet: string, url: string, position: integer}], total_results: integer, search_time_ms: integer}'. This enables LLMs to extract and chain results.
• Add constraint descriptions to parameters: 'query (string, 1-500 chars): The search query. Supports boolean operators (AND, OR, NOT) and quoted phrases.' and 'num_results (integer, 1-100, default 5): Maximum results to return.'
• Implement actual web search logic using a real API (Google Custom Search, Bing, DuckDuckGo). Replace the placeholder mock results with live data.
• Add error handling guidance to the tool description: 'Returns error if query is empty, too long, or contains invalid characters. If API rate limit is hit, retry after 60 seconds.'
• Add tool annotations in the schema: set readOnlyHint=true to signal this tool has no side effects and is safe to retry.

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

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