Organizations are increasingly adopting AI-driven tools to streamline operations, and database operations are an obvious place where the promise is compelling. Database teams spend a lot of time answering recurring questions:

• “What clusters are running?”
• “Which nodes are unhealthy?”
• “Why did that backup fail?”
• “Are there active alarms?”
• “Which query is causing the slowdown?”
• “What changed in the last hour?”

The difficult part is not asking those questions, it’s giving an AI assistant safe, structured, and useful access to the operational context needed to answer them. That’s why ClusterControl now includes a much more complete Model Context Protocol integration: ClusterControl MCP.

It lets operators talk to their database infrastructure in plain English from an MCP-compatible AI client such as Claude Desktop, Claude Code, OpenAI Codex, or another tool that supports MCP. Instead of switching between dashboards, command-line tools, SQL clients, API calls, and log files, you can ask the assistant a question and let it use ClusterControl as the operational control plane.

Before going further, it is worth addressing the obvious concern: database operations are sensitive. Any AI-assisted workflow needs to be designed around boundaries, auditability, and human control.

AI and database ops privacy and security concerns

ClusterControl MCP helps by keeping the AI client away from direct database access. The MCP server talks to the CMON controller on behalf of the user, and ClusterControl continues to enforce access through CMON users and permissions. The AI assistant does not need direct credentials for every database node, and it does not need to discover your infrastructure by guessing commands or parsing random shell output.

The MCP server also supports two separate authentication layers.

The first is authentication from the MCP server to the CMON controller. For development or testing, you can use a CMON username and password.

For production, RSA key authentication is recommended, so the MCP server can authenticate without transmitting a reusable password.

The second is authentication from the AI client to the MCP server. When running the MCP server in HTTP mode, you should require a bearer token using MCP_AUTH_TOKEN, especially if the service is bound to anything other than 127.0.0.1.

There are also safety controls for operations that change state. Write actions use a dry-run-first flow by default. The assistant describes what it would do before anything is changed, and the operation only executes after explicit confirmation. Higher-risk actions such as restarts, failover, restore operations, deleting backup schedules, dropping users, or removing ClusterControl accounts include additional warning text in the dry-run output.

Sensitive output is also handled carefully. Some tools hide potentially sensitive fields by default, such as email addresses, full SQL query text, or SQL text from deadlocked transactions. You can opt in to those details as needed when needed for debugging.

As always, operators still need to treat logs, hostnames, query text, and configuration details as sensitive operational data. MCP gives the assistant structured access. It does not remove the need for good judgment

What an MCP is and why it is useful for database ops

Model Context Protocol, or MCP, is a standard way for AI clients to connect to external tools and data sources. In database operations, that matters because the assistant needs more than general knowledge. It needs live context: cluster state, alarms, backups, jobs, logs, configuration, topology, and recent activity.

Without MCP, you might ask an AI model what to check when a backup fails. It can give generic advice, but it cannot inspect your actual backup history, retrieve the failed job log, compare the configured backup schedule, or see whether the affected node is already in maintenance. With ClusterControl MCP, the assistant can work through that kind of operational question using ClusterControl as the source of truth.

The point is not that MCP lets you do things that were impossible before, you could already use dashboards, CLI commands, SQL queries, logs, and scripts. The value is that MCP makes these workflows faster, more consistent, and easier to operate through natural language.

For example, instead of writing a custom script for every scenario, you can quickly ask:

“Which clusters have active critical alarms, what caused them, and what should I check first?”

Or,

“Show me failed backup jobs from the last 24 hours and summarize the likely root cause for each one.”

That is where MCP fits: not as a replacement for operational judgment, but as a safer and more structured bridge between AI assistants and real database infrastructure.

What is ClusterControl MCP?

ClusterControl MCP connects your assistant to your ClusterControl environment through a lightweight background process that communicates with the CMON controller, enabling it to use 69 tools and 20 MCP resources to retrieve information, inspect operational state, and, where permitted, propose or perform actions — it covers a broad set of workflows, including:

