Connect Cloudways to Claude: Monitor Security & Automate Backups

If you need to connect Cloudways to Claude to automate infrastructure management, monitor firewall security, or orchestrate server backups, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and the underlying Cloudways REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on /connect-cloudways-to-chatgpt-manage-servers-app-deployments/ or explore our broader architectural overview on /connect-cloudways-to-ai-agents-scale-infrastructure-update-wp/.

Giving a Large Language Model (LLM) read and write access to a mission-critical infrastructure platform like Cloudways is a high-stakes engineering challenge. You have to handle API key authentication lifecycles, map complex cloud provider nuances to MCP tool definitions, and deal with Cloudways' strictly asynchronous background operations. Every time Cloudways adds a new provider or alters an endpoint payload, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Cloudways, connect it natively to Claude Desktop, and execute complex DevOps workflows using natural language.

The Engineering Reality of the Cloudways API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover and invoke tools, the reality of implementing it against Cloudways' specific API architecture is painful. You are not just integrating a standard CRUD database; you are integrating a control plane that orchestrates virtual machines across AWS, Google Cloud, DigitalOcean, Vultr, and Linode.

If you decide to build a custom MCP server for Cloudways, you own the entire API lifecycle. Here are the specific integration challenges you will face:

The Asynchronous Operation Polling Pattern Almost every mutating action in the Cloudways API - creating a server, taking a backup, changing a setting, or cloning an app - is completely asynchronous. When you send a POST request to create a backup, the API does not wait for the backup to finish. It immediately returns an HTTP 202 with an operation_id. An LLM does not inherently understand this pattern. You must explicitly build tools that teach the model to capture this ID, wait, and continuously poll the get_single_cloudways_operation_by_id endpoint until the status indicates success or failure. If your MCP tools do not strictly define this relationship, the LLM will hallucinate that a backup is finished the second it receives the initial response.

Provider-Specific Payload Fragmentation Cloudways abstracts multiple cloud providers, but the API leaks underlying provider constraints. For example, scaling block storage is only available for DigitalOcean (do), while specific snapshot frequencies are strictly scoped to AWS and Google Compute Engine (gce). When defining an MCP schema for server creation or modification, you cannot present a unified payload. You must build complex conditional schemas that teach the LLM which parameters are valid for which cloud provider, otherwise the model will attempt to attach DigitalOcean block storage to an AWS EC2 instance, resulting in HTTP 422 validation errors.

Destructive Bulk List Updates When managing security rules in Cloudways - like firewall allowlists or MySQL remote access - the API relies on destructive bulk updates rather than granular add/remove endpoints. If you want to add a single IP address to a server's whitelist using the cloudways_server_security_ips_bulk_update endpoint, you must pass the entire existing whitelist along with the new IP. If the LLM passes only the new IP, it will overwrite and lock out all previous administrators. A custom MCP server must implement a read-modify-write wrapper to protect against catastrophic misconfigurations.

How Truto's Managed MCP Server Architecture Works

Truto eliminates the need to manually build and maintain a Cloudways MCP server. When you connect a Cloudways account, Truto dynamically derives a complete suite of MCP tools from the integration's internal configuration and documentation records.

The system derives tool names (e.g., list_all_cloudways_servers), query schemas, and body schemas entirely on-the-fly. A tool only appears in the MCP server if it has a corresponding documentation record acting as a quality gate. This ensures Claude is only exposed to curated, well-defined infrastructure endpoints.

When Claude calls a tool, the arguments arrive as a single flat JSON object. Truto's JSON-RPC router intelligently splits these arguments into query parameters and body parameters based on the specific JSON Schema definitions for that Cloudways method, executing the request through a secure proxy layer.

A critical factual note on rate limits: Truto does not retry, throttle, or apply automatic backoff on rate limit errors. When the upstream Cloudways API returns an HTTP 429 Too Many Requests, Truto immediately passes that error back to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller - in this case, your custom MCP client script or agent framework - is entirely responsible for catching the error, reading the reset headers, and implementing exponential backoff.

Generating the Cloudways MCP Server

You can generate a secure MCP server URL for a connected Cloudways account using either the Truto UI or the Truto REST API.

Method 1: Via the Truto UI

1. Navigate to your Truto dashboard and open the specific Integrated Account page for your connected Cloudways instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can filter the server to only expose read tools, filter by specific operational tags (e.g., security, backups), and set an automatic expiration date.
5. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3...).

Method 2: Via the Truto API

For platform builders automating infrastructure access, you can generate MCP servers programmatically. Send an authenticated POST request to the Truto API.

