cortex-memory defines 5 tools with adequate naming (verb-based prefixes) and present descriptions. However, CRITICAL GAPS significantly limit quality: (1) Most parameters lack descriptions, cortex_get_context and cortex_get_decisions have zero parameters, so no description deficit there, but cortex_search has a query parameter WITH description (good). cortex_save_memory has 3 parameters: 'type' (enum, has description), 'content' (HAS description), 'context' (HAS description), all three are well-described. cortex_status has zero parameters. (2) Tool descriptions are SHORT but non-empty: cortex_get_context (107 chars), cortex_search (88 chars), cortex_save_memory (77 chars), cortex_get_decisions (83 chars), cortex_status (99 chars). All within acceptable 10-1024 range and meet the 50-200 chars sweet spot. (3) CRITICAL ISSUE: Output schemas are NOT documented anywhere in the source. The code does NOT show what fields these tools return, only what inputs they accept. Without documented output schemas, LLMs cannot plan downstream tool calls or extract chained IDs. This violates pattern:tool and pattern:response-shaper. (4) Error handling is minimal, no evidence of error recovery guidance, categorization (retryable vs fatal), or actionable error messages in the code shown. (5) Security: No visible injection of secrets, permission gates, or audit logging. (6) Parameter schemas ARE present and mostly good (enums for 'type' in cortex_save_memory), but cortex_search's query parameter lacks constraints (no min/max length, regex, etc.). Overall: naming is solid, descriptions are present and adequate length, parameter schemas are partial, but OUTPUT schemas are completely missing and error handling is absent. This is typical of a community server that works but lacks production polish.

• Document output schemas for all 5 tools. For each tool, define the JSON structure of the response: field names, types, required vs optional fields, and descriptions. Example for cortex_search: { memories: [{id: string, type: string, content: string, created_at: string, relevance_score: number}], total_count: number, next_cursor?: string }.
• Add parameter constraints to cortex_search query. Specify: min length 1, max length 500, regex pattern if applicable (e.g. /^[a-zA-Z0-9\s\-_.]+$/), or guidance like 'Natural language keywords or project names'.
• Add error handling guidance to all tool descriptions. Examples: (1) cortex_search: 'Returns empty array if no matches found. If query syntax is invalid, returns detailed error suggesting correction.' (2) cortex_save_memory: 'Returns success with memory_id if saved. Returns conflict error if duplicate content detected (idempotency check via content hash).'
• Add idempotency to cortex_save_memory. Document: 'Calling twice with identical type + content + context is idempotent, returns same memory_id without duplication. Enables safe retries.'
• Add tool annotations to the MCP server registration. Mark cortex_get_context, cortex_search, cortex_get_decisions, cortex_status with readOnlyHint=true. Mark cortex_save_memory with destructiveHint=true and idempotentHint=true (after implementing idempotency). See MCP spec section on tool-annotations.
• Add pagination to cortex_search if result sets can be large. Include limit (default 20, max 100) and offset/cursor parameters. Return total_count so LLMs know if more results exist.