• Cluster inventory and topology
• Jobs and operational history
• Alarms and health checks
• Backups, restores, and backup schedules
• Performance diagnosis
• Schema health checks
• Transaction deadlock inspection
• ProxySQL inspection
• Database and controller configuration
• Database users and privileges
• ClusterControl user management
• Maintenance windows
• Audit logs
• CMON controller logs
• Database server and collected host logs
• Error reports
• PostgreSQL logical replication metadata

That makes the current ClusterControl MCP a much more complete operational interface than a simple “list my clusters” or “show me alarms” helper.

What can you do with it?

Get a cluster overview

Get a quick view of your whole environment or drill into a specific cluster, example prompts:

• “List all my database clusters and their status.”
• “What database clusters do I have running?”
• “Give me a summary of cluster 4.”
• “Show me all nodes across my clusters.”
• “Show me the topology of cluster 2.”

The topology view is especially useful when troubleshooting replication or failover scenarios, because the assistant can reason about how nodes relate to each other rather than treating each host as an isolated machine.

Investigate jobs and operations

ClusterControl already tracks operational jobs. The MCP makes that history conversational; example prompts:

• “Show me recent jobs on cluster 2.”
• “Show me only failed jobs on cluster 1.”
• “What backup jobs have run on cluster 3?”
• “Why did job #42 fail? Show me the log.”

You can also start or stop operational jobs through the MCP, subject to the built-in dry-run and confirmation flow — example prompts:

• “Run a backup on cluster 1 right now.”
• “Trigger a rolling restart of cluster 2.”
• “Start a failover on cluster 4 — the primary is down.”
• “Rebuild the replication slave on db3.example.com.”
• “Job #88 has been stuck for an hour — kill it.”

N.B. This is a major shift from a read-only assistant. The MCP now supports operational execution, while still requiring preview and confirmation for changes.

Work with alarms and health status

Instead of checking each cluster manually, you can ask for alarm summaries across the environment or filter by severity, cluster, or host, example prompts:

• “Are there any active alarms across all clusters?”
• “Show me alarms for cluster 3.”
• “Show me only critical alarms.”
• “What is the health status of my Galera cluster?”

You can also acknowledge alarms when they are known, expected, or already being handled, example prompts:

• “Acknowledge the high CPU alarm on cluster 3, we know about it.”
• “Acknowledge all warnings on cluster 1.”
• “Clear all warning-level alarms on db1.example.com.”
• “Show me active alarms on cluster 2, then acknowledge any that are just warnings.”

Diagnose performance problems

Diagnosing performance issues is one of the strongest use cases for AI-assisted operations because the workflow often spans multiple signals including, node metrics, long-running queries, top queries, growth trends, and logs — example prompts:

• “What is the CPU and memory usage on cluster 2’s nodes?”
• “Show me the top queries by wait time on cluster 1.”
• “Are there any long-running queries on cluster 3 right now?”
• “Kill the query with process ID 4321 on db1.example.com — it has been running for 2 hours.”
• “How fast is the database on cluster 1 growing? Show me the last 30 days.”

The assistant can collect the relevant data through ClusterControl MCP and summarize it in operational terms, instead of forcing the operator to jump between monitoring graphs, process lists, and SQL clients.

Check schema health and deadlocks

ClusterControl MCP can also help identify structural issues that often cause production problems later, example prompts:

• “Are there any tables without primary keys on cluster 1?”
• “Check for redundant indexes on my production cluster.”
• “Find any MyISAM tables on cluster 2 that should be converted to InnoDB.”

For application hangs and concurrency problems, you can inspect transaction deadlocks using prompts like,

• “Are there any deadlocks on cluster 1?”
• “Show me recent transaction deadlocks — my app is hanging.”
• “What transactions are blocking each other on the production cluster?”

N.B. SQL text from deadlocked transactions is omitted by default to reduce the risk of leaking sensitive application content. When you need it for a specific investigation, you can ask for it explicitly.

Manage backups, restores, and backup schedules

Backups are a natural fit for conversational operations because the questions are usually simple but the investigation can be tedious; example prompts:

• “List recent backups for cluster 5.”
• “Show me only failed backups on cluster 1.”
• “When was the last successful backup on my MongoDB cluster?”
• “Give me a summary of the backup schedules on cluster 2.”
• “Does cluster 1 have a backup schedule configured?”

The MCP can also help manage recurring backup jobs and restore from backups, e.g.,

