redis/mcp-redis: the official Redis MCP server, reviewed for adoption

What redis/mcp-redis is for, and who should run it

redis/mcp-redis is a Model Context Protocol server that gives an agent a set of tools for operating on Redis. The README frames it as a "natural language interface" for agentic applications, and lists the kinds of prompts it is meant to serve: storing a conversation in a stream, caching an item, storing a session with an expiration time, indexing and searching a vector.

The audience is narrow and specific. You need an MCP client already in place (the README names Claude Desktop, VS Code with GitHub Copilot, Augment and the OpenAI Agents SDK as integrations) and a Redis instance the server can reach. The server does not embed a model, does not do retrieval planning, and does not decide what to store. It translates tool calls into Redis commands. If your application already owns its key names, serialization format and eviction policy, this server is a second writer into the same keyspace, and that is a decision to make deliberately rather than by accident.

The project is published under the MIT licence and the package metadata classifies it as "Development Status :: 4 - Beta". That classification is in pyproject.toml, not in the README, and it is the honest signal about where the API surface sits.

The tool surface: one tool group per Redis data type

The mechanism is a flat set of tools, grouped by Redis data structure rather than by user task. The README lists string tools for set and get with expiration, hash tools for field-value pairs (and notes that a hash can store vector embeddings), list tools for append and pop, set tools for add, remove and list members, sorted set tools for score-ordered data, pub/sub tools that publish and create stateful channel or pattern subscriptions returning handles, stream tools that cover adding, reading, deleting, creating and destroying consumer groups and acknowledging entries, and JSON tools with path-based access.

Beyond the data types there are three more groups: a docs tool that searches Redis documentation through an HTTP API configured by MCP_DOCS_SEARCH_URL, query engine tools for managing vector indexes and running vector search, and a server management tool that reports information about the database.

That grouping matters for evaluation. The server is a command surface, so the agent's competence is bounded by how well it picks the right tool and the right key. Nothing in the tool list enforces a schema, a naming convention or a TTL policy. A prompt that says "cache this item" becomes a string write with whatever expiration the model chose, and the README's example prompts are exactly that loose.

The transport is stdio only. The README states that support for streamable HTTP "will be added in the future", so a client that cannot launch a local process is out of scope today.

Installing redis-mcp-server from PyPI and making a first call

The recommended path is the PyPI package redis-mcp-server, launched through uvx. The README gives this JSON configuration, which you paste into your MCP client's server configuration. uvx downloads the server if it is not cached, creates a temporary environment, and runs it. Note the escaped quotes around the URL inside args; that is how the README writes it.

{
  "mcpServers": {
    "RedisMCPServer": {
      "command": "uvx",
      "args": [
        "--from",
        "redis-mcp-server@latest",
        "redis-mcp-server",
        "--url",
        "\"redis://localhost:6379/0\""
      ]
    }
  }
}

The URL follows the redis or rediss URI scheme. The README gives redis://user:secret@localhost:6379/0?foo=bar&qux=baz as the general form, and redis://localhost:6379/0 as the localhost case, where the trailing 0 is the database index. After the client restarts, the server's tools should appear in the client's tool list; the README does not describe a separate health endpoint to poll.

If you prefer configuration through the environment rather than the command line, the repository ships .env.example, which the server loads via python-dotenv. The keys are REDIS_HOST, REDIS_PORT, REDIS_DB, REDIS_USERNAME, REDIS_PWD, REDIS_SSL, REDIS_SSL_CA_PATH, REDIS_SSL_KEYFILE, REDIS_SSL_CERTFILE, REDIS_SSL_CERT_REQS, REDIS_SSL_CA_CERTS and REDIS_CLUSTER_MODE.

REDIS_HOST=your_redis_host
REDIS_PORT=6379
REDIS_DB=0
REDIS_USERNAME=default
REDIS_PWD=your_password
REDIS_SSL=False
REDIS_CLUSTER_MODE=False

There is also a Docker image published as mcp/redis. The Dockerfile builds from python:3.14-slim, installs uv, copies the repository and runs uv sync --locked, then starts the server with uv run python src/main.py. Running the image means the client config points at a docker command with the same --url argument rather than at uvx. The README does not document a rollback procedure for a bad write performed through the tools, which is worth knowing before you point it at a database you care about.

Configuration, ACLs and the EntraID path for Azure Managed Redis

Two configuration routes exist and they overlap: command line arguments such as --url, and environment variables from .env.example. The README documents a Redis ACL section, which is the right place to start. Because the server exposes deletion tools (stream entries can be deleted and consumer groups destroyed, set members removed, list items popped), the credential you hand it defines the blast radius. A user with a key pattern limited to a working prefix is a materially different risk posture from the default user.

