Redis MCP vs Redis MCP Server
A side-by-side look at the Redis MCP and Redis MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Redis MCP for databases work as a local process; choose Redis MCP Server for databases as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Redis MCP when
- You need dedicated capabilities in the Databases domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN, UPSTASH_REDIS_TCP_URL, REDIS_URL. - You want tools like
redis_run_commands, redis_search_docs.
Choose Redis MCP Server when
- You need dedicated capabilities in the Databases domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
REDIS_URL, ALLOW_WRITES, REDIS_COMMAND_TIMEOUT_MS, REDIS_CONNECT_TIMEOUT_MS, REDIS_MAX_KEYS, REDIS_MAX_VALUE_BYTES. - You want tools like
redis_scan, redis_key_info, redis_get.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Databases | Databases |
| Quality signal | 55/100 · Good | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | UPSTASH_REDIS_REST_URLUPSTASH_REDIS_REST_TOKENUPSTASH_REDIS_TCP_URLREDIS_URL | REDIS_URLALLOW_WRITESREDIS_COMMAND_TIMEOUT_MSREDIS_CONNECT_TIMEOUT_MSREDIS_MAX_KEYSREDIS_MAX_VALUE_BYTES |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 2 |
| Directory activity | 2 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 2 | 7 |
| Full listing | View Redis MCP | View Redis MCP Server |
Tools & capabilities
Redis MCP tools 2
redis_run_commandsRun one or more Redis commands against an Upstash Redis database (this server is ONLY for Upstash Redis). Commands are sent over HTTP/REST or native TCP depending on how the target database is configured — you don't choose the transport. By default multiple commands run as a pipeline: each returns its own result/error, and one failure does not abort the others. Set transaction:true to run them atomically (MULTI/EXEC). For discovery prefer SCAN over KEYS, and use TYPE to inspect a key. A valid command that fails (e.g. WRONGTYPE) returns a per-command error while the rest of the pipeline still runs; a malformed/unknown command can cause the whole request to be rejected. Upstash Redis Search runs through THIS tool via SEARCH.* commands (SEARCH.LISTINDEXES/CREATE/QUERY/AGGREGATE/COUNT/DESCRIBE) — NOT RediSearch's FT.*; filters/aggregations are JSON strings. If you don't know the index name, run SEARCH.LISTINDEXES first; then SEARCH.DESCRIBE <index> for field names/types, and call redis_search_docs for syntax. Three gotchas: (1) a filter applies to ALL indexed documents unless you scope it, e.g. {"type":"story"} — an empty {} counts every type; (2) a plain text value like {"title":"x"} does fuzzy/smart matching, so for an exact word or adjacent phrase use {"title":{"$phrase":"x"}}; (3) add SELECT <n> field... to a query to return only the fields you need instead of whole documents.redis_search_docsLook up **Upstash Redis** documentation — any command, feature, option, or syntax. Covers the whole Upstash Redis surface: core Redis commands, the REST API, pipelines/transactions, and Upstash-specific features. This INCLUDES Upstash Redis Search — the SEARCH.* full-text family (SEARCH.CREATE / SEARCH.QUERY / SEARCH.AGGREGATE / SEARCH.COUNT / ...), whose JSON-based index schema and query syntax are Upstash-specific and DIFFER from Redis Labs' RediSearch FT.*, so they are unlikely to be in your training data — verify them here. Reach for this whenever you're unsure about a command, option, or syntax, and ALWAYS before writing a SEARCH.* command. Pass a natural-language query.
Redis MCP Server tools 7
redis_scanEnumerate 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).redis_key_infoInspect 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.redis_getRead 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. The size and `truncated` fields come before the payload, so a host that caps tool results below REDIS_MAX_VALUE_BYTES (Yaw MCP: 100,000 bytes by default) cuts payload, not them. Always read-only.redis_commandRun 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.redis_healthOne-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.redis_slowlogRecent 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.redis_advisorRolled-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.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Redis MCP
{
"mcpServers": {
"redis-mcp": {
"command": "npx",
"args": [
"-y",
"@upstash/redis-mcp"
],
"env": {
"UPSTASH_REDIS_REST_URL": "YOUR_UPSTASH_REDIS_REST_URL_HERE",
"UPSTASH_REDIS_REST_TOKEN": "YOUR_UPSTASH_REDIS_REST_TOKEN_HERE",
"UPSTASH_REDIS_TCP_URL": "YOUR_UPSTASH_REDIS_TCP_URL_HERE",
"REDIS_URL": "YOUR_REDIS_URL_HERE"
}
}
}
}
Redis MCP Server
{
"mcpServers": {
"redis-mcp-server": {
"command": "npx",
"args": [
"-y",
"@yawlabs/redis-mcp@latest"
],
"env": {
"REDIS_URL": "YOUR_REDIS_URL_HERE",
"ALLOW_WRITES": "YOUR_ALLOW_WRITES_HERE",
"REDIS_COMMAND_TIMEOUT_MS": "YOUR_REDIS_COMMAND_TIMEOUT_MS_HERE",
"REDIS_CONNECT_TIMEOUT_MS": "YOUR_REDIS_CONNECT_TIMEOUT_MS_HERE",
"REDIS_MAX_KEYS": "YOUR_REDIS_MAX_KEYS_HERE",
"REDIS_MAX_VALUE_BYTES": "YOUR_REDIS_MAX_VALUE_BYTES_HERE"
}
}
}
}
Frequently asked questions
Redis MCP is categorized under Databases and uses a local stdio subprocess. Redis MCP Server belongs to Databases and uses a local stdio subprocess. Pick Redis MCP for databases work and Redis MCP Server for databases.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Redis MCP has no declared pricing — check the project's own site. Redis MCP Server has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add redis-mcp and redis-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Redis MCP has a quality signal of 55/100 (Good) with 2 views, 0 installs and 0 GitHub stars. Redis MCP Server has 63/100 (Good) with 1 views, 0 installs and 2 GitHub stars.