google-search-mcp-server MCP server
This server has two search-oriented tools with clear naming and basic schema support, but significant gaps in parameter descriptions, output documentation, and error recovery guidance. Both tools follow the verb_noun pattern (google_search, read_webpage) and have brief descriptions, but descriptions are below the 50-200 char LLM-optimized range. Parameter descriptions exist but lack detail on constraints and formats. Output schemas are not documented, the code returns JSON-stringified content but LLMs cannot see what fields to expect. Error handling is present (axios error checks) but responses do not guide recovery or categorize errors as retryable vs. fatal. Security is reasonably sound (no secrets in params, API keys injected via environment), but tool annotations for read-only operations are missing.
Perform a web search query
Fetch and extract text content from a webpage
Output schemas are not documented. Both tools return JSON-stringified content without declaring the structure of the returned object. LLMs cannot plan downstream calls or extract specific fields (e.g., 'link' from search results) without seeing the schema.
Parameter descriptions lack actionable constraints. The 'num' parameter in google_search states 'Number of results (1-10)' but does not explain what happens if you request 0 or 11 (validation happens silently via Zod schema). The 'url' parameter in read_webpage has minimal guidance on what URL formats are accepted or what happens on malformed input.
Tool descriptions are too brief (23-41 characters). 'Perform a web search query' and 'Fetch and extract text content from a webpage' lack context on when to use each tool vs. alternatives, what the results are good for, and whether they have latency/quota implications. LLM-optimized descriptions should be 50-200 characters.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Error handling does not guide recovery. When search fails, the tool returns 'Search API error: <message>' but does not tell the LLM whether to retry, adjust the query, or give up. When webpage fetch fails, the tool returns 'Webpage fetch error: <message>' without categorizing it as a network timeout (retryable) vs. 404 (terminal). LLMs need explicit recovery hints.
Tool annotations are missing. Both tools are read-only operations, but neither declares the readOnlyHint in the tool definition. This prevents clients from optimizing caching, audit logging, or agent planning around the fact that these operations have no side effects.
No pagination support in google_search. The tool accepts 'num' (1-10) but does not support offset/page for retrieving results 11-20, 21-30, etc. If an agent needs comprehensive search results, it must repeatedly call with num=10 without a way to iterate through pages. The API supports 'start' parameter but the tool does not expose it.