agentMemory provides clear tool names with action verbs (memory_write, memory_read, memory_search, etc.), but suffers from incomplete descriptions, missing output schema documentation, and no error handling guidance. All 7 tools have input schemas with type definitions and parameter descriptions, which is good. However, tool descriptions are inconsistent in quality, some lack WHEN and WHY context. Output schemas are inferred from code but never explicitly documented in the tool definitions. No error classification, recovery guidance, or actionable error messages. The schema structure shows properties with descriptions, but there is no documented return type structure, and no guidance on pagination or result limits for list/search operations. The server appears to be a VSCode extension with STDIO transport, limiting its applicability to hosted MCP clients.

• Add explicit output schema documentation for all 7 tools. Example for memory_read: 'Returns: {id: string, key: string, type: enum, content: string, tags: string[], createdAt: number, updatedAt: number, metadata: {accessCount: number, createdBy: string}}'
• Expand tool descriptions to answer: What does it do? When/why use it? What's returned? What are prerequisites? Example: 'memory_read: Retrieve a stored memory by exact key. Use this when you know the memory key and need its full content. Returns the memory object or null if not found. Call memory_search first if you only have a keyword.'
• Add per-tool error handling guidance. Example for memory_write: 'On failure, returns {success: false, error: string}. If error contains "already exists", try memory_update instead. If error contains "storage full", request cleanup via project_stats.'
• Document pagination for memory_search and memory_list. Add 'offset' parameter to both. Clarify: 'limit max 100 per request; use offset for pagination to avoid context window overload.'
• Clarify the enum values for 'type' parameter with use-case guidance. Example: 'type: one of [architecture (system design), pattern (reusable technique), feature (implemented functionality), api (integration point), bug (known issue), decision (project choice)]. Choose based on memory purpose.'
• Remove or move internal performance notes (2μs, 100μs targets) from descriptions to code comments; they distract from LLM decision-making.
• For memory_update, document whether it appends or replaces. Currently description says 'Append' but code shows it sets content directly, clarify semantics.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry