A meta search engine that aggregates results from multiple search providers through an MCP server interface
seargo has a single, well-defined search tool with clear input parameters and an enum-constrained provider field. The tool name 'search' is generic but acceptable for a single-purpose server. The description is adequate (92 chars, within baseline). Input schema is properly structured with JSON Schema types and parameter descriptions. However, output schema is not documented, the tool returns JSON-marshaled search results but the response structure (SearchResult fields: title, url, description, icon) is never formally specified in tool metadata. Error handling is minimal, the tool logs errors but returns an empty array rather than actionable error guidance. The server lacks output documentation, and descriptions could be more specific about result format and limitations.
Performs a search query across multiple providers.
Output schema not documented. Tool returns JSON-marshaled SearchResult objects, but the response structure (fields: title, url, description, icon) is never declared in the tool metadata. LLMs cannot plan downstream processing or field extraction without knowing the response shape.
Error handling lacks recovery guidance. When a search fails or no provider is enabled, the tool returns an empty array silently rather than returning actionable error messages that tell the LLM what went wrong and what to do next (e.g., 'No enabled providers configured, contact admin to enable at least one provider').
Tool name 'search' is overly generic. While acceptable for a single-tool server, more specificity ('web_search' or 'search_web') would clarify intent and help LLMs distinguish this from other search tools in multi-tool environments.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Description does not mention result limits or pagination. The tool description states it 'Performs a search query across multiple providers' but does not clarify how many results are returned, whether pagination is available, or if results are capped. LLMs need this context to plan for large queries.
Provider parameter description includes example values ('e.g. duckduckgo, brave, bing') which LLMs may treat as exhaustive. The enum constraint is present, but the description should not repeat example values, let the enum speak.