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.

```text
NOPERM No permissions to run the "set" command
```

## Fix it

1. Check what the user is allowed to do:

```bash
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.