Server has well-structured tool definitions with complete JSON schemas and Zod validation. All 10 tools have descriptions and input schemas with typed parameters. However, descriptions are often terse (10-50 chars), lacking context on WHEN to use tools or HOW they chain together. Parameter descriptions are minimal. Output schemas are not documented, LLMs cannot predict response structure. Error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Naming is verb-forward and clear, but some tools like 'get_context' conflate multiple concerns (memories + preferences + patterns in one call).

• Document output schemas for all tools. E.g., search returns {results: [{id, type, content, timestamp, project}], total_count, next_cursor}. Include field types and whether pagination is supported.
• Expand tool descriptions to 100-200 chars. Add WHEN to use: 'Use search() for full-text queries across all memories. Use get_context() to retrieve project-specific memories, preferences, and success patterns in one call.' Include chaining hints.
• Add tool annotations via MCP: mark search/timeline/get_* with readOnlyHint=true; mark add_observation/add_preference with destructiveHint=false (they are writes but not destructive); mark cleanup with destructiveHint=true.
• Split get_context into three focused tools: get_project_memories(), get_project_preferences(), get_project_patterns(). Agents can then compose them as needed without over-fetching.
• Add error handling guidance to cleanup: 'Returns {deleted_count, freed_bytes}. If deleted_count=0, no memories met the criteria. If deleted_count is high, consider increasing minImportance to preserve more data.' Include examples of retryable vs fatal errors.