Single tool with critical definition gaps. Tool name 'lookup_or_insert_cache' violates single-responsibility principle (combines lookup AND insert). Input schema present but parameters lack descriptions entirely. Tool description is 108 chars but vague about when to use it and what it returns. No output schema documented. Parameters 'query_prompt' and 'estimated_tokens' have type info but zero descriptions, LLM cannot infer intent. No error handling guidance. No pagination, no result limits, no chaining IDs. Stateful cache_store in client violates stateless request handling. This server reads like a proof-of-concept, not production-grade.

• Split 'lookup_or_insert_cache' into two tools: 'lookup_cache' (read-only, returns match or null) and 'insert_cache' (write, returns inserted key). Each tool has one clear responsibility.
• Add parameter descriptions: 'query_prompt' → 'The prompt text to look up or insert (string, 1-10000 chars)'; 'estimated_tokens' → 'Estimated token count for cost calculation (integer, 1-1000000, used only for cost_saved_usd calculation)'.
• Document output schema with all fields: cache_status (enum: CACHE_HIT_SEMANTIC_MATCH | CACHE_MISS_NEW_INSERT), matched_key (string or null), jaccard_similarity (float 0-1), tokens_saved (integer), cost_saved_usd (float), cached_response (string or null), inserted_key (string or null), total_cached_entries (integer).
• Expand tool description to 150-250 chars: 'Look up a prompt in the semantic cache using Jaccard token similarity (threshold 0.80). Returns cached response if match found, otherwise inserts new entry and returns insertion key. Use to avoid redundant LLM calls for semantically similar prompts.'
• Make cache stateless: accept cache_store as a parameter or load from persistent storage (file, database) on each request. Do not rely on in-memory state across invocations.