Four servers, read from their own repositories: what each one lets a model run, and what that costs you on a live instance.
Redis is single-threaded. That one fact decides most of what a Redis MCP server should and should not do, because a badly chosen command from a model does not just return slowly -- it blocks every other client on the instance until it finishes. There are several Redis MCP servers now, including an official one from Redis itself, and they take genuinely different positions on that question. This post compares four of them against their own repositories, not their marketing, and ends with the checks worth running on whichever one you pick.
Key enumeration is the first thing an agent tries, because the first question anyone asks a cache is "what is in here?". There are two ways to answer it, and the difference is the whole post.
KEYS user:* # O(N) over the entire keyspace, one uninterruptible passSCAN 0 MATCH user:* COUNT 100 # cursor-based, yields the event loop between batchesRedis documents the hazard itself. The KEYS command page gives the complexity as "O(N) with N being the number of keys in the database" and says plainly: "Use extreme care when using this command in production environments. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code."
It is worth quoting the other half of that page too, because the point is easy to overstate: "the constant times are fairly low. For example, Redis running on an entry level laptop can scan a 1 million key database in 40 milliseconds." On a small dev instance, KEYS is not a catastrophe. The problem is that a model cannot see how large your keyspace is, and the instance it reaches for is often the one that matters most.
Redis publishes this itself and said so on its blog: "we're excited to introduce Redis' MCP servers through two open-source projects: mcp-redis and mcp-redis-cloud". It is Python (3.10+), MIT licensed, shipped to PyPI as redis-mcp-server, and it is by far the broadest server here: 53 tools across 11 modules covering strings, hashes, lists, sets, sorted sets, streams with consumer groups, JSON documents, pub/sub, and a vector query engine. As of September 2026 it has 620 stars and active commits.
On the KEYS question it does the right thing. Its scan_keys tool is cursor-based, and its own docstring describes the SCAN command as "non-blocking, production-safe". Where it differs from ours is write posture: delete, expire, rename and the type-specific setters are ordinary tools, available whenever the server is. There is no read-only switch; I checked the repository three ways and found no such flag in code, only a read-only Redis ACL user in the README's configuration section. That is a deliberate design choice, not an oversight -- the server exists to let agents manage data -- but it means the boundary lives in Redis, not in the server.
Seven tools, MIT, Node via npx, and a deliberately narrower job: explore and diagnose, do not administer. Enumeration is SCAN-only with a bounded COUNT and an iteration cap; KEYS is rejected by the command gate with a message pointing at the scan tool instead. Commands are classified against a curated read-only allowlist, mutating commands need ALLOW_WRITES=1, and anything on neither list is refused -- so the gate fails closed rather than letting an unfamiliar command through. Verbs whose safety depends on the subcommand are split: CONFIG GET passes, CONFIG SET does not. EVAL, FUNCTION, SCRIPT, MONITOR and SHUTDOWN appear on neither list, so they are unavailable in every mode.
The other half is diagnosis: redis_health rolls INFO, DBSIZE and SLOWLOG into one answer, and redis_advisor samples the keyspace for big keys, missing TTLs, eviction pressure and fork-latency risk. It is the same argument we made about the Postgres MCP server with a known SQL injection: the datastore server is the last layer before the data, so its defaults are the security model. Details and install line are on the server card.
Search results still surface the Model Context Protocol project's own Redis server, and it is worth knowing two things about it. First, it is archived -- the reference repository lists it under "Archived" along with Postgres, GitHub and Slack, and the archive has had no commits since May 2025. Second, its four tools are set, get, delete and list, and list is implemented as redisClient.keys(pattern). That is the exact shape Redis tells you not to ship. It was a reference implementation demonstrating the protocol, and the repository says as much; it was never meant to be the thing you point at production.
farhankaz/redis-mcp (MIT, TypeScript) offers 13 narrow tools -- hashes, sorted sets, sets, plus a cursor-based scan -- with writes always available and no read-only mode. GongRzhe/REDIS-MCP-Server is archived, with no commits since March 2025. And redis/mcp-redis-cloud is a different job entirely: it drives the Redis Cloud REST API to create and manage subscriptions and databases, rather than reading the keyspace inside one.
| Capability | @yawlabs/redis-mcp | redis/mcp-redis (official) | Archived reference server |
|---|---|---|---|
| Key enumeration | SCAN only; KEYS blocked at the gate | SCAN (scan_keys, scan_all_keys) | KEYS, via its list tool |
| Default write posture | Read-only until ALLOW_WRITES=1 | Writes always available | Writes always available |
| Unrecognized command | Rejected (fail-closed allowlist) | Fixed tool set, no raw command tool | Fixed tool set |
| EVAL / FUNCTION / MONITOR | Never exposed, in any mode | No such tool | No such tool |
| Data coverage | Reads across the core types | Core types plus JSON, pub/sub, streams groups, vector search | Strings only |
| Health / advisor | redis_health, redis_slowlog, redis_advisor | Server management tools (INFO, DBSIZE) | None |
| Tools | 7 | 53 across 11 modules | 4 |
| Runtime | Node via npx, bundled, no runtime deps | Python 3.10+, uvx / PyPI / Docker | Node (unmaintained) |
| Auth extras | TLS, ACL user in the URL | TLS, cluster mode, Entra ID for Azure Managed Redis | Connection string |
| License / upkeep | MIT, Yaw Labs | MIT, maintained by Redis | MIT, archived May 2025 |
The official server is the better choice for most people, and it is worth being direct about why. If you want an agent to actually use Redis -- cache a computed value, store a session with an expiry, append to a stream, keep conversation history, build and query a vector index for RAG -- that is what redis/mcp-redis is built for, and ours flatly is not. Seven read-first tools cannot substitute for 53. Our server has no JSON document support, no pub/sub, no consumer-group management, no vector search, no cluster administration, and it will not grow them, because the moment it does the read-first posture stops meaning anything.
The official server also carries operational features we do not have: Entra ID authentication for Azure Managed Redis, cluster mode, a published Docker image, and the ordinary but real advantage of being maintained by the company that makes the database. If Redis ships a new data type next year, their server will cover it first.
And their security recommendation is the better one. The official README points you at a least-privileged Redis ACL user -- ACL SETUSER readonlyuser on >mypassword ~* +@read -@write -- and that boundary is enforced by Redis itself, on every connection, regardless of which MCP server is in front of it. An in-process allowlist like ours is defense in depth on top of that, not a replacement for it. If you only do one thing after reading this, do that one.
keys(. It takes ten seconds and it is the single highest-value check.Add it to any MCP client, or let Yaw MCP fan one config out to every client on the machine:
npx -y @yawlabs/redis-mcpSource: github.com/YawLabs/redis-mcp.
Yes. Redis publishes two, and says so on its own blog: mcp-redis for the data plane and mcp-redis-cloud for the Redis Cloud REST API. Both are MIT licensed. mcp-redis is the Python one, published to PyPI as redis-mcp-server, and it is the broadest of the servers compared here at 53 tools.
Because Redis is single-threaded, so those milliseconds are milliseconds during which no other client is served. Redis's own documentation makes both points: the constant times are fairly low, and you should use extreme care with the command in production and not put it in regular application code. The risk is not a laptop with a million keys. It is a model that cannot see how large your keyspace is choosing the command for you on a busy instance.
If you want the agent to write data, manage JSON documents, use pub/sub or run vector search for RAG, use the official redis/mcp-redis server, which is built for that and maintained by Redis. If you want an agent to explore and diagnose a live instance without being able to change it, a read-first server like ours fits better. Either way, put a least-privileged Redis ACL user in the connection URL, which is what both projects recommend.
Jeff Yaw, Yaw Labs. Follow along at tokenlimit.news for weekly notes on AI infrastructure.
Published by Yaw Labs.