Enhancing database operations with ClusterControl and Model Context Protocol (MCP)

Organizations are increasingly adopting AI-driven solutions to streamline operations, and there’s growing interest in using AI agents to help manage complex database environments. In theory, these agents can automate monitoring, tuning, and even incident response, analyzing logs, identifying anomalies, and optimizing queries faster than a human operator.

The promise is appealing: an intelligent assistant that keeps your databases healthy and performant around the clock. In practice though, today’s agents can be unpredictable, require a lot of context, and demand significant engineering effort to operate safely around critical infrastructure such as databases. As a result, their potential stunted by the difficulty of making them both safe and effective at scale without heavy human supervision.

This is exactly why we developed a Model Context Protocol (MCP) for ClusterControl; to provide a consistent interface that lets intelligent systems query the right data in context without the guesswork or fragmented discovery process that plagues standalone AI agents.

In this post, I will tell you what an MCP is, explain why it’s often preferable to plain bash scripts when paired with the right tools and limits, how to install one, and give you a few practical examples of how ClusterControl’s can help streamline your daily operational life.

But first, let’s address concerns around AI and privacy and security.

AI and database ops privacy and security concerns

Privacy and security concerns aren’t unique to AI. While the details differ, the risks with AI are similar to other cloud-based tools and are best addressed through a shared responsibility model. For those with the capabilities and requirements, open-source AI tools and models are making it more viable to run AI on their own infrastructure, even offline.

Tools such as MCPs also help further offset some of these concerns — let’s consider our ClusterControl s9s-cli-mcp as an example. First, the AI doesn’t require direct access to the database servers, ClusterControl deals with that part. Likewise, the cloud AI servers don’t require visibility into your ClusterControl credentials, those live in the MCP configuration. The AI tools running on your machine don’t need to pass those them to the cloud at all. Lastly, the calls to ClusterControl are done locally, with only their results being given to the AI. 

Of course, you still need to be careful about those results – they may contain hostnames/IP addresses, cluster configurations, or, as in the case of our examples below, database names. Always make sure all the tools you are using can be trusted with the data they get access to, and consider masking or redacting sensitive identifiers where possible.

Now that we’ve addressed the proverbial elephant in the room, let’s dive into MCPs.

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

It is crucial for AI agents to be able to interact with the world, which is accomplished with RAG (retrieval-augmented generation) and function-calling. RAG enables them to retrieve information – it’s like accessing books from a library; while function-calling provides them the added ability to actually change something and check the results – kind of like having eyes and hands.

Model Context Protocol (MCP) provides these tools to the agents. In our specific context, it lets us define reliable ways to access information about database clusters from ClusterControl while keeping the user-friendly and universal way to communicate using natural language with AI. You may be thinking, “Why would I introduce this dependency set when I can use base scripts?”

The point isn’t that you can do things you otherwise couldn’t without AI, it’s that those things that you could do are much more efficient, potentially saving time and money, with AI. Yes, traditional scripts can do a lot of things but are brittle and require you to anticipate specific issues. And yes, AI requires additional tools and limits, but it can handle ambiguity and address a larger problem set. It’s also often easier and faster to prompt the AI than it is to develop the scripts.

N.B. Even with MCP, AI agents don't replace operational judgment — MCP gives you a safer, more structured integration, not a license to run fully autonomous ops.

Now that we understand what MCPs are and their utility in database ops, let’s look at the ClusterControl MCP’s current capabilities, its installation and a few example prompts. 

Current ClusterControl MCP capabilities

Here’s what the current ClusterControl MCP can actually do on your behalf. You can find the full, up-to-date list of MCP tools and parameters in the GitHub repository, but this set already covers the most important “read and reason” workflows for day-to-day operations:

Inspect the ClusterControl environment

• s9s_version – Check which ClusterControl CLI version is in use (s9s --version).
• s9s_help – Retrieve the CLI help output (s9s --help), which the agent can use as a “capability catalog.”

Discover clusters, nodes, and databases

