MCP field guide / Redis
// mcp field guide · datastore
"It's just a cache" is the assumption that gets teams hurt — Redis is often a system of record (sessions, RAG vectors, operational data), and this server writes to it. There's no FLUSHALL tool today — but scan_all_keys plus a per-key delete loop is an agent-driven keyspace wipe, and it can't be undone without a backup.
GUARD FIT · READS
PASS-THROUGHget, hgetall, lrange, zrange, vector search. No data change. (Note scan_all_keys is a recon primitive — log it.)
GUARD FIT · WRITE + DELETE
STRONGset/hset overwrite; del/rename/expire lose data. Mass-delete loop is catastrophic.
Overall fit: STRONG on the write path — Redis here is a write-capable datastore, not a disposable cache.
redis/mcp-redis is Redis Inc.'s official server (MIT, local stdio). It gives an agent a natural-language interface to read and write any Redis structure — strings, hashes, lists, sets, sorted sets, streams, pub/sub, RedisJSON — plus vector search over embeddings and server-info tools. Common framing: session state, caching, rate limiting, and RAG/semantic search. It connects to whatever Redis you point it at.12 There's no built-in read-only toggle — the recommended way to restrict a session is an external read-only Redis ACL user.
| Tier | Tools (actual function names) |
|---|---|
| read-only | get, hget/hgetall, lrange, smembers, zrange, xrange, json_get, type, scan_keys, scan_all_keys (⚠️ enumerates the entire keyspace), dbsize, info, vector_search_hash, hybrid_search |
| mutating | set, hset, json_set, lpush/rpush, sadd, zadd, xadd, publish, create_vector_index_hash |
| destructive | delete (DEL — removes a whole key), rename (clobbers its target if it exists), expire (deferred data loss), hdel/lpop/rpop/lrem/srem/zrem/xdel, xgroup_destroy |
The catastrophic case, stated precisely (verified): the current official server exposes no flushdb, flushall, or raw-command tool — so a single call can't wipe the DB. But whole-keyspace destruction is reachable by composition: scan_all_keys to enumerate every key, then delete per key — an agent-driven FLUSHALL. Treat mass delete loops as top-severity. (If a future release or fork adds flushdb/flushall or a passthrough command tool, gate those at the top.)
Agent session memory. Store/fetch chat history and session state during a run.
RAG + semantic search. Build vector indexes (create_vector_index_hash) and run vector_search_hash/hybrid_search over embeddings.
Operational data. Manipulate lists, sorted sets and streams for queues, counters and leaderboards from natural language.
Reads → pass through. Auto-allow. One flag: scan_all_keys/info/client_list are recon/exfiltration surface — log, don't necessarily gate.
Mutations → strong. set/hset/json_set/zadd — require approval showing the key and value written. Compensation is sometimes possible (a fresh write can restore an overwritten value only if the prior value was captured first) — compensation, not true undo, and it fails for pre-existing values you never read.
Destructive → strong, block-by-default. delete, rename (silently clobbers its target), expire, and the element-removal family are irreversible without a backup/RDB-AOF snapshot. delete and rename are the highest-severity single calls today; any mass delete loop (especially after scan_all_keys) is the catastrophic one.
The honest line: once a key is DEL'd or a target overwritten by RENAME, no deterministic rollback exists unless the proxy snapshotted the value beforehand. A composed FLUSHALL on a Redis used as a datastore cannot be undone — recovery depends entirely on external persistence/backups that may not exist. That's the case for refuse-by-default + explicit out-of-band confirmation, not a promised rollback.
ChronoMCP passes reads through and holds delete/rename/overwrites for a human — flagging mass-delete loops as catastrophic and irreversible.
Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Redis. Tool names are the actual function names read from source; the absence of flush/raw-command tools is verified. The composed-FLUSHALL risk is an inference from real tool capabilities. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.