Smriti has well-structured tool definitions with clear naming (verb-noun pattern: remember, recall, search, list, update, append, archive, delete, trace, consolidate). All 10 tools have descriptions and input schemas with typed parameters. However, descriptions are often generic and lack actionable context for LLM selection. Parameter descriptions exist but are sparse on constraints (enums, ranges, formats). Output schemas are not documented, LLMs cannot predict return structure. Error handling guidance is absent. Security considerations (permission gates, audit trails) are not visible in tool definitions. The metadata schema is comprehensive but overly permissive (many optional fields with minimal validation hints).

• Document output schemas for all tools. Example: search() returns {results: [{id, title, snippet, score}], total, next_cursor}. Include field types and whether pagination is supported.
• Add enum constraints to parameters: status ∈ {active, archived}, memory_type ∈ {episodic, semantic, procedural, preference, decision, handoff, error_pattern}, confidence ∈ {high, medium, low, inferred, user-stated}.
• Expand tool descriptions to 100 - 200 chars with selection context. Example: 'Search memories by query text. Use this when you have a keyword or phrase; use recall() if you already have a memory ID.'
• Add confirmation/dry-run support to delete(). Return {would_delete: {id, title}} on dry_run=true, then require explicit confirm=true to execute. Document that deletion is irreversible.
• Document error cases and recovery paths. Example: 'If memory not found, try search() with a partial title. If permission denied, check visibility scope.'