AlperAI provides 5 search-focused tools with good naming conventions (all start with search_ or web_ verbs). All tools have complete input schemas with proper JSON structure and documented parameters. However, descriptions are notably brief (averaging ~80 characters), and there are significant gaps in parameter descriptions and output schema documentation. No error handling guidance is visible, no tool annotations for safety classification, and the server appears designed as a client library rather than a proper MCP server with full spec compliance. Tools are focused but lack the depth of guidance needed for robust LLM selection and error recovery.

• Expand tool descriptions to 100-200 characters, explaining not just WHAT each tool does but WHEN to use it and how it differs from similar tools. E.g., for search_frontend_components: 'Search for reusable UI components and design patterns within a specific framework. Use this when you need a single element like a button or card. For complete page layouts, use search_frontend_templates instead.'
• Document output schemas for all tools. Specify what fields each returns (e.g., web_search returns [{url, title, snippet, date}, ...]). Include a result count and example for each.
• Add error guidance to descriptions: 'Errors: Returns empty results if no matches found. Returns 'rate limited' if quota exceeded (retryable). Returns timeout if search takes >30s.'
• Add tool annotations to all tool definitions: readOnlyHint=true (since all are read-only). This enables MCP clients to cache results and optimize retry logic.
• Constrain numeric parameters: num_results should be 1-50 (documented in description and schema min/max). Add enum or pattern validation for 'style' and 'style_preference' parameters.
• Add pagination: support limit (default 10, max 50) and offset (or cursor) parameters. Return total_count in response. This prevents context window exhaustion for popular queries.
• Consider splitting search_frontend_components and search_frontend_templates into more granular tools if they serve very different use cases, or add clearer guidance on when to use each.
• Add input validation examples in descriptions: 'technology parameter: valid values are React, Vue, Flask, Python, Node.js, etc. (not case-sensitive).'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry