Side-by-Side Model Context Protocol Comparison
Keymem vs Kanboard MCP
In-depth architectural comparison of the Keymem and Kanboard MCP 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
Kanboard MCP
Workplace & Productivity · Local stdio
Quality: 60/100 (Good) | Auth: API Key required
Verdict Summary: Choose Keymem if you need specialized Workplace & Productivity tools running via a local process. Choose Kanboard MCP 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).
- Primary tools included: recall, browse_keys, read_key.
Choose Kanboard MCP when:
- You need dedicated capabilities in the Workplace & Productivity domain.
- You prefer local stdio subprocess transport architecture.
- Your security boundary fits: API Key required (Free / Open Source).
- You have access to required keys:
KANBOARD_URL, KANBOARD_USERNAME, KANBOARD_API_TOKEN. - Primary tools included: add_project_user, attach_file_to_task, close_task.
Feature & Specification Comparison
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 Configuration
Kanboard MCP Configuration