Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output structure. web_search has 4 parameters with types and descriptions, calculator has 1 parameter. Both descriptions are present but brief (under 100 chars). No output schemas documented. No error handling guidance. Parameter descriptions lack format constraints and validation rules. No tool annotations (readOnlyHint, idempotentHint). Naming is acceptable (verb_noun pattern), but descriptions do not explain WHEN to use each tool or what downstream tools expect.

• Add output schema documentation to both tools. For web_search, document: {results: [{title: string, url: string, snippet: string, source: string}], total_count: integer}. For calculator, document: {value: number | string, error?: string}.
• Expand tool descriptions to 150-250 characters. Example for web_search: 'Search the web using DuckDuckGo. Returns ranked results with titles, URLs, and snippets. Use when you need current information, recent news, or facts not in your training data. Supports time-based filtering via recency_days.'
• Add format constraints to parameter descriptions. For 'query': 'A search phrase (1-500 characters, supports AND/OR/NOT operators). Avoid special characters except quotes for exact phrases.' For 'expression': 'A numeric expression using +, -, *, /, **, %, and functions like sin, cos, sqrt. Supports pi and e constants.'
• Implement structured error responses. Instead of returning empty string on failure, return {error: string, suggestion: string}. Example: {error: 'No results found', suggestion: 'Try a simpler query or check spelling'}.
• Add tool annotations to FastMCP decorator. Use @server.tool(name='web_search', readOnlyHint=True, idempotentHint=True) to signal to LLMs that these tools are safe to retry and do not modify state.