curl -X POST https://api.truto.one/integrated-account/<ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer <TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Cloudways SecOps Assistant",
    "config": {
      "methods": ["read", "write"],
      "tags": ["security", "servers", "backups"],
      "require_api_token_auth": true
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API validates the tool availability, generates a highly secure cryptographic token, hashes it for storage in a distributed key-value store, and schedules any requested expiration alarms. The response returns your ready-to-use URL.

Connecting the MCP Server to Claude

Once you have your Truto MCP server URL, you must connect it to your AI client. You can do this via the Claude/ChatGPT interfaces or via a manual configuration file for Claude Desktop.

Method A: Via the Claude or ChatGPT UI

For Claude:

1. Open Claude Settings and navigate to Integrations.
2. Click Add MCP Server.
3. Paste your Truto MCP URL into the connection field and click Add.

For ChatGPT:

1. Open ChatGPT Settings, go to Apps, and select Advanced settings.
2. Toggle Developer mode on.
3. Under Custom connectors, click Add new server.
4. Name it "Cloudways Ops" and paste your Truto MCP URL.

Method B: Via Manual Config File

If you are using Claude Desktop and prefer a declarative file-based setup, you must edit your claude_desktop_config.json file. Because standard Claude Desktop configurations expect a local command to spin up a transport bridge, you can use the standard @modelcontextprotocol/server-sse npx wrapper to connect your remote Truto URL to local standard I/O.

{
  "mcpServers": {
    "cloudways-ops": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/<YOUR_SECURE_TOKEN>"
      ]
    }
  }
}

Note: If you enabled require_api_token_auth during generation, your client must be capable of injecting your Truto API token as a Bearer token in the Authorization header of the connection.

Security and Access Control

Giving an AI agent raw access to production infrastructure requires strict guardrails. Truto MCP servers support multiple security layers encoded directly into the connection token:

• Method Filtering: Restrict servers to specific operational categories. Passing methods: ["read"] ensures the LLM can list servers and view monitoring data, but strictly prevents it from scaling disks or restarting services.
• Tag Filtering: Limit the surface area of the API. By applying tags: ["security"], the MCP server will only mount tools related to firewall IPs, SafeUpdates, and bot alerts.
• Expiration (TTL): The expires_at field sets a strict Unix timestamp. Once breached, distributed alarms automatically purge the token from the key-value store, immediately revoking Claude's access.
• Secondary Auth (require_api_token_auth): By default, the cryptographically secure URL acts as a bearer token. Enabling this flag forces the client to also pass a valid Truto API token, ensuring that leaked MCP URLs remain useless without your core platform credentials.

Hero Tools for Cloudways

The Cloudways API exposes massive surface area. Below are the highest-leverage tools Truto auto-generates for managing cloud infrastructure with Claude.

1. list_all_cloudways_servers

Retrieves a complete inventory of all servers connected to your Cloudways account. This is the foundational discovery tool Claude uses to map human-readable server names (like "Production Database") to the numeric server_id required by almost all other tools.

Usage notes: Claude should always call this tool first when a user asks about a server by name. The response includes vital metadata like IP addresses, status, and the specific cloud provider (aws, do, vultr).

"Claude, pull a list of all our active servers. Show me their IP addresses, underlying cloud provider, and current status. Let me know if anything looks offline."

2. create_a_cloudways_manage_backup

Initiates an on-demand server backup operation. Because backups require significant I/O, this is an asynchronous tool.

Usage notes: This tool requires a server_id. It returns an operation_id rather than a finished backup state. You must instruct Claude to capture this ID for status tracking.

"Take an immediate manual backup of the 'Acme Production' server. Give me the operation ID so we can track when it finishes."

3. get_single_cloudways_operation_by_id

Retrieves the current execution status of a background task. This is the mandatory polling mechanism for Cloudways.

Usage notes: Requires the id (the operation_id returned by mutating tools). The response includes is_completed (boolean) and a textual message. Claude should be instructed to loop this tool if a workflow requires waiting for completion.

"Check the status of operation ID 1839284. If it's still running, wait a moment and check again. Let me know the exact message when it completes."

4. update_a_cloudways_safeupdates_setting_by_id

Configures automated WordPress updates (SafeUpdates) for a specific application. It manages the auto-update behavior for core, plugins, and themes, alongside scheduling specific time-slots for maintenance.

Usage notes: Requires server_id and app_id. The payload accepts specific days of the week and hour blocks to ensure updates happen during low-traffic periods.

"Enable SafeUpdates for the main marketing blog app. Schedule the updates to run only on Sundays during the earliest available time slot. Turn on email notifications for successful updates."

