Memory-buddy defines 5 tools with clear verb-noun naming (recall_, search_, store_, forget_, list_). All tools have descriptions (avg 120 chars) and input schemas with types. However, output schemas are undocumented, LLMs cannot predict what recall_memory or search_memory return. Parameter descriptions are present but sparse (avg 45 chars). The forget_memory tool lacks a dry-run/confirmation pattern despite being destructive. No tool annotations (readOnlyHint, destructiveHint) are present in the MCP registration. Error handling is minimal, no recovery guidance or actionable error messages visible in the tool definitions.

• Document output schemas for all tools. E.g., recall_memory should return {facts: [{id, content, category, created_at}], summaries: [{id, content, turn_range}]}. This enables LLMs to chain tools and extract required fields.
• Add tool annotations to MCP registration: mark recall_memory, search_memory, list_memory_users with readOnlyHint=true; mark store_memory with destructiveHint=false; mark forget_memory with destructiveHint=true. This enables agents to reason about safety.
• Expand parameter descriptions to 50 - 150 chars with format hints. E.g., 'Natural language query (1 - 500 chars). E.g., "user prefers dark mode". Searches across all stored facts and summaries for this user.'
• Implement a dry-run or confirmation step for forget_memory. Return a preview of what will be deleted and require confirm=true to proceed. This prevents accidental data loss.
• Add error handling guidance to tool descriptions. E.g., 'If no memories found, returns empty list. If store fails due to quota, returns error with retry guidance. If user_id is invalid, returns 400 with available user IDs.'