| FMRS | 59 / 100 · C | 79 / 100 · B | 74 / 100 · B |
|---|
| Reliability | 9 / 20 | 12 / 20 | 13 / 20 |
|---|
| Security and permissions | 11 / 20 | 18 / 20 | 13 / 20 |
|---|
| Maintenance | 12 / 20 | 17 / 20 | 17 / 20 |
|---|
| Documentation | 14 / 20 | 17 / 20 | 16 / 20 |
|---|
| Setup experience | 13 / 20 | 15 / 20 | 15 / 20 |
|---|
| Best for | - AI agents that need offline, low-latency, local memory.
- Developers who want to avoid LLM calls during memory storage and recall.
- Projects requiring persistent memory, knowledge graphs, or Hebbian learning.
- Teams using Zenoh, ROS2, or robotic mission memory.
| - Teams already using ClickHouse who want AI assistants to access data directly.
- Scenarios requiring fast, read-only data queries and schema exploration.
| - Teams that want precise control over which database operations an AI can perform, rather than open arbitrary SQL execution
- Scenarios needing a unified MCP setup across multiple database engines
|
|---|
| Not for | - Users seeking a hosted cloud memory service or built-in multi-tenant authorization.
- Applications expecting the server itself to perform LLM inference.
- MCP clients operating without an available local backend.
- Workflows that only need simple stateless text processing.
| - Scenarios requiring write access to the database without explicit opt-in.
- Production environments with stringent security requirements that avoid default permission settings.
| - Lightweight cases that just want to run a few ad-hoc SQL queries without maintaining a tools.yaml config (a simpler single-database MCP may be a better fit)
|
|---|
| Required permissions | - Access to read and write Shodh-Memory's local memory data.
- Permission to launch the npm package and local MCP server over stdio.
- Network access to the address specified by SHODH_API_URL when using a remote backend.
- SHODH_API_KEY when authentication is enabled; this variable is secret.
- The tools can create, modify, and delete memories, todos, projects, reminders, and backups.
| - Requires read-only access to ClickHouse database (default).
- Optional: write access via CLICKHOUSE_ALLOW_WRITE_ACCESS.
- Optional: destructive operations via CLICKHOUSE_ALLOW_DROP.
| - Database credentials (username/password/connection string) are supplied via env vars or config
- A tool's actual permission is whatever SQL statement is defined in tools.yaml — designed for least privilege, but misconfiguration can still over-expose access
|
|---|
| Risks and side effects | - Memories, todos, projects, and backups may contain sensitive information and persist locally.
- forget, delete, purge, and backup_restore can cause data loss or overwrite data.
- For remote deployments, the deployer must protect the API key and network exposure.
- SHODH_USER_ID is a logical memory namespace, not an authorization tenant.
- A local model is downloaded on first run, requiring local resources and model storage.
| - If write access is enabled, AI might make unintended modifications.
- If DROP access is enabled, data deletion could occur accidentally.
- Credentials may be exposed via environment variables.
| - If tools.yaml defines SQL statements that allow unconstrained writes or deletes, the AI could accidentally modify data
- The prebuilt toolsets (--prebuilt) favor convenience and may expose broader query capability than a specific business actually needs — use a custom tools.yaml in production
|
|---|
| Supported clients | Claude Code, Claude Desktop, Cursor | Claude Desktop | Claude Code, Gemini CLI, Zed, Antigravity |
|---|
| Tools | 51 | 4 | 0 |
|---|