Redis MCP: managed Redis needs rediss:// TLS (plain redis:// fails)

TL;DR: Managed Redis (Upstash, Redis Cloud) requires TLS. If your URL starts with redis://, the connection fails. Change it to rediss:// (note the double s) or set REDIS_SSL=true, and it connects.

Error: connect ETIMEDOUT / connection reset

(Plain redis:// against a TLS-only endpoint. The exact error varies; timeouts and resets are typical.)

Fix it

1. Change the scheme in your connection URL:

rediss://your-endpoint:6379

Or if you configure via env vars, set REDIS_SSL=true alongside REDIS_HOST, REDIS_PORT, REDIS_PWD.

1. Restart the MCP server.

Expected: the server connects and tools respond.

When to use this

• Connecting redis/mcp-redis to Upstash, Redis Cloud, or any managed Redis.
• Local redis://YOUR_HOST:6379 works but the managed endpoint does not.

When NOT to use this

• Local dev Redis without TLS. Forcing TLS there breaks the connection the other way.
• The error is NOAUTH or WRONGPASS. TLS is fine; the credentials are the problem.

Compatibility

• redis/mcp-redis (REDIS_SSL env var, rediss:// URL scheme).
• Upstash, Redis Cloud, AWS ElastiCache with in-transit encryption.

Why it happens

Managed Redis providers terminate TLS at the endpoint and refuse plaintext. A redis:// client starts a plaintext handshake the server immediately drops, which surfaces as a timeout or reset rather than a helpful error. The rediss:// scheme tells the client to negotiate TLS first.

Edge cases

• Self-signed or private-CA certs on private endpoints may need REDIS_SSL_CA_CERTS pointed at the CA bundle.
• Upstash also offers a REST API with a token. That is a different protocol, not a substitute for the Redis password over rediss://.
• Some clients need the port from the provider panel. Upstash uses 6379; Redis Cloud uses a per-database high port.