• cluster_list – List all managed clusters in JSON form, with optional flags for filtering and detail.
• node_list – List nodes across clusters (s9s node --list --print-json), including roles and basic health indicators.
• database_list – List databases for a given cluster and their details, enabling the AI to reason about what actually needs to be backed up, monitored, or investigated.
• cluster_list_config – Fetch configuration details for a specific cluster (e.g. topology, settings) via --cluster-id.

Review jobs, backups, and schedules

• job_list – List recent and active jobs (backups, maintenance tasks, etc.) with optional flags for status, time windows, and more.
• job_log – Retrieve detailed logs for a specific job ID, which is key for root-cause analysis.
• backup_list – List backups (optionally filtered by clusterId) to see what exists, what succeeded, and what failed.
• schedules_backups_list – List configured backup schedules in JSON, so the AI can reason about backup coverage and cadence.

Inspect access and alarms

• accounts_list – List accounts associated with a specific cluster, including roles and permissions (--cluster-id=ID --long).
• alarms_list – List alarms for a given cluster, including severity, component, and message.

Installing and configuring the MCP

The MCP needs to be configured in an AI chat / agent tool with MCP support, e.g. VSCode, Claude Code, etc. Thanks to standardization efforts, most MCPs are very easy to install. With some of them you can even use a prompt to the AI to make it configure its MCPs. Most AI chat/agent tools contain a json configuration file that looks something like this example:

{
  "mcpServers": {
    "s9s-cli-docker-inline": {
      "command": "docker",
      "args": [
        "run",
        "--rm", 
        "-i",
        "-e", "CC_HOST=your.clustercontrol.host",
        "-e", "CC_PORT=9501", 
        "-e", "CC_USER=your_username",
        "-e", "CC_PASS=your_password",
        "severalnines/s9s-cli-mcp:latest"
      ],
      "description": "s9s CLI MCP server with inline environment variables"
    }
  }
}

Example ClusterControl MCP database ops workflow

Now you just talk to the AI normally. Here’s a transcript of a very easy example conversation:

PROMPT: Are there any alarms in my clusters?

I'll check for alarms in your clusters.

> Ran List clusters - s9s-cli-mcp

Now let me check the alarms for this cluster:

> Ran List alarms - s9s-cli-mcp

Yes, there is 1 critical alarm in your clusters:

Cluster: ft-py-postgres-3332362 (ID: 94)

Title: Backup Failed
Severity: CRITICAL
Message: Server pytest-test-rockylinux-8-1-con1 reports: Backup failed.
Recommendation: Backup failed, check Logs → Jobs messages and Backup → Reports. For streaming backups ports 9990-9999 (default) must be open.
Created: 2025-11-12 19:50:45 UTC
Component: Backup
The alarm indicates a backup failure on one of your PostgreSQL cluster nodes. You should check the job logs and backup reports to investigate the issue.

PROMPT: Find out why there’s the alarm

I'll investigate the backup failure alarm by checking the job logs and backup reports.

> Ran List jobs - s9s-cli-mcp
> Ran List backups by cluster - s9s-cli-mcp

Found it! I can see job 7737 failed. Let me get the detailed logs for that failed backup job:

> Ran Get job log - s9s-cli-mcp

Root Cause Found
The backup alarm was triggered because job 7737 failed while trying to create a partial backup. The failure occurred because:

Database "d1" does not exist

The backup job was configured to create a partial backup with:

Include databases: d1
Include tables: testtabletable1
However, when pg_dump tried to connect to database "d1" on the PostgreSQL server at 10.162.17.72:5432, it failed with:
pg_dump: error: connection to server on socket "/run/postgresql/.s.PGSQL.5432" failed:
FATAL: database "d1" does not exist
Summary:

Someone or some automated test tried to backup a non-existent database called "d1" with a table "testtabletable1"
The backup was titled "partialbackup1"
This appears to be a test backup that referenced a database that was either never created or was already dropped
The backup job failed immediately at 2025-11-12 19:50:45 UTC
The system correctly cleaned up the failed backup directory
Resolution: The alarm can be cleared once you verify that this was an intentional test or accidental backup request for a non-existent database. If database "d1" should exist, you'll need to create it before running the backup again.

