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

Not specified by the original author.

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.

2. 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.

The okengine Upstash provider docs (omqkhafi/okengine site/content/docs/providers/upstash.mdx) state TLS is mandatory and redis:// without TLS fails, with the documented REDISURL form rediss://endpoint:6379. The redis-cloud.mdx doc repeats that public endpoints expect TLS, use the rediss:// scheme. The redis/mcp-redis server exposes REDISSSL to enable TLS for the Redis connection. Connecting without TLS to a TLS-mandating endpoint fails at the transport level.

Not specified by the original author.

TL;DR: Managed Postgres providers (Supabase, Neon, RDS) require TLS and your MCP server is connecting without it. Append ?sslmode=require to the connection URL in your client config. That is the whole fix.

Error: SSL connection is required. Please specify SSL options and retry.

Variant phrasings you may see: SSL is required, server requires encryption, no pg_hba.conf entry for host ... SSL off.

Fix it

1. Find the connection URL in your MCP client config (env block, e.g. DATABASE_URL or the server's first CLI arg).
2. Append the SSL mode parameter:

postgresql://db.supabase.co:5432/postgres?sslmode=require

If the URL already has query parameters, join with & instead: ...?connect_timeout=10&sslmode=require.

3. Restart the MCP client so the server picks up the new URL.

   Expected: the next tool call connects and returns rows. No SSL error.

When to use this

• Connecting an MCP Postgres server to Supabase, Neon, RDS, or any managed Postgres.
• The error mentions SSL, TLS, or encryption being required.

When NOT to use this

• Local dev Postgres (Docker, Homebrew). Forcing SSL there causes the opposite error. Use sslmode=disable for local dev if needed.
• The error is a certificate verification failure (self-signed certificate). That needs the CA cert or a different sslmode, not just require.

Compatibility

• All MCP Postgres servers that pass the URL to node-postgres/pg: @modelcontextprotocol/server-postgres, yawlabs/postgres-mcp, Tabulus, pgedge-postgres-mcp.
• Supabase, Neon, AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL.

Why it happens

Managed Postgres fleets terminate plain connections as a security policy. The pg driver defaults to opportunistic SSL (prefer), which is not enough for providers that mandate it. sslmode=require tells the driver to always negotiate TLS, which is what the provider expects.

Edge cases

• Supabase pooler URLs (port 6543) also need sslmode=require.
• If you get a certificate error after adding it, your provider uses a custom CA. Either supply the CA (sslrootcert) or check the provider docs for their recommended sslmode.
• Some servers read the URL once at startup. A client restart is required, not just a new chat.

The Tabulus (WalkingMountain/tabulus) troubleshooting table documents this exact failure mode: Error ... SSL ... required with the cause managed Postgres (Supabase, Neon, RDS) requires TLS and the fix append ?sslmode=require to the URL. This is the documented gotcha for connecting MCP Postgres servers to managed providers. Source: https://github.com/WalkingMountain/tabulus

Not specified by the original author.

TL;DR: NOAUTH means the Redis MCP server connected without a password to a Redis that requires one. Set REDIS_PWD in the server's environment (and REDIS_USERNAME if you use ACL users) and restart. Every command will start working.

NOAUTH Authentication required.

Fix it

1. Confirm the Redis side requires auth. If you run it, check for --requirepass or requirepass in the config. If it is managed (Upstash, Redis Cloud), it always requires auth.
2. Set the credentials in the MCP server's environment. In your client config env block, or wherever you launch the server:

REDIS_HOST=your-redis-host
REDIS_PORT=6379
REDIS_USERNAME=default
REDIS_PWD=your-redis-password

Command-line args take precedence over env vars if your setup passes --url explicitly. Make sure the password is in the URL then: redis://:password@host:6379/0.

3. Restart the MCP server (restart the client for stdio servers).

   Expected: tools execute and return data. PING returns PONG.

When to use this

• Every Redis tool call fails with NOAUTH Authentication required.
• redis-cli -a [password] ping works, proving the server and password are fine.

When NOT to use this

• The error is WRONGPASS. A password is being sent, it is just wrong. Fix the value, not the presence.
• The error is a connection timeout or refused. The server is not reachable at all.

Compatibility

• redis/mcp-redis (env-var and --url configuration).
• Redis 6+ with ACLs, Redis 7, Upstash, Redis Cloud, self-hosted with requirepass.

Why it happens

The Redis MCP server defaults to no password (REDIS_PWD empty). That matches a default local Redis, but any production or managed Redis requires auth. The server does not prompt or fail at startup; it connects and then every command gets NOAUTH, which looks like the server is broken when it is just unauthenticated.

Edge cases

• With ACLs, an empty username sends a one-arg AUTH that fails differently. Set REDIS_USERNAME=default explicitly when using the default user with a password.
• Special characters in the password inside a --url must be percent-encoded.
• Docker setups: the env var must be passed into the container (-e REDIS_PWD=...), not just set on the host.

The redis/mcp-redis server reads connection settings from environment variables including REDISHOST, REDISPORT, REDISUSERNAME and REDISPWD, documented in the project's configuration guides (zskbot/catalog image/redis-mcp/guides.md, upstream https://github.com/redis/mcp-redis). When the Redis server runs with --requirepass and the MCP server has no password configured, every command fails with NOAUTH Authentication required. The same failure is documented in deployment guides: REDIS_URL had no credentials while the server runs with --requirepass, so clients failed with NOAUTH.