Redis exposes plenty of statistics and almost nobody knows which combinations mean trouble. High fragmentation with normal memory use, a slowlog full of KEYS, a latency chart that spikes exactly when a background save runs — those are recognisable to someone who has operated Redis and invisible in raw INFO output. Encoding that recognition into the tools means an agent returns a finding rather than a table for a human to interpret. The TTL coverage check is the quiet standout: a cache where most keys have no expiry is the failure that shows up as a memory alert months later, and nothing else surfaces it.
A diagnostic layer over Redis: seven focused analysers plus one that runs them all, each interpreting the server's own statistics rather than returning them.
- analyze_memory detects high fragmentation, RSS overhead and maxmemory conditions rather than reporting bytes used.
- analyze_slowlog reads the SLOWLOG and identifies dangerous O(N) commands specifically — the class that looks fine until the key grows.
- analyze_latency separates the causes that matter: fork latency spikes from RDB and AOF, and AOF fsync stalls.
- analyze_keyspace checks TTL coverage and hit-versus-miss ratio, which is how you tell a cache from an accidental permanent store.
- analyze_clients finds blocked clients and connection-pool problems, and analyze_replication reports replica health from the master's side.
- analyze_config flags security and reliability risks in the configuration itself.
- analyze_performance runs every analyser for a full assessment in one call.
REDIS_URL. Everything here reads — there is no tool that changes configuration or evicts anything.
One command — npx -y mcp-redis-diagnostics