• “Create a nightly backup schedule at 02:00 on cluster 1 using xtrabackup.”
• “Change the backup schedule on cluster 3 to run at 03:30 instead of 02:00.”
• “Delete backup schedule #42 on cluster 1 — we are switching to a different tool.”
• “Restore backup #42 to cluster 1 — the last deployment broke the data.”
• “Roll back cluster 3 to yesterday’s backup.”

N.B. Restore operations are high risk, so they should always be handled deliberately. ClusterControl MCP’s dry-run-first behavior is particularly important here: the assistant should show exactly what it intends to do before the action is executed.

Schedule maintenance windows

Maintenance windows are another common operational task that benefits from natural language. Example prompts:

• “Is any node in cluster 2 in maintenance mode?”
• “Show me all maintenance windows across my clusters.”
• “Show me only active maintenance windows.”
• “Put db1.example.com into maintenance from 22:00 to 23:00 UTC tonight — we are patching the OS.”
• “Cancel all maintenance windows on cluster 3.”
• “Remove all active maintenance windows on db1.example.com.”

This lets teams coordinate planned work without clicking through several screens or remembering the exact command syntax.

Manage users and access

ClusterControl MCP can work with both database users and ClusterControl users. Example prompts include for database users and privileges include;

• “Who are the database users on cluster 2?”
• “Create a read-only user called reporter with SELECT on the analytics database.”
• “Add a user appuser that can connect from 10.0.0.0/8.”
• “Grant INSERT and UPDATE on appdb.* to appuser on cluster 1.”
• “Revoke DELETE from appuser on cluster 2.”
• “Remove all privileges from tempuser on cluster 1.”

For ClusterControl users, example prompts include:

• “List all ClusterControl users.”
• “Who has access to the ClusterControl interface?”
• “What CMON groups exist?”
• “Create a ClusterControl user called john with email [email protected].”
• “Update alice’s email address.”
• “Change the password for ClusterControl user bob.”
• “Remove the ClusterControl user oldstaff — they have left the company.”

N.B. Email addresses are omitted from user-list output by default to reduce PII exposure. As with other sensitive fields, you can request them explicitly when needed.

Inspect configuration

ClusterControl MCP can inspect and modify both database node configuration and CMON controller runtime settings — example prompts for database node configuration:

• “Show me the configuration for cluster 1.”
• “What are the settings for the primary node of cluster 3?”
• “What is the max_connections setting on host db1.example.com?”
• “Set max_connections to 500 on db1.example.com in cluster 1.”
• “Reset innodb_buffer_pool_size on db2.example.com to the database default.”

Example prompts for controller runtime settings:

• “Show me the controller settings for cluster 1.”
• “What is the swap_warning threshold on cluster 2?”
• “Set swap_warning to 20 on cluster 1.”
• “What is the backup retention period on cluster 3?”

N.B. Configuration changes are exactly the sort of operation where the dry-run-first model matters. The assistant can explain what it will change before anything is applied.

Read CMON and database logs

The MCP exposes two important categories of logs. CMON controller logs explain what the ClusterControl controller recorded for a cluster, such as host registration, alarm activity, replication watchers, and configuration changes — example prompts:

• “Show me the CMON log for cluster 1.”
• “Are there any warnings in the CMON log for cluster 2?”
• “Show CMON log entries from db2.example.com in the last hour, severity LOG_WARNING or higher.”
• “Summarize the CMON log for cluster 1 by severity and component.”

Database server and collected host logs answer a different question: what did the database or host-side services say? You can submit prompts like these:

• “List the log files collected from cluster 1.”
• “Show me the last 200 lines of mysqld.log on db1.example.com in cluster 1.”
• “Save the full PostgreSQL log from db1.example.com in cluster 4 to /tmp/pg.log.”

This distinction is useful during incident response. Sometimes you need to know what ClusterControl did. Sometimes you need to know what the database itself reported.

Inspect ProxySQL, audit logs, error reports, and PostgreSQL logical replication

The MCP also covers more specialized operational workflows — for ProxySQL:

• “What are the top queries going through ProxySQL on cluster 3?”
• “Show me the query routing rules on proxy1.example.com.”
• “List the backend servers configured in ProxySQL on proxy1.example.com.”