As you can see from the conversation, the agent was able to thoroughly yet quickly investigate the issues until it had all the information it needed to analyze the root cause and determine that it’s actually not a critical issue but rather just someone messing around, with little to no effort or input from the user. Meanwhile, all of the critical information is maintained by ClusterControl. 

The benefit is clear: the AI provides an efficient way to execute a multi-step workflow via native language prompts instead of requiring ops personnel to do that work manually or writing many complicated scripts. Thanks to this, maintaining your own DB clusters is easier than ever.

The agent can be even more useful. Here’s an example of a still simple, slightly smarter prompt:

PROMPT: Check my clusters for any issues, analyse them and propose solutions

I'll help you check your clusters for issues. Let me start by listing your clusters to see what we're working with.

> Ran List clusters - s9s-cli-mcp

Now let me check for alarms on this cluster:

> Ran List alarms - s9s-cli-mcp

Let me check the job logs to see what caused the backup failure:

Let me check the available backup information:

> Ran List backups by cluster - s9s-cli-mcp

Now let me check the job log for the failed backup:

> Ran Get job log - s9s-cli-mcp

Let me also check the databases available on the cluster:

Let me check the nodes to see their health:

Cluster Analysis Summary
I've analyzed your PostgreSQL cluster (ID: 10, name: "psql") and found the following:

✅ Good News:
Cluster Status: Running and operational (STARTED)
All nodes are online and healthy:
PostgreSQL master node (10.162.17.218:5432) - PostgreSQL 17.5
Controller node (10.162.17.193:9500) - CMON 2.3.4
Prometheus monitoring node (10.162.17.193:9090) - active
Hardware resources: Adequate (8 CPU cores, 4GB RAM per host)
License: Valid (expires in 399 days)
Previous backups: 2 successful backups exist (BACKUP-1, BACKUP-12)

⚠️ Critical Issue Found:
Backup Failure (CRITICAL alarm)

Job ID: 7773
Backup Title: "pgdump_test"
Failed at: 2025-11-26 15:24:16
Root Cause: Attempting to backup database "admindb" which does not exist
Error: database "admindb" does not exist
📋 Proposed Solutions:
Solution 1: Fix the Backup Configuration
Since the "admindb" database doesn't exist, you have two options:

a) Remove the non-existent database from backup configuration:

Edit or recreate the backup job to exclude "admindb"
Only backup databases that actually exist (like "postgres")
b) Create the missing database (if it's supposed to exist):

Solution 2: Verify Existing Databases
Before configuring backups, you should list all available databases on your PostgreSQL cluster to ensure backup configurations reference valid databases.

Solution 3: Test Backup with Known Databases
Create a new backup job targeting databases that exist (e.g., "postgres" which was successfully backed up in BACKUP-12).

🔧 Immediate Action:
The most straightforward fix is to avoid backing up the non-existent "admindb" database. Either:

Remove "admindb" from the backup configuration
Backup all databases using pgdumpall without specifying individual databases
Create the "admindb" database if it's required for your application
Would you like me to help you create a corrected backup configuration or investigate further?

This shows the huge difference every little bit of effort gives when creating a prompt. Same tools, same natural language, still very simple. The prompt is vague enough to let the AI deal with many kinds of bad situations, but specific enough to let it know it should do the work to analyze what’s happening and why — the kind of root cause analysis that normally takes most time.

I merely told the AI to do more, and it did everything, saving time and money. The combination of powerful AI and reliable tools can exponentially enhance productivity when used deliberately.

Wrapping up

Incorporating AI into key operational workflows is a matter of when, not if. ClusterControl’s s9s-cli-mcp is a case in point for using current tools to enable the deliberate, conservative use of AI agents to help streamline visibility into and troubleshooting of your database infrastructure.

If you’re using ClusterControl, adding s9s-cli-mcp is a low-risk way to start experimenting with AI-assisted ops in a controlled, auditable manner. Download it from the Docker hub for containerized deployments or get the instructions through the official GitHub repository.

If you’re not a CC 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