Enumerate 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).

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

Read 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. Always read-only.

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

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

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

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