Summary: According to the provided schema—which is much broader than the README’s three-tool design—this Redis MCP server lets clients inspect and manipulate Redis data, manage connections, and configure a command blacklist.
Execute arbitrary Redis commands, with dangerous commands checked against a blacklist.
Run read-only Redis queries and inspect keys by name, type, TTL, encoding, and value, or list keys by pattern.
Read/write strings, hashes, lists, sets, and sorted sets; delete/rename keys; and manage TTLs.
Select databases and report database size, server information, and current connection details.
Create, list, test, switch, and delete saved Redis connection configurations.
View, update, and reset the command blacklist configuration.
Provides tools for connecting to any Redis instance and executing a wide range of Redis commands, including string, hash, list, set, and sorted set operations, as well as key management and database administration.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Redis MCP Server get the value of key 'user:123'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Redis that keeps every command honest about where it runs and what it is allowed to do there. Three tools, an environment tag on every connection, and a web console for everything that does not belong in a chat.
Every command an agent sends lands in a specific Redis instance — a development cache it is free to flush, or the one a running service depends on. This server makes that context part of the protocol:
Where am I? Every connection carries a test or prod tag, and every tool response reports it.
What am I allowed to do here? Four permission switches per tag — write, delete, admin, dangerous — enforced before the command reaches Redis. Reads are never gated.
What about commands that are unsafe no matter where they run? A small deny list that no template can unlock, plus a hard cap on how much a single call can return.
The parts that do not belong in a chat — connection management, permission templates, a command console, and a live view of what the server exposes — live in a web console.
Three focused tools — redis_query, redis_execute, redis_context. Reads, gated writes, and context switching. Nothing else is exposed.
Environment tags — every connection is test or prod; production ships read-only by default.
Command classification — every command is parsed into an argv and sorted into read / write / delete / admin / dangerous, and that category decides how it is handled before anything reaches Redis.
Self-describing responses — every result says which connection and environment produced it, and how much was truncated.
Bounded output — results are capped at 200 items by default, limit goes up to 2000, so a wide SCAN or LRANGE cannot blow up a context window.
Always-denied commands — KEYS, subscriptions, transaction blocks, and MONITOR are refused with a reason and an alternative.
Web console — connection CRUD, permission templates, a command tester, and the live policy in four tabs. Chinese / English switch included.
Password encryption — saved passwords are AES-256-GCM encrypted with a per-installation key.
git clone https://github.com/minivv/redis-mcp-server.git
cd redis-mcp-server
npm install
npm run build
node build/index.jsThe server speaks MCP over stdio and starts a web console on http://localhost:3457.
{
"mcpServers": {
"redis": {
"command": "node",
"args": ["/absolute/path/to/redis-mcp-server/build/index.js"],
"env": {
"REDIS_HOST": "127.0.0.1",
"REDIS_PORT": "6379",
"REDIS_ENV": "test"
}
}
}
}Any connection you add through the web console is available to the MCP process immediately — no restart. The MCP process re-reads ~/.redis-mcp/connections.json on every call and reconnects when the active connection, its credentials, its database, or its environment tag changes.
redis_queryRead-only channel.
{ "command": "SCAN 0 MATCH user:* COUNT 50", "limit": 100 }A command that is not read-only is rejected here with the note to use redis_execute instead — the tool tells you the category it was classified into.
{
"connection": "cache-dev",
"env": "test",
"envLabel": "测试库",
"readOnly": false,
"allowedOps": ["write", "delete", "admin"],
"database": 2,
"command": "SCAN",
"operation": null,
"count": 3,
"truncated": false,
"maxItems": 200,
"result": ["4", ["user:42", "user:43", "user:44"]]
}redis_executeWrite, delete, admin, and dangerous commands — gated by the active connection's environment template.
{ "command": "SET session:42 active" }{
"connection": "cache-prod",
"env": "prod",
"envLabel": "正式库",
"readOnly": true,
"allowedOps": [],
"database": 0,
"command": "SET",
"operation": "write",
"result": "OK"
}When the template does not allow it, the call fails with an explanation instead of reaching Redis:
正式库（env=prod）不允许 写入（SET / HSET / LPUSH / ZADD / RENAME 等） 操作，已拦截命令 "SET"。
如需放开，请到 Web UI 的「权限配置」中调整该标识对应的模板。redis_contextLook around, switch database, or switch connection.
{}{
"connection": "cache-dev",
"env": "test",
"envLabel": "测试库",
"readOnly": false,
"allowedOps": ["write", "delete", "admin"],
"host": "127.0.0.1",
"port": 6379,
"database": 2,
"databases": 16,
"savedConnections": [
{ "name": "cache-dev", "host": "127.0.0.1", "port": 6379, "db": 2, "env": "test" }
]
}{ "database": 0 } — switch the database index (the count comes from the instance's databases config, not a hardcoded 0–15).
{ "connection": "cache-dev" } — switch to a saved connection and reconnect. The environment tag travels with the connection, and only the calling MCP process is affected.
Tab | What it does |
Connections | Add, edit, rename, test, activate, delete. Each card shows the host, database, and environment badge. |
Permissions | Two templates (test / prod) × four switches. Change a template once and every connection with that tag follows. |
Query | Run one command per line and see every result. Same validation as a tool call. |
Tools & Policy | The three tool signatures, the operation categories, the deny list, and the result limits, read live from the server. |
Permissions are bound to the environment tag, not to a single connection.
Category | Example commands |
|
|
read |
| always | always |
write |
| on | off |
delete |
| on | off |
admin |
| on | off |
dangerous |
| off | off |
dangerous is off even in test: a wiped development cache still costs someone an afternoon.
These are refused regardless of template, because they are unsafe in a one-command-per-call protocol:
Command | Why |
| Blocks the event loop. Use |
| Puts the shared connection into subscriber mode, after which ordinary commands fail. |
| The server issues one command per call; a half-open transaction would poison the connection. |
| Never appropriate for a tool call — use the connection settings instead. |
File | Contents |
| Saved connections, each with |
| The two permission templates. Created on first run. |
| AES-256-GCM key for saved passwords (mode |
All three are written atomically: a temporary file replaces the old one, so an interrupted write leaves the previous configuration intact.
Variable | Default | Purpose |
|
| Host for the fallback connection. |
|
| Port. |
| — | Password. |
| — | ACL username. |
|
| Database index. |
|
| Enable TLS. |
|
| Environment tag for the fallback connection. Unknown values are treated as |
|
| Web console port. |
|
| Open the console in a browser on start. |
Read the environment matrix as a safety rail, not a sandbox. The real boundary is Redis ACLs: give the account it uses only the commands it needs.
The deny list is enforced in code and is not configurable through any tool.
A second MCP instance started while the console port is taken still works — it prints a notice and keeps following the active connection from the config file.
Passwords are encrypted at rest; tool responses never contain credentials.
npm run dev # build and run
npm run build # type-check and emit to build/The whole server lives in src/index.ts: command classification, permission model, MCP tool handlers, HTTP API, and the embedded console.
MIT
Related MCP server: Redis MCP Server
agent 发出的每一条命令都落在某个具体的 Redis 上——它可以随手清空的开发缓存，或者线上服务正在依赖的那一个。这个服务把「在哪儿」变成协议的一部分：
我在哪？ 每个连接带 test / prod 标识，每次工具返回都会报出当前所处环境。
这里允许我做什么？ 每个标识四项权限开关——写入、删除、管理、高危——在命令到达 Redis 之前就拦下。只读命令永远不受限制。
有些命令在哪跑都不该允许，怎么办？ 一份任何模板都解不开的拒绝清单，加上单次调用结果的硬性上限。
不适合塞进对话里的东西——连接管理、权限模板、命令控制台、当前到底暴露了什么——都放在 Web 控制台里。
三个聚焦的工具 —— redis_query、redis_execute、redis_context，分别是只读通道、受门控的写入通道、上下文切换。除此之外不暴露任何入口。
环境标识 —— 每个连接都是 test 或 prod，正式库默认只读。
按命令归类 —— 每条命令先解析成 argv，判定为 read / write / delete / admin / dangerous，再由这个类别决定怎么处理，然后才发往 Redis。
自描述的返回 —— 每次结果都说明是哪个连接、哪个环境、截断了多少。
结果有上限 —— 默认最多 200 项，limit 上限 2000，SCAN、LRANGE 不会撑爆上下文。
始终拒绝的命令 —— KEYS、订阅、事务块、MONITOR 会被拒绝，并给出原因和替代方案。
Web 控制台 —— 连接增删改、权限模板、命令测试、实时策略，四个标签页，中英切换。
密码加密 —— 保存的密码用每套安装独立的密钥做 AES-256-GCM 加密。
git clone https://github.com/minivv/redis-mcp-server.git
cd redis-mcp-server
npm install
npm run build
node build/index.js服务通过 stdio 提供 MCP，同时在 http://localhost:3457 启动 Web 控制台。
{
"mcpServers": {
"redis": {
"command": "node",
"args": ["/绝对路径/redis-mcp-server/build/index.js"],
"env": {
"REDIS_HOST": "127.0.0.1",
"REDIS_PORT": "6379",
"REDIS_ENV": "test"
}
}
}
}在 Web 控制台里新建的连接对 MCP 进程立即可用，不用重启。MCP 进程每次调用都会重新读取 ~/.redis-mcp/connections.json，当激活连接、账号密码、库序号或环境标识发生变化时自动重连。
redis_query只读通道。
{ "command": "SCAN 0 MATCH user:* COUNT 50", "limit": 100 }非只读命令会在这里被拒绝，并提示改用 redis_execute，同时告诉你它被归到了哪一类。
{
"connection": "cache-dev",
"env": "test",
"envLabel": "测试库",
"readOnly": false,
"allowedOps": ["write", "delete", "admin"],
"database": 2,
"command": "SCAN",
"operation": null,
"count": 3,
"truncated": false,
"maxItems": 200,
"result": ["4", ["user:42", "user:43", "user:44"]]
}redis_execute写入、删除、管理、高危命令——受当前连接的环境模板门控。
{ "command": "SET session:42 active" }模板不允许时，调用直接失败并说明原因，命令不会到达 Redis：
正式库（env=prod）不允许 写入（SET / HSET / LPUSH / ZADD / RENAME 等） 操作，已拦截命令 "SET"。
如需放开，请到 Web UI 的「权限配置」中调整该标识对应的模板。redis_context查看上下文、切库、切换连接。
不带参数：返回当前连接、环境标识、库序号、该环境放行的操作类别、已保存连接列表。
{ "database": 0 }：切换库序号（范围取自实例的 databases 配置，不是写死的 0–15）。
{ "connection": "cache-dev" }：切换到已保存的连接并重连。环境标识跟着连接走，且只影响当前 MCP 进程。
标签页 | 用途 |
连接管理 | 新增、编辑、重命名、测试、激活、删除。卡片上直接显示地址、库序号和环境徽章。 |
权限配置 | 测试库 / 正式库两套模板 × 四项开关。改一次模板，所有使用该标识的连接立即生效。 |
查询测试 | 一行一条命令，逐条显示结果。校验规则与工具调用完全一致。 |
工具与策略 | 三个工具的参数、操作类别、拒绝清单、结果上限，全部从服务端实时读取。 |
权限绑在环境标识上，不是绑在单个连接上。
类别 | 示例命令 |
|
|
读取 |
| 总是允许 | 总是允许 |
写入 |
| 开 | 关 |
删除 |
| 开 | 关 |
管理 |
| 开 | 关 |
高危 |
| 关 | 关 |
高危 在测试库也默认关闭：清掉一个开发缓存，同样会让人搭进去一下午。
无论模板怎么配，这些命令都会被拒绝，因为它们在「一次调用一条命令」的协议里本身就不安全：
命令 | 原因 |
| 阻塞 Redis 主线程。改用 |
| 会把共享连接切进订阅模式，之后的普通命令都会失败。 |
| 服务一次调用只发一条命令，半开的事务会污染连接。 |
| 不适合出现在工具调用里，请改用连接配置。 |
文件 | 内容 |
| 已保存的连接（每个都带 |
| 两套权限模板，首次运行自动创建。 |
| 保存密码用的 AES-256-GCM 密钥（权限 |
三者都是原子写入——临时文件直接替换旧文件，写到一半中断也不会损坏原有配置。
变量 | 默认值 | 用途 |
|
| 兜底连接的主机。 |
|
| 端口。 |
| — | 密码。 |
| — | ACL 用户名。 |
|
| 库序号。 |
|
| 启用 TLS。 |
|
| 兜底连接的环境标识，无法识别的值一律按 |
|
| Web 控制台端口。 |
|
| 启动时自动打开浏览器。 |
把环境矩阵当成安全带，不是沙箱。真正的边界是 Redis ACL：给这个账号只发它需要的命令。
拒绝清单写死在代码里，任何工具都改不了。
控制台端口被占用时再启动一个实例仍然可用：它会打印提示，并继续跟随配置文件里的激活连接。
密码加密存储，工具返回里不会出现凭据。
npm run dev # 构建并运行
npm run build # 类型检查并输出到 build/整个服务都在 src/index.ts 里：命令归类、权限模型、MCP 工具处理、HTTP API、以及内嵌的控制台。
MIT
查看或切换上下文。不带参数：返回当前连接、环境标识、库序号、该环境放行的操作类别、已保存连接列表。传 database：切换到指定库序号（范围取自实例的 databases 配置）。传 connection：切换到已保存的连接并重新建连。切换只会影响当前 MCP 进程，不会改变连接的环境标识。
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | 要切换到的库序号，从 0 开始 | |
| connection | No | 要切换到的已保存连接名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that switching is scoped to the current MCP process only, does not alter the connection's environment identifier, and that switching connection triggers a reconnect. It does not state permission requirements for switching or failure behavior for an out-of-range database index.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short clauses, front-loaded with the no-argument behavior, then one clause per parameter, then a trailing constraint on scope. No filler and no repetition of schema text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating what the inspection mode returns, plus the side-effect scope of switching. Remaining gaps are edge cases: combined parameters, invalid index handling, and whether subsequent redis_query calls inherit the new database.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real semantics: the database index range is bounded by the instance's databases configuration, and passing connection causes a reconnect rather than a lazy switch. It does not address what happens if both parameters are supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource: inspect or switch the Redis context, with an explicit breakdown of what the no-argument mode returns (current connection, environment id, db index, permitted operation categories, saved connections). It is clearly distinguishable from redis_query/redis_execute by content, though it never names those siblings to reinforce the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes between the tool's own three modes (no args / database / connection) clearly, which is useful. But it gives no guidance on when an agent should call this instead of redis_query or redis_execute, or on whether switching is a prerequisite for those tools — usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行写入 / 删除 / 管理 / 高危命令（SET / HSET / DEL / EXPIRE / CONFIG / FLUSHALL 等）。这些命令会按当前连接的环境标识（测试库 / 正式库）对应的权限模板逐类校验，被禁类别在命令下发前就被拦下。返回包含 connection / env / envLabel / readOnly / allowedOps / operation / result。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回条目上限，默认 200，最大 2000 | |
| command | Yes | Redis 命令，如 'SET key value EX 60'、'HSET hash f v'、'DEL key1 key2' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that commands are validated against an env-specific permission template and that forbidden categories are blocked before dispatch. It also enumerates the return fields including readOnly and allowedOps, giving the agent strong operational context, though it doesn't detail reversibility of individual destructive commands beyond the high-risk label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: purpose and examples first, then the permission-validation behavior, then return shape. No wasted text and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description covers the key behavioral risks (permission gating, blocked categories) and lists the return fields, leaving only per-command reversibility unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds value by showing concrete command-string syntax examples ('SET key value EX 60', 'HSET hash f v') that map to the command param, and the limit default is already documented in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb set (write/delete/manage/high-risk) and resource (Redis commands) with concrete examples (SET/HSET/DEL/FLUSHALL). The mutating scope implicitly contrasts with the redis_query sibling, but the alternative is never named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the command categories – use this for writes/management rather than reads – but there is no explicit 'when to use vs redis_query' statement or prerequisite guidance beyond the general permission-template note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行只读 Redis 命令（GET / HGETALL / LRANGE / SMEMBERS / SCAN / INFO 等）。服务端按命令本身判定是否只读，写命令会被拒绝并提示改用 redis_execute。结果按 limit 截断。返回包含 connection / env / envLabel / readOnly / allowedOps / count / truncated / result。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回条目上限，默认 200，最大 2000 | |
| command | Yes | Redis 命令，如 'GET user:1'、'HGETALL session:abc'、'SCAN 0 MATCH user:* COUNT 100' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses read-only enforcement, rejection behavior for writes, limit-based truncation, and the full return envelope (connection/env/envLabel/readOnly/allowedOps/count/truncated/result). It stops short of describing authentication, connection selection, or rate-limit behavior, which is the only gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: the first states scope with examples, the second addresses write rejection and the fallback tool, and the third covers truncation and the return shape. Nothing is redundant and the most important routing rule is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely sufficient because, despite having no output schema, it enumerates the fields in the return value and explains limit truncation. The one unresolved point is how the connection or env is selected, because there is no corresponding input parameter, though redis_context may supply this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3. The description adds genuine value by stating that results are truncated according to limit, which clarifies limit's runtime effect beyond its schema text ('default 200, max 2000'), and the command examples reinforce the command parameter's expected syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('执行只读 Redis 命令') and lists allowed command families (GET/HGETALL/LRANGE/SMEMBERS/SCAN/INFO), so it is indistinguishable from the sibling redis_execute only by its read-only scope, which it explicitly states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the server rejects write commands and directs the agent to use redis_execute instead, which is an explicit when-not rule and a named alternative. This is exactly the routing guidance an agent needs when choosing between the two siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0add_setadd_sorted_setdelete_connectiondelete_keyexecute_commandget_command_blacklistget_connection_infoget_database_sizeget_hashget_key_infoget_listget_server_infoget_setget_sorted_setget_stringget_ttllist_keyslist_saved_connectionspush_listredis_contextredis_executeredis_queryrename_keyreset_command_blacklistrun_redis_querysave_connectionselect_databaseset_hashset_stringset_ttltest_connectionupdate_command_blacklistuse_connectionv1.0.0add_setadd_sorted_setdelete_connectiondelete_keyexecute_commandget_command_blacklistget_connection_infoget_database_sizeget_hashget_key_infoget_listget_server_infoget_setget_sorted_setget_stringget_ttllist_keyslist_saved_connectionspush_listrename_keyreset_command_blacklistrun_redis_querysave_connectionselect_databaseset_hashset_stringset_ttltest_connectionupdate_command_blacklistuse_connectionScored across 3 tools
The three tools have clearly distinct roles: redis_query is strictly read-only, redis_execute handles writes/deletes/admin/high-risk commands, and redis_context manages connection/database context. Boundary is reinforced by server-side read-only enforcement and rejection messages directing callers to the right tool.
All tools use the redis_ prefix and are readable, giving a predictable grouping. However, query and execute are verbs while context is a noun, so the convention is slightly mixed but still intuitive.
Three tools are well-scoped for a Redis MCP server: read, write/admin, and context management cover the main interaction modes without redundancy. Each tool earns its place and there is no obvious tool bloat.
The surface covers read-only queries, write/admin commands, and context switching/listing, which are the core Redis operations an agent needs. Minor gaps exist around saved-connection lifecycle management (create/delete saved connections) and possibly transaction/pipeline workflows, but agents can work around these.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for AI dialogue using various LLM models via AceDataCloud
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