For audit logs:

• “Show me recent activity on cluster 1.”
• “Who made changes to cluster 3 in the last hour?”
• “Show me all user management events across all clusters.”
• “What did admin do recently?”

For error reports:

• “List error reports for cluster 1.”
• “Generate an error report for cluster 3 — something is behaving oddly.”
• “Download error report #13 for cluster 1 to /tmp/report.tar.gz.”
• “Extract the error report at /tmp/report.tar.gz so I can look at the logs.”

For PostgreSQL logical replication:

• “List the replication publications on cluster 4.”
• “What subscriptions are configured on my PostgreSQL cluster?”

These may not be daily tasks for every operator, but they show how far the MCP has moved beyond basic inventory and alarm checks.

Installing and configuring ClusterControl MCP

Before getting started, make sure you have:

• A running ClusterControl instance with the CMON controller reachable on port 9501
• A CMON user account with access to the clusters you want to manage
• An MCP-compatible AI client, such as Claude Desktop, Claude Code, OpenAI Codex, or another client that supports MCP

Packages are published through the Severalnines repository alongside other ClusterControl components.

For Debian or Ubuntu:

apt-get install clustercontrol-mcp

For RHEL, Rocky Linux, or AlmaLinux:

yum install clustercontrol-mcp

The binary installs to:

/usr/bin/cmon-mcp

The package also installs:

/etc/systemd/system/cmon-mcp.service
/etc/default/cmon-mcp

The service unit is used when running the MCP server as a persistent HTTP service. The environment file stores credentials and transport options.

Choosing a transport mode

ClusterControl MCP supports two main transport modes: stdio and HTTP.

Stdio mode for local use

In stdio mode, the AI client launches cmon-mcp as a local subprocess. This is the simplest setup for individual use with clients such as Claude Desktop or Claude Code.

Example Claude Desktop configuration:

{
  "mcpServers": {
    "clustercontrol": {
      "command": "cmon-mcp",
      "env": {
        "CMON_ENDPOINT": "https://your-cc-host:9501",
        "CMON_USERNAME": "admin",
        "CMON_PASSWORD": "your-password"
      }
    }
  }
}

After restarting Claude Desktop, the MCP server should be available to the client.

For Claude Code:

claude mcp add clustercontrol -- cmon-mcp \
  -endpoint https://your-cc-host:9501 \
  -username admin \
  -password your-password

HTTP mode for Codex, teams, and multi-client access

HTTP mode is better for OpenAI Codex, shared team use, or any scenario where multiple clients need to connect to the same running MCP server.

When MCP_BIND_ADDRESS is set, the server exposes two MCP transports on the same port:

Path	Transport	Typical clients
/sse and /message	SSE	Claude Desktop, Claude Code
/mcp	Streamable HTTP	OpenAI Codex, Claude Code

Example /etc/default/cmon-mcp configuration:

CMON_ENDPOINT=https://127.0.0.1:9501
CMON_USERNAME=admin
CMON_KEY_FILE=/etc/clustercontrol/id_rsa

# Listen on all interfaces so remote clients can connect.
MCP_BIND_ADDRESS=0.0.0.0:3000

# Tell clients to connect using the host's public hostname or IP.
MCP_BASE_URL=http://your-cc-host:3000

# Require a bearer token on all connections.
MCP_AUTH_TOKEN=<your-strong-random-token>

Generate a strong token:

openssl rand -hex 32

Then restart the service:

systemctl restart cmon-mcp
journalctl -u cmon-mcp -n 20

Connect OpenAI Codex using the streamable HTTP endpoint:

codex --mcp-server-uri http://your-cc-host:3000/mcp \
      --mcp-header "Authorization: Bearer <your-token>"

Connect Claude Code using SSE:

claude mcp add clustercontrol --transport sse http://your-cc-host:3000/sse \
  --header "Authorization: Bearer <your-token>"

Connect Claude Desktop using SSE:

