amem has well-structured tool definitions with complete Zod schemas and consistent descriptions. All 6 tools are properly registered with input schemas and descriptions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameter descriptions are present but minimal (avg ~40 chars vs. baseline 72). Output schemas are not documented, LLMs cannot predict response structure. Error handling is basic (isError flag only, no recovery guidance). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Missing idempotency guarantees and confirmation patterns for destructive operations.

• Document output schemas for all tools. Example for memory_search: 'Returns array of {id, meta: {name, description, type, tags, keywords, context}, score}. Sorted by BM25 relevance. Max 10 results by default.'
• Add tool annotations via MCP SDK. Mark memory_search, memory_list, memory_links with readOnlyHint=true. Mark memory_delete with destructiveHint=true. Mark memory_add, memory_update with idempotentHint=true if they support idempotency keys.
• Expand tool descriptions to 100-150 chars with WHEN guidance. Example: 'Update an existing memory's metadata or content. Use this to refine descriptions, add tags, or fix typos. To create a new memory, use memory_add instead.'
• Add recovery guidance to error responses. Instead of 'Memory not found', return 'Memory not found. Try memory_search() with keywords or memory_list() to find the correct ID.'
• Implement dry-run or confirmation for memory_delete. Add optional 'confirm=true' parameter or return a confirmation token that must be passed in a second call to actually delete.