Engram has clear, well-structured tool definitions with good naming (verb_noun pattern: t_auto_context, t_smart_search, t_save, t_delete, t_list, t_stats). Descriptions are present and moderately detailed (avg ~150 chars), explaining what each tool does and when to use it. Input schemas are visible with type definitions and parameter descriptions. However, output schemas are not formally documented, responses are inferred from code (e.g., t_auto_context returns {ctx, n, cats} but this is not declared in a schema). Error handling is minimal (t_smart_search returns {error: 'query required'} but lacks recovery guidance). Parameter constraints are present (limit 1-8, importance 1-10) but some descriptions could be more explicit about format and validation rules. No tool annotations (readOnlyHint, destructiveHint) are visible in the code.

• Add formal output schema declarations for all tools. Document response fields, types, and examples. E.g., t_auto_context returns {ctx: string, n: integer, cats: object<string, integer>}.
• Implement tool annotations in MCP registration: mark t_delete with destructiveHint=true, t_auto_context/t_smart_search/t_list/t_stats with readOnlyHint=true, and t_save with idempotentHint=true (if ID-based upsert is idempotent).
• Enhance error messages with recovery guidance. E.g., 'Query required. Provide a search string to find memories by content.' and 'Conflict detected: similar memory exists (ID: abc123). Provide an explicit ID to update, or modify content to create a new memory.'
• Expand parameter descriptions to include format constraints. E.g., 'tags: Comma-separated tags (max 200 chars, alphanumeric + hyphens only)' and 'content: Memory text (required, max 8000 chars, UTF-8).'
• Clarify t_save upsert semantics: 'If id is provided and exists, update the memory; if id is provided and does not exist, create with that ID; if id is omitted, generate from content hash and create or update based on hash match.'