{
  "mcpServers": {
    "clustercontrol": {
      "type": "sse",
      "url": "http://your-cc-host:3000/sse",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

Example ClusterControl MCP workflow

Once configured, you interact with ClusterControl MCP through natural language.

For example:

Are there any failed backups across my clusters?

The assistant can list clusters, inspect backup history, filter failed backup jobs, and retrieve the relevant job logs.

A follow-up might be:

Why did the most recent failed backup on cluster 3 fail?

The assistant can inspect the job log and summarize the root cause in plain English.

Then you can ask:

Check whether this cluster has a valid backup schedule and propose a fix.

At this point, the workflow becomes more than read-only troubleshooting. The assistant can inspect existing schedules, compare them with backup history, and propose a corrected schedule or backup command.

If you ask it to make a change, such as:

Create a nightly backup schedule at 02:00 using xtrabackup.

The MCP write-safety flow applies. The assistant should first show a dry-run explanation of what would be created, which cluster it applies to, which backup method will be used, and any high-risk implications. Only after confirmation should it call the tool again with execution enabled.

This is the main operational benefit of the updated MCP: it can help move from “what is wrong?” to “what should we do next?” and, where appropriate, “make that change after I approve it.”

MCP task support for long-running operations

Some operations take longer than a typical request-response cycle. The MCP supports task augmentation for long-running tools such as restore operations and error report generation or download.

Clients that implement MCP task support can start a task, poll for progress, fetch the final result, or cancel the task. Clients that do not support MCP tasks can still use these tools synchronously.

This is particularly useful for support and recovery workflows where the operator wants to start an operation, monitor progress, and retrieve the result without losing the conversational context.

Known limitation: Claude Code tool discovery

Claude Code may not always show every ClusterControl MCP tool when several MCP servers are connected at the same time. This is a client-side discovery limitation caused by a shared tool discovery budget across connected MCP servers.

The tools are still registered and functional on the ClusterControl MCP server side. If tools do not appear in Claude Code, disconnect MCP servers you do not need for the current session, or use Claude Desktop or HTTP mode with Codex, which are not affected in the same way.

Wrapping up

ClusterControl MCP has evolved into a more complete operational interface for AI-assisted database management. It now goes well beyond basic visibility and supports a broad set of day-to-day workflows. Now, operators can ask better questions faster, gather context from ClusterControl more efficiently, and move from diagnosis to approved action without stitching together dashboards, shell commands, SQL queries, and log files manually.

For teams already using ClusterControl, the MCP is a practical way to bring AI into database operations while keeping ClusterControl as the trusted control plane and preserving human approval for sensitive changes. Get a full installation and configuration documentation here.

Not a ClusterControl customer? Get started in minutes: Install ClusterControl directly from this post and streamline your database deployments with a free 30-day Enterprise trial.

ClusterControl Script Installation Instructions

The installer script is the simplest way to get ClusterControl up and running. Run it on your chosen host, and it will take care of installing all required packages and dependencies.

Offline environments are supported as well. See the Offline Installation guide for more details.

On the ClusterControl server, run the following commands:

wget https://severalnines.com/downloads/cmon/install-cc
chmod +x install-cc

With your install script ready, run the command below. Replace S9S_CMON_PASSWORD and S9S_ROOT_PASSWORD placeholders with your choice password, or remove the environment variables from the command to interactively set the passwords. If you have multiple network interface cards, assign one IP address for the HOST variable in the command using HOST=<ip_address>.

S9S_CMON_PASSWORD=<your_password> S9S_ROOT_PASSWORD=<your_password> HOST=<ip_address> ./install-cc # as root or sudo user

After the installation is complete, open a web browser, navigate to https://<ClusterControl_host>/, and create the first admin user by entering a username (note that “admin” is reserved) and a password on the welcome page. Once you’re in, you can deploy a new database cluster or import an existing one.

The installer script supports a range of environment variables for advanced setup. You can define them using export or by prefixing the install command.

See the list of supported variables and example use cases to tailor your installation.

Other Installation Options

Helm Chart

Deploy ClusterControl on Kubernetes using our official Helm chart.

Ansible Role

Automate installation and configuration using our Ansible playbooks.

Puppet Module

Manage your ClusterControl deployment with the Puppet module.

ClusterControl on Marketplaces

Prefer to launch ClusterControl directly from the cloud? It’s available on these platforms:

• DigitalOcean Marketplace
• gridscale.io Marketplace
• Vultr Marketplace
• Linode Marketplace
• Google Cloud Platform