AIops-tools/Queue-AIops

**Governed AI-ops for redis + rabbitmq.** queue-aiops is for the team running
their own cache and message broker — a redis that "suddenly eats memory", a
rabbitmq whose queues quietly grow until publishers block — without an
enterprise observability suite. It gives an AI agent (or a human at the CLI) a
governed toolset over both: transparent root-cause analyses for memory
pressure, latency, queue backlog, and connection churn, plus the handful of
writes an operator actually needs (config set, client kill, purge/delete
queue, policies) — every call audited, budgeted, risk-tiered, and undo-recorded
by the built-in governance harness.
> **Disclaimer**: Community-maintained open-source project, **not affiliated
> with, endorsed by, or sponsored by the Redis or RabbitMQ projects or their
> respective owners.** Redis and RabbitMQ are trademarks of their respective owners.
>
> **Verification**: behaviour is covered by a mock-based test suite; not yet validated
> against live brokers. Both redis and rabbitmq are free/self-hostable (one lab container
> or package install each), so a lab check is easy — queue-aiops doctor is the fastest
> live probe, and docs/VERIFICATION.md is the checklist.
Quick start
As a Claude Code plugin
One install gives an agent both the skill and the MCP server:
The MCP server is fetched with uv and pinned to the
package version this plugin declares, so an audit row can be traced back to the
code that wrote it. Credentials are still configured with queue-aiops init — see below.
As an OpenClaw plugin
The same bundle is published on ClawHub, where one
install delivers the skill and its MCP server together:
Restart the OpenClaw gateway afterwards so it loads the plugin. The MCP server is
fetched with uv, pinned to this exact release, so
uvx has to be on PATH — without it the skill still installs but reports
Visible to model: no. Credentials are configured exactly as below.
As a CLI or standalone MCP server
Then the interesting parts:
What this tool does, and does not, decide
It delivers broker operations — reads and writes — accurately and efficiently,
and records every one of them. It does **not** decide whether a write is allowed
to happen. That is the agent's judgement, or the permission of the account you
connect it with: give the Redis connection an ACL user restricted to read
commands, or the RabbitMQ management user only the monitoring tag, and the
writes fail at the broker — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: **every call, over
MCP and over the CLI alike, lands an audit row** in ~/.queue-aiops/audit.db,
and reversible writes still capture their before-state and record an inverse.
> Each tool declares a risk_level, kept in agreement with its [READ]/[WRITE]
> documentation tag by a test, and carried into the audit row as a descriptive
> tier — so a reviewer can see at a glance that a row was a high-risk delete. It
> is a label, not a gate.
Running a smaller / local model? See
agent-guardrails.md — it lists
the guardrails this tool now enforces for you (so you don't spend prompt budget
restating them) and gives a ready-made system prompt for what's left.
Support scope
| Platform | Protocol | Coverage |
|----------|----------|----------|
| **redis** (5.x–7.x wire protocol via redis Python client) | RESP, password optional, TLS optional | INFO (server/memory/clients/stats/persistence/keyspace), SLOWLOG, CLIENT LIST/KILL, CONFIG GET/SET, MEMORY STATS/USAGE, SCAN-budgeted big-key sampling, DBSIZE, PING |