The pairing is the point: asking which alarms fired and then acting on the affected clusters normally means two consoles and a context switch. The SQL side is deliberately read-only, so the risk lives entirely on the TALM side, where remediation and CGU management change real clusters. Treat it as a lab build — the authors say so plainly — and give it credentials scoped to a lab tenant.
A proof-of-concept repository holding a PostgreSQL MCP server, a TALM (Topology Aware Lifecycle Manager) MCP server for Red Hat ACM, and a Google ADK web agent that talks to both. The authors mark it clearly as not for production use.
- `execute_query(database, query)` — read-only SQL against the alarms, resources or clusters database, returning JSON with the results, metadata and the SQL that ran
- A safety rule on that tool: only SELECT and WITH statements are accepted
- TALM resources for managed clusters, policies and cluster status, with tools for cluster remediation, health checks and CGU management
- Guided prompts for cluster lifecycle operations, rather than raw calls
- Both servers run as streamable HTTP on ports 3000 and 3001, or as stdio commands in Claude Desktop
- A unified natural-language web interface on port 8000 that spans database and cluster questions
Uv, and `uv sync` in the checkout. TALM needs `KUBECONFIG` pointing at your cluster config. The PostgreSQL server needs host, port, name, user and password for each of the three databases, so `ALARMS_DB_HOST`, `RESOURCES_DB_HOST` and `CLUSTERS_DB_HOST` each come with their own port, name, user and password entries. An OpenShift deployment path exists too, running all three containers in one pod with only the web interface exposed through a route.
Build from source — clone the repository and build it, then point your client at the binary