The agent ran a simple key lookup and the entire application latency spiked — but no error was logged anywhere. Why?
The silent failure that takes down production Redis: the agent (or a server fallback path) issued KEYS * to find a key — an O(N) blocking command that freezes the Redis single-threaded event loop. Every other client queues behind it, and the resulting latency spike masquerades as a network problem because Redis never raises an error for legal commands. The engineering fix: strip KEYS from the ACL (-keys), force SCAN with COUNT hints for any keyspace exploration, and confirm with SLOWLOG GET — the offending KEYS call will be sitting there with a microsecond timestamp and your agent fingerprints all over it.
Why does the agent get nil for keys that definitely exist?
Almost always a wrong logical database index (SELECT 1 vs SELECT 0) or a keyspace prefix mismatch — Redis returns nil, never an error, so the agent concludes the key expired. Pin the DB index in the connection and verify with SCAN MATCH against the expected prefix.
Can it work with Redis Streams and Pub/Sub?
Streams yes — XRANGE and XADD work within ACL limits and are excellent for queue inspection. Pub/Sub is a poor fit: it is connection-stateful, and stdio MCP servers are request-scoped, so subscriptions do not survive across tool calls. Use keyspace notifications persisted to a stream instead.
Does it support Redis Cluster mode?
Point the server at a single replica for read workloads. Cross-slot writes will fail with MOVED redirects that the server may not follow — for cluster write workflows, route through a proxy that handles slot mapping.