Memori-MCP provides two tools with partial schema and description clarity, but has notable gaps in parameter documentation, output schema specification, and error handling guidance. Naming is clear and action-oriented (store_memory, recall), but parameter descriptions are minimal and lack constraints. Output structures are returned as JSON strings rather than structured typed objects. The server lacks the production-grade polish expected for recommendation, descriptions are adequate but brief, and no guidance is provided for multi-step workflows or error recovery.

• Define explicit output schemas for both tools. store_memory should return {id: string, timestamp: string, success: boolean}; recall should return {results: [{text: string, score: float, id: string}], total_count: int, query: string}.
• Enhance store_memory description to include metadata constraints: 'Store a memory with text, unique ID, and optional metadata (category, tags as array of strings, custom fields allowed). Timestamp is auto-added.'
• Add parameter constraints to recall: 'k must be 1-50 (default 3). Query cannot be empty. Returns top k results ranked by relevance score (0.0 - 1.0).'
• Implement error classification and recovery guidance. Invalid input errors should suggest the constraint violated and a corrective action: 'Error: Query cannot be empty, provide a non-empty search term and retry.'
• Add pagination to recall: return total_count, limit results to 50 by default, and offer an offset parameter for pagination. Document this in the description.
• Document that store_memory is idempotent if called with the same ID, clarify whether repeated calls update or reject duplicates.
• Include example metadata schema in store_memory description or parameter schema to guide LLM usage.

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

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