Which integrations are available for this server?

Provides read-first exploration, diagnostics, and health checks for Redis instances, including key scanning, value retrieval, and advisory analysis, with optional write support. Supports connecting to Upstash managed Redis via rediss:// URLs with TLS, including options for disabling certificate verification when needed.

How do I use redis-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@redis-mcp scan for keys matching session:*" 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.

redis-mcp

by YawLabs

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@yawlabs/redis-mcp

npm version License: MIT

Explore and diagnose a Redis instance from Claude Code, Cursor, and any MCP client. Read-only by default - writes opt in via a single env var - and key enumeration always uses SCAN, never the O(N) KEYS, so it is safe to point at a production instance with millions of keys.

Built and maintained by Yaw Labs.

One click adds this to your local Yaw MCP config so it's available in every Yaw Terminal session. Or install manually below.

Why this one?

SCAN, never KEYS. Every key-enumeration path uses cursor-based SCAN with a bounded COUNT and an iteration cap. KEYS * is O(N) over the entire keyspace and blocks Redis's single-threaded event loop for the full scan - a self-inflicted outage on a large instance. SCAN yields between batches. See Security.
Read-first command gate. Tools run a curated read-only command allowlist by default. Mutating commands (SET, DEL, EXPIRE, HSET, ...) require ALLOW_WRITES=1. Arbitrary-execution commands (EVAL, FUNCTION, SCRIPT, MULTI, MONITOR, SHUTDOWN, CLUSTER, ...) are never exposed, even with writes on - the gate is a curated allowlist, not "anything when writes are enabled".
Type-aware reads without surprises. redis_get dispatches by value type (string / hash / list / set / zset / stream) and windows collection reads to a cap, so a million-element list can't blow out the model context. redis_key_info reads type / TTL / encoding / memory footprint without pulling the value at all.
Health in one call. redis_health rolls up INFO + DBSIZE + recent SLOWLOG into memory pressure, eviction policy, hit rate, ops/sec, persistence status, replication role, per-database key counts (and how many lack a TTL), and the most recent slow commands.
A real advisor. redis_advisor is the "what should I be looking at?" lint pass: big keys, missing TTLs, eviction pressure (including the dangerous noeviction + no-TTL combination), and fork-latency risk - each with a severity and an actionable fix. Keys are SCAN-sampled, so it is safe on a large instance.
Instant startup. Ships as a single bundled file with zero runtime dependencies. No multi-minute node_modules install on every npx cold start.

Related MCP server: mcp-opensearch

Scope

This server is a read-first explorer and diagnostician, not a general Redis admin console. It deliberately does not expose EVAL/FUNCTION/SCRIPT, pub/sub, MONITOR, cluster management, or replication control. For those, use redis-cli directly. The goal here is the safe, common 90%: "what's in this instance, is it healthy, and what should I worry about?" - the questions an agent should be able to answer against a production Redis without risk.

Works against Redis 6+ and Valkey. A few redis_health fields (latest_fork_usec, aof_enabled) depend on the running server exposing them in INFO; missing fields surface as null rather than erroring.

Quick start

1. Create .mcp.json in your project root

macOS / Linux / WSL:

{
  "mcpServers": {
    "redis": {
      "command": "npx",
      "args": ["-y", "@yawlabs/redis-mcp@latest"],
      "env": {
        "REDIS_URL": "redis://:password@host:6379/0"
      }
    }
  }
}

Windows:

{
  "mcpServers": {
    "redis": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@yawlabs/redis-mcp@latest"],
      "env": {
        "REDIS_URL": "redis://:password@host:6379/0"
      }
    }
  }
}

