Single tool with adequate naming but insufficient parameter descriptions. The deep_search tool has a clear verb-based name and a functional schema, but parameter descriptions lack depth and guidance. The 'effort' enum parameter description is minimal ('Search effort'), and the tool description, while present, lacks context about when to use it, what prerequisites exist, or what the output structure contains. No output schema is documented. Error handling is not visible in the provided source. The server shows basic competence but falls short of production standards.

• Document the output schema explicitly: 'Returns: {answer: str, sources: List[{title: str, url: str, snippet: str}]}'. This lets LLMs plan follow-up calls and extract references reliably.
• Expand the 'effort' parameter description to explain the tradeoff: 'low: 1 search query, 1 research loop, uses gemini-2.5-flash (fast, cheap). medium: 3 queries, 2 loops, flash (balanced). high: 5 queries, 3 loops, uses gemini-2.5-pro (thorough, slower, more expensive).'
• Add context to the tool description: 'Use for complex research questions requiring multiple search iterations and synthesis. Prerequisites: GOOGLE_API_KEY set. Estimated latency: low=5-15s, medium=15-45s, high=45-120s. Retry transient failures (rate limits, timeouts); fatal errors include invalid API key, quota exceeded.'
• Add error handling guidance to the description: 'Returns error with actionable message on failure (invalid query syntax, network timeout, API quota exceeded). Retryable errors include timeout and rate_limit; non-retryable errors include auth_failed and invalid_query.'
• Implement and document rate-limiting: add a note like 'Max 10 concurrent requests per agent instance to respect API quotas. Requests exceeding rate limit will return HTTP 429 with retry-after header.'
• Consider adding a 'sources_only' boolean parameter (default: false) for cases where the agent needs citations but not full answers, reducing latency and cost.