Single tool 'search' has a reasonable description (104 chars, within 10-1024 range) and input schema with three parameters. However, critical gaps undermine quality: parameter descriptions are present but lack actionable constraints (no enums for provider types, no format specs for query); output schema is completely undocumented (no return type visible); no error handling guidance; no indication of pagination or result limits despite aggregating multiple sources. The tool name 'search' is generic and lacks the verb_noun clarity pattern (e.g., 'web_search' or 'aggregate_search' would be clearer). Tool definition appears in frontend/src/router.js rather than backend MCP service code, suggesting the schema may be inferred rather than explicitly registered in the MCP service implementation.

• Document the complete output schema: return type (object), field names (e.g., results[], total_count, next_cursor), and field types. Example: {results: [{title, url, snippet, source}], total_count: number, next_cursor: string}.
• Add enum constraint to 'onlyTypes' and 'excludeTypes' parameters. List all valid provider types (e.g., 'tavily', 'brave', 'google', 'bing') as an enum in the schema, not just in description text.
• Add pagination parameters: 'limit' (1-50, default 20) and 'offset' or 'cursor'. Document max results per call and how to fetch next page.
• Add error handling guidance to description: 'Returns error if query is empty, all providers fail, or timeout occurs (>30s). Retry with fewer provider types or check provider configuration.'
• Verify tool is explicitly registered in backend/src/mcp/mcp.service.ts with full schema. Confirm McpService.tools array includes 'search' with complete input/output definitions.