For Azure Managed Redis, the project depends on redis-entraid>=1.0.0 and the README documents EntraID authentication natively. That is the one configuration area where this server does something a hand-rolled script would have to build itself, and it is a fair reason to prefer it over a generic Redis client wrapper if you are on Azure.

TLS is configured through the REDIS_SSL family of variables, including a CA path, client key and certificate files, and REDIS_SSL_CERT_REQS defaulting to required in the example file. REDIS_CLUSTER_MODE is a boolean. The README also has a Logging section; the .env.example file does not list a log level variable, so check the README's logging section rather than assuming an environment variable name.

Where redis/mcp-redis is the wrong tool

The most common failure mode is treating it as a Redis client for production code. It is not. It is a process that a model drives, and the model chooses keys, values and expirations. Any workflow that needs deterministic key construction, atomic multi-key transactions, or a fixed serialization contract belongs in application code, with the agent calling your code instead.

The second limit is transport. stdio only means one server process per client, started locally. If your MCP client runs remotely, or your deployment model is a long-lived HTTP service that many clients connect to, the README says streamable HTTP support is planned rather than present. You cannot bridge that gap with configuration.

The third is prompt surface. The README's own examples ("Cache this item", "Store the session with an expiration time") are underspecified: no key, no TTL, no value shape. An agent given those instructions will invent them. If your Redis instance is shared with other services, an invented key prefix is a real operational problem, and the server has no allowlist mechanism described in the README to prevent it.

Finally, the project is self-classified as Beta. The version history shows 0.5.1 in August 2026, 0.5.0 in March 2026 and 0.4.1 in November 2025, so the minor version has moved twice in under a year. Pin the version you test against rather than tracking @latest in a shared configuration.

How it compares to writing your own MCP server over redis-py

The realistic alternative is not another Redis MCP server; it is a small MCP server you write yourself against redis-py. The dependency list here is mcp[cli]>=1.26.0,<2, redis>=6.0.0, python-dotenv, numpy, click, aiohttp and redis-entraid. A hand-written server would need mcp[cli] and redis, and then whatever else your tools require.

The difference in approach is scope versus control. redis/mcp-redis gives you roughly a dozen tool groups covering every major Redis data type plus vector search, pub/sub and consumer groups, on day one, with an official Redis-maintained implementation and a docs-search tool wired to an HTTP endpoint. Writing your own gives you three or four tools with names and schemas that match your domain ("record_agent_decision", "fetch_customer_profile") and hard-coded key prefixes, TTLs and validation.

For a prototype or an internal assistant over a scratch Redis instance, the official server wins on time to first call. For anything where the agent writes into keys that other services read, the hand-written server wins, because the constraint you need is not a Redis data type, it is your schema. A middle path is to run redis/mcp-redis against a dedicated database index (the /0 or /1 in the URL) so its invented keys cannot collide with application data.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-02, so the project is receiving commits. The release cadence visible in the metadata is roughly one minor release every four to five months, with 0.5.1 in August 2026 as the most recent. Nothing in the README describes a deprecation policy or a compatibility guarantee between minor versions, and the Beta classifier in pyproject.toml is consistent with that absence.

The practical upgrade cost is low if you pin. The server is a single process launched per client, so upgrading means changing a version string in the client configuration and restarting the client. The risk is not the upgrade itself but the tool surface changing underneath a prompt or an agent instruction that referenced a specific tool name. Because the tools are grouped by Redis data type, a rename in, say, the stream group would break agent instructions that mention it.

The licence is MIT, declared both in the repository LICENSE file and in pyproject.toml, with the author listed as Redis and the contact [email protected]. MIT is permissive and imposes no copyleft obligation on your own code. It also carries no warranty, which is standard, and it is not legal advice: if you redistribute the server inside a product, read the LICENSE file in the repository rather than this summary.

Editorial conclusion

Adopt redis/mcp-redis if you already run Redis and want an MCP client such as Claude Desktop, VS Code with GitHub Copilot or the OpenAI Agents SDK to read and write that data through tool calls, and you are comfortable that the package is classified as Beta and currently speaks only the stdio transport. Do not adopt it as a general Redis administration surface, as a replacement for application code that owns its own key schema, or behind a client that only supports streamable HTTP. Before wiring it into anything shared, verify three things: the Redis ACL you grant the server, the exact URL form you pass to --url including the database index, and whether your client resolves uvx on PATH or needs the Docker image instead.

Frequently asked questions

Official sources

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