Skip to main content
Glama
Sign In
mcp-server-redis

mcp-server-redis

by atengk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

redis_execute_command

Execute native Redis commands or pipeline batches (up to 20) safely, with built-in blocking and destructive command protections.

Instructions

执行单行原生 Redis 命令或多命令管道批处理（核心命令网关）。

支持单行原生 Redis 语法与标准引号分词（如 'GET key', 'SET key "hello world"'）。 支持通过 'commands' 传入命令列表执行管道批处理（上限 20 条），在单一网络往返中批量极速执行。 内置破坏性指令物理阻断（FLUSHALL/KEYS 等）、Fail-Close 阶梯写门禁与高危删除二次确认保护。 自动对阻塞式读取指令（BLPOP/BRPOP 等）的安全超时进行收敛改写，彻底杜绝服务假死。 针对 HGETALL/SMEMBERS/LRANGE/ZRANGE 等无界全量读取执行 O(1) 探查预检，防止 Redis 单线程锁死。 大集合返回结果自动安全切片截断（上限 100 项），防止客户端内存溢出与上下文爆炸。

提示：在生产环境中读取大型 Hash/Set/ZSet 数据时，推荐优先使用 HSCAN/SSCAN/ZSCAN 等渐进式切片命令， 避免使用 HGETALL/SMEMBERS 等全量 O(N) 命令阻塞 Redis 单线程主循环。

Args: command: 原生 Redis 命令行字符串（如 'GET user:1001'，与 commands 二选一） commands: 原生 Redis 命令行列表（用于单往返管道批处理执行，上限 20 条） connection: 目标连接别名（可选，当前系统仅配置单连接 'default'，缺省直接使用） db: 逻辑库编号（可选，0~15，集群模式下忽略并绑定 db=0） confirm: 是否确认执行高危删除操作（仅对 DEL/UNLINK 命令生效，未确认时返回待确认详情）

Returns: dict[str, Any]: 统一信封结果字典，包含 command, result, data_type, is_truncated 等元数据

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "redis_execute_command"
  }
}

Input Schema

NameRequiredDescriptionDefault
dbNo
commandNo
confirmNo
commandsNo
connectionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so richly: physical blocking of destructive commands (FLUSHALL/KEYS), a fail-close write gate, second-confirmation for high-risk deletes, automatic timeout rewriting for blocking reads (BLPOP/BRPOP), O(1) prechecks for unbounded reads, and result truncation at 100 items. Each of these is a non-obvious runtime behavior an agent needs in order to predict outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and scope are front-loaded, and the bullet list of safety behaviors is scannable rather than a wall of prose. It is on the verbose side — the production HSCAN tip and the closing Returns note both overlap material covered elsewhere — but almost every line still carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter, zero-annotation, side-effecting gateway tool, the description covers intent, argument semantics, safety gating, timeout/truncation side effects, and even outlines the return envelope, which the output schema also fully specifies. An agent has everything needed to call it correctly and anticipate edge-case responses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it does: it explains that 'command' and 'commands' are mutually exclusive, caps the pipeline at 20, notes 'connection' is effectively fixed to 'default', states db's 0–15 range and its silent binding to 0 in cluster mode, and confines 'confirm' to DEL/UNLINK with a pending-confirmation return when omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource — executing single-line raw Redis commands or a pipelined batch — and labels itself the 'core command gateway', which cleanly separates it from the read-oriented siblings (inspect_key, scan_keys, list_connections). An agent can tell what this tool is for without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage direction: use 'commands' for single-round-trip batch execution (max 20), and prefer HSCAN/SSCAN/ZSCAN over HGETALL/SMEMBERS for large Hash/Set/ZSet reads in production. It stops short of explicit routing against siblings (e.g., when to prefer redis_inspect_key instead of a raw command), so it is clear context without full alternative coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools