The server provides 3 tools (search, qa, retrieve) with basic structure but significant quality gaps. All three tools have descriptions and input schemas visible in the code, but descriptions are generic and lack specificity for LLM decision-making. Parameters have type information but lack detailed constraints and format guidance. Output schemas are not documented. Error handling is minimal, no recovery guidance or categorization. The tools are read-only but lack explicit readonly annotations. Parameter descriptions are present but brief (averaging ~40 chars, below the 72-char baseline for production tools). Tool names follow verb_noun convention (search_*, retrieve_*) but qa is ambiguous, does it answer questions, retrieve Q&A pairs, or validate answers? No pagination support visible despite semantic search returning multiple results. No output structure documentation means LLMs cannot plan downstream chaining. STDIO-only transport is a hard cap at 50 for protocol readiness, but definition quality itself is mediocre across all three tools.

• Rename 'qa' tool to a more specific verb: 'answer_question' or 'generate_answer'. The current name conflates question-answering with data retrieval and confuses LLM selection.
• Expand tool descriptions to 100-150 chars and address WHEN to use each tool. Example: 'search: Find documents by semantic similarity when you need relevant context. qa: Generate a direct answer to a question by synthesizing retrieved documents. retrieve: Get specific documents by ID or exact match when you know what you're looking for.'
• Document output schemas explicitly. For search and retrieve, specify: 'Returns list of {id: string, title: string, content: string, score: float, metadata: object}'. For qa, specify: 'Returns {answer: string, sources: [{id, title, excerpt}], confidence: float}'.
• Add parameter constraints and format guidance. E.g., 'limit: Maximum results to return (1-100, default 20)' and 'query: Free-text search terms or document ID (alphanumeric, <=500 chars)'.
• Implement pagination support with offset/limit or cursor. Add 'offset' parameter (default 0) and return 'total_count' and 'has_more' in results so agents can iterate large result sets.
• Add error handling guidance in tool descriptions. E.g., 'If no results found, try a broader query or check the knowledge base index status. If query fails, verify the query format and check system logs.'
• Implement per-tool error responses with recovery hints. When query returns empty, return {results: [], message: 'No documents matched. Try: (1) Broader terms, (2) Different language, (3) search_help to see indexed topics'}.

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

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