Both tools lack input schemas entirely, cannot verify parameter types, constraints, or structure. Descriptions are present but minimal (under 100 chars each). No evidence of output schema documentation. Tools are named with verbs (search_, save_) but lack the depth required for production use. The example code shows tool invocation via OpenAI-compatible API, but the actual MCP tool definitions are not visible in the provided source, only inferred from the example client.

• Provide explicit tool registration with full JSON Schema input schemas. Define all parameters with type, description, required status, and constraints (e.g., search_memory query: string, max 500 chars; save_memory fact: string, max 1000 chars).
• Expand tool descriptions to 150 - 250 chars. Example: 'search_memory: Query persistent facts about the user stored across all sessions. Returns matching facts with timestamps. Call this before answering user questions to check prior context.'
• Document output schemas. E.g., search_memory returns {facts: [{text: string, timestamp: ISO8601, source: string}], total_count: number}.
• Add parameter descriptions. E.g., 'query (string, required): Search term or natural language question. Max 500 chars. Supports partial matching.'
• Include error guidance. E.g., 'If no facts match, return empty list with message: "No prior facts found. This is the first mention of this topic."' to help LLMs handle edge cases.

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained