Single tool 'search' has a clear, action-verb name and reasonable description (89 chars). However, the input schema is minimal, only a 'query' string parameter with basic description. No output schema is documented in the visible code. The tool lacks parameter constraints (enums, ranges), error handling guidance, and composition details. No tool annotations (readOnlyHint, etc.) are present. The server exposes a narrow interface suitable for RAG but lacks the depth expected of production-grade tools.

• Document the output schema explicitly. Specify fields like 'passages' (array of strings), 'provenance' (array of {source, page, offset}), 'scores' (array of floats), and 'total_results' (integer). Include example output in the tool description or a separate schema block.
• Add constraints to the 'query' parameter: minimum length (e.g., 3 chars), maximum length (e.g., 500 chars), and guidance on supported syntax (e.g., 'Boolean operators (AND, OR, NOT) are supported; wildcards (*) are not').
• Add pagination parameters: 'limit' (1 - 100, default 20) and 'offset' (default 0). Return 'total_results' in the response so the agent knows if more results exist.
• Include error handling in the description: 'Returns empty results if no passages match the query. If the corpus is locked, returns an error with the message "Corpus locked, provide MDCX_KEY environment variable."'
• Add tool annotation 'readOnlyHint: true' to signal that this tool is safe to call without side effects. This aligns with current MCP spec (2026-07-28) and helps agents reason about retry safety.