5. cloudways_server_security_ips_bulk_update

Manages the allowed or blocked IP addresses at the server firewall level. This allows an AI agent to quickly respond to threats or grant access to new VPN subnets.

Usage notes: Requires server_id, iplist (array of IPs), and mode (allow/deny). Danger: This is a destructive bulk update. The iplist array completely replaces the existing rules. Claude must first read the existing list, append the new IP, and send the combined array back.

"We are seeing malicious traffic from 203.0.113.45. Add that IP to the blocklist for the 'Customer Portal' server immediately. Make sure you don't delete any of the existing blocked IPs."

6. list_all_cloudways_scans

Retrieves the history and results of security scans performed on an application, detailing threats found, quarantined files, and scan durations.

Usage notes: Requires app_id and server_id. Useful for generating automated compliance reports or investigating recent security incidents.

"Pull the security scan history for our e-commerce app over the last week. Were any threats detected or files quarantined? Summarize the findings."

(For the complete inventory of Cloudways operations, schemas, and required parameters, visit the Cloudways integration page.)

Workflows in Action

MCP servers transform isolated API tools into multi-step, autonomous workflows. By chaining read, execute, and polling commands, Claude can operate as an active Site Reliability Engineer.

Workflow 1: Incident Response and Threat Mitigation

When a monitoring alert fires regarding suspicious traffic, an IT admin can ask Claude to investigate the security logs and lock down the infrastructure.

"Claude, check the security scan history for our 'Frontend App'. If you see any recent threats, immediately add the suspected IP to the server's blocklist and run a fresh security scan to confirm we are clean."

Execution Steps:

1. Claude calls list_all_cloudways_servers to resolve "Frontend App" to its server_id and app_id.
2. Claude calls list_all_cloudways_scans to read the recent threat history and extracts the flagged malicious IP address.
3. Claude calls list_all_cloudways_server_security_ips to pull the current array of blocked IPs (crucial to avoid overwriting existing rules).
4. Claude calls cloudways_server_security_ips_bulk_update, passing the combined array of old IPs plus the new malicious IP.
5. Claude calls create_a_cloudways_scan to trigger a new security sweep, outputting the confirmation to the user.

Workflow 2: Pre-deployment Safeguards and Async Polling

Before deploying major application changes, a developer needs absolute certainty that a fresh backup exists.

"Claude, take a full backup of the 'Staging Database' server. Do not proceed until the backup is 100% complete, then let me know it is safe to deploy."

Execution Steps:

sequenceDiagram
    participant User
    participant Claude
    participant TrutoMCP as Truto MCP
    participant Cloudways as Cloudways API

    User->>Claude: "Take backup of Staging Database & wait"
    Claude->>TrutoMCP: Call list_all_cloudways_servers
    TrutoMCP->>Cloudways: GET /server
    Cloudways-->>TrutoMCP: Returns server_id: 9942
    TrutoMCP-->>Claude: JSON Array of servers
    Claude->>TrutoMCP: Call create_a_cloudways_manage_backup (9942)
    TrutoMCP->>Cloudways: POST /manage/backup
    Cloudways-->>TrutoMCP: HTTP 202 { operation_id: 55512 }
    TrutoMCP-->>Claude: operation_id: 55512
    
    loop Async Polling
        Claude->>TrutoMCP: Call get_single_cloudways_operation_by_id (55512)
        TrutoMCP->>Cloudways: GET /operation/55512
        Cloudways-->>TrutoMCP: { is_completed: false }
        TrutoMCP-->>Claude: Status: Running
        Note over Claude: Claude waits internally
    end

    Claude->>TrutoMCP: Call get_single_cloudways_operation_by_id (55512)
    TrutoMCP->>Cloudways: GET /operation/55512
    Cloudways-->>TrutoMCP: { is_completed: true, message: "Success" }
    TrutoMCP-->>Claude: Status: Completed
    Claude->>User: "Backup is complete. Safe to deploy."

Strategic Wrap-Up

Connecting Claude to Cloudways unlocks massive operational leverage for infrastructure teams, but doing it from scratch means owning a heavy maintenance burden. Hand-coding MCP servers means constantly polling for API changes, deciphering asynchronous operation patterns, and managing token infrastructure.

By leveraging a managed MCP architecture, you offload the complexities of JSON-RPC protocol translation, payload mapping, and token lifecycle management. You get immediate, curated, and highly secure AI access to your cloud infrastructure - allowing your team to stop writing integration glue code and start building autonomous, intelligent DevOps workflows.