Keymem vs MCP Odoo — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Keymem vs MCP Odoo
In-depth architectural comparison of the Keymem and MCP Odoo MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
Keymem
Workplace & Productivity · Local stdio
Quality: 64/100 (Good) | Auth: No auth required
MCP Odoo
Workplace & Productivity · Local stdio
Quality: 69/100 (Great) | Auth: other
Verdict Summary: Choose Keymem if you need specialized Workplace & Productivity tools running via a local process. Choose MCP Odoo if your workspace requires Workplace & Productivity integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose Keymem when:
You need dedicated capabilities in the Workplace & Productivity domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
Associative key-graph memory for LLM agents — recall by association, not vector similarity.
Production-grade MCP server for Odoo ERP (16-19) with zero Odoo-side install. 24 tools across read, write (approval-token gated), diagnose, migrate, and audit. JSON-2 transport for Odoo 19+, real Docker Compose smoke tests against Odoo 16/17/18/19, diagnostics (diagnoseodoocall, upgraderiskreport, fitgapreport, scanaddonssource), and 5 reusable agent prompts.
Category & Scope
Tools & Capabilities Breakdown
Keymem Tools (12)
recall
Search long-term memory for what is already known about the user, project, or topic — call this before your first reply and whenever the topic shifts. Always pass the active namespace when known. Returns matching key clusters only (not memory content): canonical concept, aliases, key type, match score, linked-memory count, hub status, and specificity. For a core lookup, complete read_key(key_id, original_query, namespace) then read_memory(memory_id, via_key_id, namespace): only the full read grows depth/access, reinforces the traversed edge, and learns aliases. Use short focused noun queries and decompose multi-fact questions into several recall calls. inject:true is only an unconfirmed passive preview and must not replace that traversal; injected memories are not reinforced. inject_top_k defaults to 1; inject_max_chars defaults to 2000 and marks truncated previews. An empty result returns {status:'no_match', nearest_keys} — the closest stored concepts below the gate; retry with one of those concepts when relevant.
browse_keys
Browse the vocabulary of one namespace when recall has no hit or you need an entry point. Returns active key clusters with hubs first, then by linked-memory count. This is index metadata only; continue with read_key(key_id, query, namespace) and read_memory(memory_id, via_key_id, namespace).
read_key
List the memories stored under one key (concept), ranked. Returns the canonical key, its aliases, and hub metadata plus ranked memory IDs and metadata — never memory content. Always pass the original focused query and active namespace when known: handles are then ranked by content relevance, which is essential for hubs. Call read_memory(memory_id, via_key_id=key_id, namespace) on the selected handle to confirm the fact and reinforce the path. Use limit/offset to page without flooding context.
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
Keymem is categorized under Workplace & Productivity and uses a local stdio subprocess. In contrast, MCP Odoo belongs to Workplace & Productivity using local stdio subprocess. Select Keymem when you need capabilities focused on workplace & productivity and MCP Odoo when you require tools for workplace & productivity.
Read the full content of one stored memory (selected via read_key). Returns the memory and all connected key clusters so exploration can continue Key → Memory → Key. Pass via_key_id from the selected key: only that traversed edge is Hebbian-reinforced, and depth/access count increase only when this full read occurs.
remember
MANDATORY END-OF-TURN GATE: before replying, save every durable fact newly revealed this turn (names, preferences, decisions, corrections, project facts, goals). A durable fact left unsaved is a bug; save silently in the same turn. Save nothing only after consciously confirming that nothing durable appeared. Before writing, recall() the topic in the same namespace and reuse returned canonical concepts or aliases. Use 3-6 diverse ATOMIC concept keys of 1-2 words each, never memory-specific phrases (use 'Nexora' and 'portfolio', not 'Nexora portfolio'); 3+-word keys are flagged in hints.phrase_keys and are measurably 91% unreachable singletons. CROSS-LINGUAL: register both language forms together (for example '포트폴리오' and 'portfolio'). Shared broad keys become navigable hubs. namespace groups memories by project/context; ttl_seconds sets expiry; related_to adds explicit memory links; source attaches provenance and is auto-stamped with the server session, a timestamp, and — when a host agent (Claude Code, Codex) transcript is active — host_session/host_agent/host_turn so the memory can be traced back to its original conversation via get_conversation. The response may include hints.near_keys (existing concepts your keys nearly duplicate — prefer reusing those concepts) and hints.language_note (add the missing-language variants).
correct
Update outdated information. Use when user corrects you or info changes (e.g. moved cities, changed job). Old version is preserved but weakened — never lost. Omit keys to keep the same search terms. related_to links the updated memory to other memory IDs.
related
Find other memories associated with a memory you already have (by ID). Returns neighboring memories connected by shared keys or explicit links. For normal agent-driven navigation prefer read_memory(), inspect its returned keys, then call read_key().
forget
Permanently delete a memory. Only use for completely wrong information. For outdated info, use correct() instead — it preserves history.
list_memories
List all stored memories. namespace filters by project/context. Expired memories are excluded. Prefer recall() for normal retrieval.
remember_batch
MANDATORY END-OF-TURN GATE: when a turn reveals multiple durable facts, save them silently before replying. A durable fact left unsaved is a bug. Recall each topic first, reuse canonical concept-level keys (ATOMIC, 1-2 words each — never phrases), and register cross-lingual forms together. Each item: {content, keys, key_types?, namespace?, ttl_seconds?, related_to?}. Returns saved IDs and is more efficient than multiple remember() calls.
cleanup_expired
Delete all memories past their ttl. Returns count of deleted memories. Call periodically to keep memory clean.
memory_stats
Get counts of keys, memories, and links in the system.
MCP Odoo Tools (41)
data_quality_report
Run read-only data-quality checks on one Odoo model: duplicates, missing required values, orphaned references, format anomalies
diagnose_odoo_call
Diagnose an Odoo model call without executing it
generate_json2_payload
Build a JSON-2 request preview without network access
inspect_model_relationships
Inspect model relationships and required field metadata
diagnose_access
Diagnose ACL and record-rule visibility for an Odoo model
upgrade_risk_report
Report Odoo upgrade and JSON-2 migration risks
analyze_upgrade_log
Classify Odoo install/update log errors into a migration worklist (no_action / needs_review / needs_script) with fix suggestions
lookup_model_history
Look up Odoo model rename/removal history by old or new model name (e.g. account.invoice -> account.move)
fit_gap_report
Classify Odoo requirements into fit/gap implementation buckets
scan_addons_source
Scan local Odoo addon source without importing addon code
build_domain
Build a validated Odoo domain from structured conditions
business_pack_report
Report expected modules, models, and safe discovery calls for a business pack