redis/mcp-redis: An MCP Server That Exposes Redis Primitives as Agent Tools

The gap between an agent that reasons and an agent that can write to Redis

An LLM that can describe a caching strategy still cannot set a key. Closing that gap normally means writing tool wrappers by hand: a function per Redis command, JSON schemas for each argument, and error handling that survives whatever the model emits. redis/mcp-redis removes that work by shipping the wrappers as a Model Context Protocol server. The README describes it as a natural language interface for agentic applications that manage and search data in Redis, and the examples it gives are telling in their ordinariness: store the entire conversation in a stream, cache this item, store the session with an expiration time, index and search this vector. These are not exotic operations. They are the operations a support bot, a coding assistant or a research agent needs on nearly every turn. The intended user is someone building on an MCP client (Claude Desktop, VS Code with GitHub Copilot, the OpenAI Agents SDK, Augment) who wants Redis reachable from the model without maintaining a bespoke tool layer. It is not aimed at application developers who already know which Redis command they want to call; those developers have redis-py and no reason to route through a language model.

What the tool surface actually covers, and where the module line falls

The server groups its tools by Redis data type rather than by command name. There are string tools for set and get with expiration, hash tools for field-value pairs (the README notes a hash can hold vector embeddings), list tools for append and pop, set tools for membership and set operations, and sorted set tools for score-ordered data such as leaderboards and priority queues. Pub/sub is exposed as publish plus stateful channel or pattern subscriptions, with the server returning subscription handles that the client uses to read queued messages. Streams get the full consumer-group lifecycle: add, read, delete, create and destroy groups, and acknowledge entries. JSON tools handle path-based document access. Two further groups sit outside the core types: a docs tool that answers natural-language questions against Redis documentation through an HTTP API configured by MCP_DOCS_SEARCH_URL, and query engine tools for managing vector indexes and running vector search. That last group is where the deployment matters. Vector search and JSON depend on Redis Stack modules being present on the target instance, and the README does not spell out what happens when they are not. If your Redis is a plain OSS server without those modules loaded, expect the corresponding tools to fail at call time rather than at startup. Verify module availability before you let an agent plan around them.

Installation: uvx from PyPI, or the Docker image

The recommended path is PyPI through uvx, which downloads the server on demand, builds a temporary environment and runs it. The README's configuration block for an MCP client looks like this: the server entry is named RedisMCPServer, the command is uvx, and the args are --from, redis-mcp-server@latest, redis-mcp-server, --url, and the connection string. Note the quoting in the published example: the URL appears as a JSON-escaped string with embedded double quotes around the redis:// value. That is worth testing in your own client config rather than copying verbatim, because some MCP clients pass the argument through with the quotes intact and the server then receives a URL that does not parse. A Docker image is also published under mcp/redis, and the README covers installation from GitHub and a development install as alternatives. The connection string follows the IANA redis and rediss URI schemes, so redis://user:secret@localhost:6379/0?foo=bar&qux=baz is the general shape, with the trailing 0 selecting database zero. TLS is expressed by the rediss scheme rather than a separate flag.

Configuration keys, ACLs and EntraID for Azure Managed Redis

Configuration can arrive as command-line arguments or as environment variables, and the README documents both paths. The one argument shown in full is --url. Authentication is handled in the URL itself (user:secret) or through a Redis ACL, which the README treats as a first-class configuration topic: you grant the server a user with exactly the command categories the agent should reach, rather than handing it the default user. That is the right instinct, because an agent with a broad key space and no ACL is an agent that can delete anything it can name. For Azure Managed Redis there is native EntraID support, documented as a separate configuration section, which matters because token-based auth does not fit the user:secret form of the URL. Logging has its own section, so the server can be made to emit a record of what the agent asked for. Treat the ACL and the logs as the two controls you actually have. The server does not appear to implement an approval step between the model's decision and the command's execution; if the model decides to flush a key, the tool call is the only gate.

The transport constraint: stdio only, streamable HTTP still pending

The README is explicit that the server supports the stdio transport and that support for streamable HTTP will be added in the future. This is the single most consequential limitation in the document. Stdio means the server runs as a child process of the MCP client on the same machine. It works well for a desktop assistant and poorly for anything shared: no remote agents, no multi-tenant gateway, no running the server once and pointing several clients at it. If your architecture assumes a central MCP endpoint that many agents call over the network, this project does not provide it today. A second constraint follows from the same design. Because the server is a process per client, your Redis connection string, and therefore your credentials, live in each client's configuration file. There is no broker in between to hold the secret. Teams that treat credential distribution as a solved problem will find this arrangement backwards.

When the right answer is a function call you wrote yourself

The obvious alternative is not another MCP server; it is redis-py behind a small set of functions you define. The difference is in who chooses the operation. With redis-mcp-redis, the model selects from the published tool list based on the conversation, which is the point when the task is open-ended and the user's phrasing is unpredictable. With hand-written wrappers, you decide the verbs in advance: cache_set, session_get, feed_append. The model can still call them, but it cannot reach a command you did not expose, and the argument schema is yours. That is a real advantage for anything touching production data, because a fixed verb list is a fixed blast radius. It also removes a dependency on the MCP protocol and on a server process that must be installed and versioned alongside your application. The cost is flexibility: every new capability is a code change and a redeploy, whereas adding a tool here is a matter of the upstream project shipping it. Choose the MCP server when the agent's Redis usage is exploratory and the key space is disposable. Choose your own wrappers when the agent's Redis usage is a known, narrow set of operations against data you cannot recreate.

Maintenance cost, version cadence and the MIT licence

The project is actively released: 0.5.1 in August 2026, 0.5.0 in March 2026, 0.4.1 in November 2025, with the repository's last push dated September 2026. That cadence implies you should pin a version rather than track latest. The README's own example pins redis-mcp-server@latest, which is convenient for trying the server and wrong for anything you depend on, since a minor bump can change tool names or argument shapes and silently break an agent's plans. Pin an explicit version in the uvx --from argument and upgrade deliberately. The Python requirement is stated as 3.14 or newer, which is aggressive; check that your environment and your MCP client's process launcher can satisfy it, because uvx will fetch a matching interpreter but a system Python install will not be upgraded for you. The licence is MIT, which is permissive and imposes no copyleft obligation on your own code. Nothing here is legal advice, and the licence file in the repository is the authority. One thing the supplied material does not cover is the project's stability policy for the tool interface, so treat tool names and argument schemas as unstable across minor versions until you find a statement otherwise.

Editorial conclusion

Adopt redis/mcp-redis when an MCP client needs to touch Redis primitives and you want the vendor's own tool definitions rather than a hand-rolled function-calling layer. Do not adopt it as a data-access layer for a conventional application, and do not expect streamable HTTP yet. Before wiring it into an agent, verify which Redis modules your target instance actually has loaded, because the vector and JSON tools depend on them, and confirm the --url string your client passes is not double-quoted the way the README example shows.

Official sources

1. License: MIT
2. Project website
3. README
4. redis/mcp-redis on GitHub
5. Releases