Skip to main content
Glama
YawLabs

redis-mcp

by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

redis_command

Destructive

Execute a Redis command through a safety gate that permits read-only operations by default, requires explicit write permission for mutating commands, and blocks dangerous or arbitrary execution commands.

Instructions

Run a single Redis command through the safety gate. Read-only commands (GET, HGETALL, LRANGE, TYPE, TTL, INFO, ...) always run. Mutating commands (SET, DEL, EXPIRE, HSET, ...) require ALLOW_WRITES=1. KEYS is blocked (use redis_scan). Arbitrary-execution commands (EVAL, FUNCTION, SCRIPT, MULTI, MONITOR, SHUTDOWN, CLUSTER, ...) are never exposed, even with ALLOW_WRITES=1 -- the gate is a curated allowlist, not a blanket 'anything when writes are on'. Use this for commands without a dedicated tool; prefer the typed tools (redis_get, redis_scan, redis_key_info) where they exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNoCommand arguments in order. For multi-word commands, the subcommand is the first arg.
commandYesThe Redis command verb (e.g. `GET`, `HGETALL`, `INFO`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.1
    • removedInput schema / properties / args / items / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / args / items / type
      Added value: +[
+  "string",
+  "number"
+]
  2. First observedv0.1.3

TDQS

A4.6/5.0
Behavior5/5

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

The description substantially expands on the annotations by explaining the safety-gate model: read-only commands always run, mutating commands require ALLOW_WRITES=1, and arbitrary-execution commands are never exposed even with writes enabled. It also calls out that the gate is a curated allowlist, which is far richer than the bare destructiveHint=true annotation.

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

Conciseness5/5

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

Though lengthy, every sentence carries operational weight: purpose, safety rules, blocked commands, and alternative tools are all covered without repetition. The most important scoping information is front-loaded before the alternatives.

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

Completeness4/5

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

For a generic command gateway, the description is remarkably complete: it covers how to invoke, what is safe, what is blocked, and when to use sibling tools. The only missing detail is a note about the return shape or error behavior when a command is denied, but with no output schema and highly variable Redis replies, this is a minor gap.

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

Parameters3/5

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

Schema description coverage is 100%, with both `command` and `args` already documented, including the subcommand-as-first-arg rule. The description adds useful command-family examples but does not add new parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.

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 description opens with 'Run a single Redis command through the safety gate,' a specific verb and resource that immediately defines the tool's role. It also distinguishes itself from siblings by explicitly naming redis_get, redis_scan, and redis_key_info as the preferred typed tools and by noting KEYS is blocked in favor of redis_scan.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: 'Use this for commands without a dedicated tool; prefer the typed tools...'. It also states the ALLOW_WRITES=1 requirement for mutating commands and that KEYS should go through redis_scan, leaving no ambiguity about alternatives.

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