Why the extra step on Windows? Since Node 20, child_process.spawn cannot directly execute .cmd files (that's what npx is on Windows). Wrapping with cmd /c is the standard workaround.

2. Restart and approve

Restart Claude Code (or your MCP client) and approve the redis MCP server when prompted.

3. (Optional) Enable writes

Read-only is the default. To let the agent run mutating commands (SET, DEL, EXPIRE, HSET, ...) via redis_command, add ALLOW_WRITES=1:

"env": {
  "REDIS_URL": "redis://...",
  "ALLOW_WRITES": "1"
}

Prefer scoping this to dev/test instances. Even with writes on, arbitrary-execution commands stay blocked.

Security

SCAN, not KEYS - this is the load-bearing choice. Redis is single-threaded. KEYS pattern walks the entire keyspace in one uninterruptible operation; on an instance with millions of keys it blocks every other client for the duration - effectively a denial of service you triggered yourself. Every key-enumeration path in this server (redis_scan, the advisor's key sampling, redis_get's set reads) uses cursor-based SCAN/SSCAN with a bounded COUNT and a hard iteration cap, which yields the event loop between batches. KEYS is explicitly rejected by the command gate with a nudge to redis_scan.

Read-only by default. Without ALLOW_WRITES=1, only commands on the read-only allowlist run; everything else is rejected before it reaches Redis. With ALLOW_WRITES=1, a curated set of mutating commands is additionally permitted - but arbitrary-execution commands (EVAL, FUNCTION, SCRIPT, MULTI/EXEC, MONITOR, SHUTDOWN, REPLICAOF, CLUSTER, MIGRATE, ...) remain blocked in all modes. The gate is fail-closed: a command on neither allowlist is rejected, so a command we never anticipated can't slip through.

Use Redis ACLs as the primary control. As with a database role, the cleanest posture is a least-privileged Redis user (ACL SETUSER mcp on >pass ~* +@read) in REDIS_URL. Redis then enforces the boundary server-side, independent of this server's gate. ALLOW_WRITES is defense-in-depth on top of that.

See SECURITY.md for vulnerability reporting.

Tools

Tool	Description
`redis_scan`	Enumerate keys with cursor-based `SCAN` (never `KEYS`). Optional glob `match`, value-`type` filter, and resumable `cursor`. Capped at `REDIS_MAX_KEYS`.
`redis_key_info`	Inspect one key without reading its value: type, TTL (s/ms), encoding, memory footprint, idle time. The big-key / missing-TTL probe.
`redis_get`	Read a key's value, dispatching by type (string / hash / list / set / zset / stream). Collection reads windowed by `limit`. Always read-only.
`redis_command`	Run a single Redis command through the safety gate. Reads always run; writes need `ALLOW_WRITES=1`; `KEYS` and arbitrary-execution commands are blocked. The escape hatch for commands without a dedicated tool.
`redis_health`	One-call health snapshot from `INFO` + `DBSIZE` + `SLOWLOG`: memory pressure, eviction policy, hit rate, ops/sec, persistence, replication role, per-db key counts, recent slow commands.
`redis_slowlog`	Recent entries from the Redis slow log - command, microseconds, timestamp, client. Read-only (`SLOWLOG GET`).
`redis_advisor`	Rolled-up health lints in one call: big keys, missing TTLs, eviction pressure, fork-latency risk. Each finding has a severity and a fix. SCAN-sampled, safe on large instances.

Configuration

All env vars are read from the MCP server's environment:

Variable	Default	Purpose
`REDIS_URL`	(required)	Redis connection string, e.g. `redis://:pass@host:6379/0` or `rediss://...` for TLS.
`ALLOW_WRITES`	unset	Set to `1` or `true` to permit curated mutating commands via `redis_command`. Arbitrary-execution commands stay blocked regardless.
`REDIS_COMMAND_TIMEOUT_MS`	`10000`	Per-command timeout. A command that runs longer is aborted so a wedged call can't hang the agent.
`REDIS_CONNECT_TIMEOUT_MS`	`10000`	TCP connect timeout. Without this, a dead host hangs until the OS gives up (~2 minutes).
`REDIS_MAX_KEYS`	`1000`	Cap on keys returned by a single scan, and on collection elements returned by `redis_get`.
`REDIS_SCAN_COUNT`	`100`	`COUNT` hint per `SCAN` iteration. Higher = fewer round-trips but more work per iteration.
`REDIS_TLS_REJECT_UNAUTHORIZED`	unset	Set to `false` to skip TLS cert verification (for managed Redis using private-CA certs). Connection is still encrypted.

Connecting to managed Redis (Upstash, ElastiCache, Redis Cloud, etc.)

Use a rediss:// URL for TLS. If the provider serves a cert signed by a private CA that Node's trust store doesn't recognize (symptoms: self signed certificate in certificate chain, unable to verify the first certificate), add REDIS_TLS_REJECT_UNAUTHORIZED=false:

"env": {
  "REDIS_URL": "rediss://default:pass@host:6379",
  "REDIS_TLS_REJECT_UNAUTHORIZED": "false"
}

This disables certificate-chain verification only - the connection is still TLS-encrypted end-to-end. Where you can install the CA, prefer NODE_EXTRA_CA_CERTS over disabling verification.

Troubleshooting

REDIS_URL is not set - Your MCP client is launching the server without the env var. On Windows especially, env vars set in bash / PowerShell profiles are not inherited by MCP servers launched via cmd. Put REDIS_URL directly in the env block of .mcp.json.

NOAUTH Authentication required - The instance requires a password and the URL has none. Add it: redis://:yourpassword@host:6379 (note the leading colon - the username is empty for the default user).

<COMMAND> mutates state and is blocked: ALLOW_WRITES is not set - You asked for a write through redis_command in read-only mode. Add ALLOW_WRITES=1 to the env block (dev/test), or - cleaner - use a Redis ACL user scoped to the access you want.

KEYS is blocked - Intentional. Use redis_scan (cursor-based) to enumerate keys; it is safe on a large keyspace where KEYS is not.

First command is slow, subsequent commands are fast - Expected. The client connects lazily on the first command; later commands reuse the connection.

Development

npm install
npm test          # build + unit tests (no live Redis needed)

The unit suite covers the pure logic - command allowlist enforcement, SCAN cursor paging, INFO/SLOWLOG parsing, and the advisor heuristics - and runs without a Redis instance. Integration tests that exercise live paths (npm run test:integration) require a disposable Redis at REDIS_URL.

License

Available Tools

7 tools

redis_advisorA

Read-onlyIdempotent

Rolled-up Redis health lint pass -- one call returns four categories of findings, each with a severity and an actionable fix:

big_keys: sampled keys whose memory footprint or element count is large enough to make operations O(N) and risk blocking the event loop on delete/expire.
missing_ttls: share of sampled keys with no expiry -- the classic 'cache fills up and OOMs' setup.
eviction_pressure: used/maxmemory ratio, active evictions, and the dangerous noeviction + no-TTL combination that turns a full instance into failed writes.
fork_latency_risk: long last-fork time, large dataset + active persistence, and failed background saves -- the causes of periodic latency spikes and durability gaps. Keys are sampled via SCAN (never KEYS), so it is safe on a large production instance; the big-key / missing-TTL findings are over the SAMPLE, not the whole keyspace.

ParametersJSON Schema

Name	Required	Description
`sampleSize`	No	How many keys to SCAN-sample for big-key / missing-TTL checks (default 200, 0 to skip key sampling).
`bigKeyBytes`	No	Flag a key at or above this many bytes (default 1 MiB = 1048576).
`usedPctWarn`	No	Warn when used/maxmemory reaches this ratio (default 0.8 = 80%).
`forkUsecWarn`	No	Warn when the last fork took at least this many microseconds (default 100000 = 100ms).
`bigKeyElements`	No	Flag a collection with at least this many elements (default 5000).
`largeDatasetBytes`	No	Treat the dataset as large (fork-risk) at or above this many bytes (default 1 GiB = 1073741824).
`missingTtlFraction`	No	Flag when this fraction of the sample lacks a TTL (default 0.5 = 50%).

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds significant behavioral context beyond annotations: it explains the sampling method (SCAN), the four categories (big_keys, missing_ttls, eviction_pressure, fork_latency_risk), and the thresholds used. It also clarifies that findings are over the sample, not the whole keyspace. No contradictions.

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?

The description is a single, well-structured paragraph that front-loads the core purpose and then lists the four categories with clear explanations. Every sentence adds value, and there is no redundant or filler text. It is appropriately sized for the tool's complexity.

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?

Given the 7 parameters (all with defaults and descriptions in schema) and no output schema, the description provides a complete picture: it explains what the tool returns (four categories with severity and fixes), how it works (sampling), and safety considerations. It covers all essential aspects for an agent to understand and use the tool correctly.

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%, so the baseline is 3. The description does not re-explain each parameter but provides high-level mapping between parameters and categories (e.g., sampleSize affects key sampling). This adds some context but does not significantly enhance understanding beyond the schema's own descriptions.

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 clearly states the tool's purpose as a 'Rolled-up Redis health lint pass' that returns four categories of findings with severity and actionable fixes. It uses specific verbs ('returns') and resource ('health lint findings'), and distinguishes itself from sibling tools like redis_scan or redis_key_info by providing a comprehensive health assessment in one call.

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?

The description provides explicit context for safe usage: 'Keys are sampled via SCAN (never KEYS), so it is safe on a large production instance.' It implies comprehensiveness but does not explicitly state when not to use it or name alternatives. The sibling tools suggest more specific purposes, but the description itself lacks explicit guidelines.

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

redis_commandA

Destructive

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.

ParametersJSON Schema

Name	Required	Description	Default
`args`	No	Command arguments in order. For multi-word commands, the subcommand is the first arg.
`command`	Yes	The Redis command verb (e.g. `GET`, `HGETALL`, `INFO`).

TDQS

A4.9/5.0

Behavior5/5

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

The description adds significant context beyond annotations: it details that read-only commands always run, mutating commands require a flag, and arbitrary commands are never exposed. It explains the safety gate is a curated allowlist, which is crucial for safe usage.

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?

The description is a single paragraph but packs essential information efficiently: purpose, behavioral rules, and usage guidance. Every sentence contributes value, and the structure is logical and front-loaded.

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?

Given the complexity of Redis command execution with safety gates and no output schema, the description covers all necessary aspects: allowed/disallowed commands, prerequisites, and alternatives. It is complete for an agent to use correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by noting that for multi-word commands the subcommand is the first arg, which clarifies the 'args' parameter usage beyond the schema description.

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 clearly states 'Run a single Redis command through the safety gate,' specifying what the tool does. It distinguishes from siblings by noting that typed tools (redis_get, redis_scan, redis_key_info) are preferred where they exist, and that KEYS should use 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?

The description explicitly says when to use (commands without a dedicated tool) and when not to (prefer typed tools, KEYS via redis_scan). It also provides conditions for mutating commands (ALLOW_WRITES=1) and lists blocked commands, giving clear alternatives.

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

redis_getA

Read-onlyIdempotent

Read a key's value, dispatching by type so you get the right shape without knowing the type in advance: string -> the value (byte-windowed at REDIS_MAX_VALUE_BYTES, default 256 KiB, with truncated + full length when capped); hash -> field/value object; list -> array (LRANGE windowed by limit); set -> member array; zset -> [member, score] pairs (ZRANGE WITHSCORES, windowed); stream -> recent entries (XREVRANGE, windowed). Collection reads are capped at limit (default REDIS_MAX_KEYS) so a million-element list can't blow out context. Always read-only.

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	The key to read.
`limit`	No	Max elements to return for collection types (default REDIS_MAX_KEYS=1000).

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already provide readOnlyHint, openWorldHint, etc. The description adds critical behavioral details: byte-windowing at REDIS_MAX_VALUE_BYTES, truncation indication, collection caps with limit defaults, and type-specific shape mentions. No contradiction with annotations.

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 description is a single, well-structured sentence that front-loads the purpose. It is slightly verbose due to listing all types, but each part earns its place. Could be more concise.

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?

Despite no output schema, the description fully covers return shapes for all types, edge cases (truncation, defaults), and safety (read-only). Context signals show simple parameters, and the description handles the complexity well.

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 coverage is 100%. The description adds meaning to 'limit' (default REDIS_MAX_KEYS=1000, windowing) and explains how 'key' is used without extra detail. It enriches the schema's minimal descriptions.

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 clearly states the tool reads a key's value and dispatches by type. It distinguishes from siblings like redis_scan (scan keys) and redis_key_info (key info) by specifying type-aware reading.

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?

The description implies usage for reading any key's value without knowing the type, and notes it's always read-only. It does not explicitly list when not to use or compare to siblings, but the context is clear.

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

redis_healthA

Read-onlyIdempotent

One-call health snapshot rolled up from INFO + DBSIZE + recent SLOWLOG: server version and mode, uptime, memory used vs maxmemory + eviction policy, connected clients + blocked clients, ops/sec, keyspace hit/miss ratio, total keys per database (and how many lack a TTL), persistence (RDB/AOF) status, replication role, and the most recent slow commands. Use as a connection sanity check and the first stop in 'why is Redis slow / using so much memory?' triage.

ParametersJSON Schema

Name	Required	Description	Default
`slowlogLimit`	No	Number of recent slow commands to include (default 5, 0 to skip).

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds extensive behavioral detail about the specific metrics and data sources (INFO, DBSIZE, SLOWLOG), which goes beyond annotations and provides transparency about what the tool accesses.

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 description is a single well-structured paragraph that front-loads the key metrics. It is concise given the amount of information, though it could be slightly more scannable with lists.

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?

Despite no output schema, the description thoroughly explains what will be returned. The single parameter is fully documented in schema. The tool is simple and the description covers all necessary context for selection and invocation.

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 coverage is 100%, so baseline is 3. The description mentions slow commands in context but does not add new meaning to the 'slowlogLimit' parameter beyond the schema's description. No additional value provided.

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 clearly states the tool provides a health snapshot from INFO, DBSIZE, and SLOWLOG, listing specific metrics like server version, memory, clients, ops/sec, keyspace, persistence, replication, and recent slow commands. It distinguishes itself from siblings like redis_slowlog by being a rolled-up summary.

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?

The description explicitly says 'Use as a connection sanity check and the first stop in 'why is Redis slow / using so much memory?' triage,' providing clear when-to-use guidance. It does not explicitly exclude alternatives like redis_advisor, but the context is sufficient.

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

redis_key_infoA

Read-onlyIdempotent

Inspect a single key without reading its (possibly huge) value: type, TTL (seconds and ms, -1 = no expiry, -2 = key missing), internal encoding (listpack, hashtable, intset, ...), serialized memory footprint in bytes (MEMORY USAGE), and idle time. Use this before redis_get on an unfamiliar key to avoid pulling a multi-megabyte value into context, and to spot big keys / missing TTLs.

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	The key to inspect.

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations (readOnly, idempotent, non-destructive), the description explains TTL semantics, encoding examples, and memory usage via MEMORY USAGE command. It fully discloses what the tool returns and its non-value-reading nature.

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?

The description is well-structured with front-loaded purpose, followed by return details and usage advice. Every sentence adds value without redundancy.

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?

Given a single parameter and no output schema, the description covers all essential aspects: what is returned, TTL meaning, safe inspection, and use case. No gaps remain.

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 already describes 'key' as 'The key to inspect' with 100% coverage. The description adds no new parameter-specific details (e.g., format, patterns), only behavioral context. Baseline score of 3 is appropriate.

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 clearly states the tool inspects a single key's metadata (type, TTL, encoding, memory, idle time) without reading its value. It distinguishes from sibling redis_get by explicitly recommending use before retrieval.

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?

Explicitly recommends using before redis_get to avoid pulling large values, and to spot big keys/missing TTLs. While it doesn't enumerate all alternatives, the guidance is strong and context-specific.

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

redis_scanA

Read-onlyIdempotent

Enumerate keys with cursor-based SCAN -- NEVER the O(N) KEYS command, so this is safe to run against a production instance with millions of keys (SCAN yields the event loop between batches). Returns up to REDIS_MAX_KEYS keys (default 1000) matching an optional glob match pattern (e.g. user:*, session:??). When more keys remain, truncated is true and cursor is non-'0' -- pass that cursor back to continue from where you left off. Optionally filter by value type (string/list/set/zset/hash/stream). Within one call duplicate keys are removed; across a resumed scan a key may reappear (SCAN's guarantee is no key present for the whole scan is missed, not that none repeats).

ParametersJSON Schema

Name	Required	Description	Default
`type`	No	Filter to keys of this value type (uses SCAN's TYPE option).
`count`	No	COUNT hint per SCAN iteration (default REDIS_SCAN_COUNT=100). Higher = fewer round-trips, but very high values increase per-iteration event-loop hold time on large keyspaces -- the small-batch yield is this module's core safety property for production instances.
`match`	No	Glob pattern to match keys (e.g. `user:*`). Omit to scan all keys.
`cursor`	No	SCAN cursor to resume from. Start (and default) is '0'.	0

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, etc.), the description reveals critical behaviors: SCAN yields event loop between batches, duplicate removal within a call, possible reappearance across resumed scans, default max keys, and the truncated flag. This fully informs the agent of the tool's safety and pagination model.

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 description is a single paragraph but well-organized: starts with the primary purpose, then details pagination, pattern, and type filtering. Every sentence adds value, though a slightly more structured format (e.g., bullet points) could improve scannability.

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?

Given the tool's complexity (cursor-based iteration, safety guarantees, multiple optional parameters) and the absence of an output schema, the description is remarkably complete. It explains return fields (truncated, cursor), pagination semantics, and production safety, leaving no critical gaps for an agent.

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?

All 4 parameters are fully documented in the schema (100% coverage), but the description adds substantial value: explains cursor-based pagination, default count and its safety implications, pattern matching syntax, and the type filter enum. This goes beyond the schema's basic descriptions.

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 clearly states it enumerates keys with cursor-based SCAN, explicitly contrasting with the O(N) KEYS command and highlighting safety for production. This distinguishes it from sibling tools like redis_get or redis_key_info.

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?

The description provides clear usage context: use for safe key enumeration, especially on production with many keys. It explains how to resume scans with cursor and mentions optional pattern/type filtering. While not explicitly listing when not to use it, the sibling tools are sufficiently different.

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

redis_slowlogA

Read-onlyIdempotent

Recent entries from the Redis slow log -- commands that took longer than slowlog-log-slower-than microseconds (default 10000 = 10ms). Each entry has the command, execution time in microseconds, a unix timestamp, and the client address/name (Redis 4+). The fastest way to find which specific commands are slow. Read-only (SLOWLOG GET); SLOWLOG RESET would need ALLOW_WRITES and is intentionally not exposed here.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max slowlog entries to return (default 20).

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining the data source (slowlog), configuration (slowlog-log-slower-than), and that reset is not exposed. No contradictions.

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?

Three sentences, each informative. Front-loaded with the core purpose. Every sentence earns its place with no redundancy.

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?

Despite no output schema, the description explains the fields of each entry. Covers the configuration, why to use it, and what is not exposed. Complete for a simple tool with one parameter.

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?

Input schema has one parameter (limit) with full description, default, min, max. The description does not add meaning beyond the schema but provides context about the log content. Schema coverage is 100%, baseline 3.

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 clearly states it returns recent entries from the Redis slow log, specifying fields (command, execution time, timestamp, client address). It distinguishes itself from other tools by claiming it's the fastest way to find specific slow commands.

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?

Explicitly says it's the fastest way to find slow commands, implying its primary use case. Mentions that SLOWLOG RESET is intentionally not exposed, indicating a limitation. However, it does not compare to sibling tools like redis_advisor or redis_command.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: scanning keys, inspecting single key metadata, reading values, running generic commands, health check, slow log, and advisor. No overlap.

Naming Consistency5/5

All tool names follow the consistent pattern redis_<action>, using descriptive nouns (scan, key_info, get, command, health, slowlog, advisor). No mixing of conventions.

Tool Count5/5

7 tools is well-scoped for a Redis diagnostic and data access server. Each tool earns its place, covering essential operations without bloat.

Completeness4/5

Covers key read operations, scanning, health, and diagnostics. Write operations (set, delete) are available via redis_command with write gate, but a dedicated write tool is missing, making coverage not fully explicit.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcpcheckup A
io.github.fpetitit
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
Penetration Testing Security
22
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42
ArcadeOps Public Discovery A
io.github.Damso74
Read-only ArcadeOps discovery for developer docs, OAuth, OpenAPI and synthetic sandbox.
API Testing Documentation Access Developer Tools
31
Kadent Scan A
so.kadent
Free, read-only security scanner for remote MCP servers, before you connect them.
Security Penetration Testing
11

Related MCP Servers

redis-mcp-server
Databases Monitoring
lm203688
A
license
A
quality
D
maintenance
Enables AI to safely view and operate Redis databases with read-only mode by default and support for key operations.
Updated 4 months ago (2026-05-13 09:15 UTC)
11
MIT
mcp-opensearch
Search Observability Databases
dmayan-ss
A
license
Not graded
quality
D
maintenance
Read-only MCP server for exploring and searching OpenSearch clusters, enabling log analysis, index exploration, and query execution.
Updated 6 months ago (2026-02-26 19:45 UTC)
MIT
mcp-redis-allowlist
Databases Monitoring
TeaBambooNGU
A
license
B
quality
C
maintenance
Read-only Redis MCP server with a configurable command allowlist for safe production diagnostics, enabling exact read-only subcommands like CLIENT LIST and SLOWLOG GET.
Updated 2 months ago (2026-07-01 05:59 UTC)
5
MIT
Upstash Redis MCPofficial
Databases Documentation Access
upstash
A
license
Not graded
quality
B
maintenance
Lightweight MCP server for Redis that allows running any Redis command and searching Redis documentation. Supports multiple named databases with HTTP/REST or TCP transport.
Updated 2 months ago (2026-07-08 14:32 UTC)
63
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/YawLabs/redis-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@yawlabs/redis-mcp

Why this one?

Scope

Quick start

Security

Tools

Configuration

Connecting to managed Redis (Upstash, ElastiCache, Redis Cloud, etc.)

Troubleshooting

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Upstash Redis MCPofficial

Latest Blog Posts

MCP directory API