MCP server for web search with multi-engine support (Serper, SerpAPI, Brave, Exa) and optional secure credentials via VaultGuard
mcp-omniserp presents a functional search tool suite with clear naming conventions and consistent parameter schemas across all 12 tools. However, tool descriptions are uniformly brief (15-30 characters), falling well below the 194-char baseline for production tools. Parameter descriptions are present but generic, lacking actionable context about constraints, formats, or when to use each specialized search variant. Output schemas are not visible in the provided source code, only input schemas are documented. The tool set has good verb-noun naming (google_search*, webpage_scrape) and organized around single concerns, but lacks guidance on error recovery, pagination behavior, and the functional differences between overlapping search tools (e.g., google_search vs google_search_news). Security handling for API keys is well-designed (keyring/VaultGuard integration), but this is server-side and not reflected in tool parameters, which is correct.
Perform a Google web search
Get search suggestions using Google Autocomplete
Search for images using Google Images
Perform visual search using Google Lens
Search for locations using Google Maps
Search for news articles using Google News
Search for places using Google Places
Tool descriptions universally under 20 characters ('Perform a Google web search', 'Search for news articles using Google News'). Descriptions lack actionable context: when to choose google_search vs google_search_news? What does each return? What are pagination limits?
Parameter descriptions are minimal (e.g., 'The search query', 'Number of results to return'). No constraints documented: what is the min/max for numResults? What country/language codes are valid? What format should location take? LLMs cannot infer these and will hallucinate values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Search for reviews
Search for academic papers using Google Scholar
Search for products using Google Shopping
Search for videos using Google Videos
Scrape content from a webpage
Output schemas not documented in source code. No visibility into what fields are returned by each search variant, pagination structure, total counts, or next-cursor information. Agents cannot plan downstream calls without knowing response structure.
No error handling guidance. What happens if search fails? Rate-limited? Invalid country code? Timeout? No recovery hints provided. LLM cannot self-correct without actionable error messages.
Twelve similar search tools (google_search*) risk LLM confusion on selection. Descriptions do not clearly differentiate when to call google_search vs google_search_news vs google_search_scholar. No guidance on resource type (web pages, news articles, academic papers) or use-case boundaries.
Parameter 'country' and 'language' accept free-form strings with no enum or pattern constraint. Should specify valid ISO 3166-1 alpha-2 codes (e.g., 'US', 'GB') and ISO 639-1 language codes (e.g., 'en', 'fr'). LLMs will guess invalid values.
webpage_scrape tool accepts 'url' with no constraints. Should validate URL format, document timeout behavior, what happens for non-HTML content (PDF, image), blocked/paywalled sites, rate-limiting. No description of output structure (HTML, markdown, plaintext).