Redis MCP: NOPERM no permissions to run the command (ACL user too restricted)

TL;DR: NOPERM means you authenticated fine but your Redis user is not allowed to run that command. If you set up a read-only user, writes failing is the system working as designed. Either grant the ACL permissions or switch the MCP server to a user that has them.

NOPERM No permissions to run the "set" command

Fix it

1. Check what the user is allowed to do:

redis-cli -u "redis://host:6379" ACL WHOAMI
redis-cli -u "redis://host:6379" ACL LIST

2. On the Redis server, grant the missing permissions. For a read-mostly agent user that also needs some writes:

ACL SETUSER mcpuser on >newpassword +@read +@connection +set +del ~*

Persist ACLs with an aclfile so they survive restarts.

3. Or point the MCP server at a more privileged user via REDIS_USERNAME / REDIS_PWD and restart.

   Expected: the previously denied commands succeed.

When to use this

• Auth works, reads work, but writes fail with NOPERM.
• You deliberately created a least-privilege user for the agent.

When NOT to use this

• The error is NOAUTH or WRONGPASS. That is authentication, not authorization.
• All commands fail including reads. Then the ACL is missing +@read or the user is disabled.

Compatibility

• redis/mcp-redis against Redis 6+ with ACLs.

Why it happens

Redis 6 introduced ACLs so each user gets a command allowlist. Least-privilege agent users commonly get +@read only, which is correct for a query agent but breaks the moment the agent (or you) tries a write. The MCP server passes the error straight through, so it looks like a server bug when it is policy.

Edge cases

• Key patterns matter too: ~* allows all keys; a restricted pattern like ~cache:* denies everything else even with +@all commands.
• ACL changes apply immediately, but the MCP server may hold a pooled connection authenticated as the old definition. Restart it to be sure.
• On managed providers, edit the user in the Access Control panel rather than via ACL commands.