cloudways-mcp-x-6

原始内容

---
name: cloudways-mcp
version: 1.4.0
license: MIT
description: |
  Operational guide for managing Cloudways servers and applications, across one or several Cloudways accounts, via the official Cloudways MCP server (Cloudways' hosted MCP / Remote MCP, per their support docs).
  Use whenever the user mentions Cloudways, a Cloudways server or app, server monitoring, app monitoring, bandwidth, disk usage, PHP/MySQL/traffic analytics, Varnish cache, app cloning, backups/restore on Cloudways, Git deployments on Cloudways, SSL/Let's Encrypt on Cloudways, malware scans / Security Suite, staging sync, team members, AgencyOS client billing, or running an audit/onboarding on a Cloudways-hosted client site.
  Any write operation (start/stop/restart server, backup, restore, update CNAME, purge cache, change service state, git pull, SSL install/revoke, IP whitelist update, staging sync, team/billing changes, delete server/app) requires explicit confirmation of target server/app and intended action before execution.
---

# Cloudways MCP — Operational Skill

Managing Cloudways infrastructure through the Cloudways MCP server.

> **Connection:** This skill targets the **official Cloudways (Remote) MCP** — an MCP hosted by Cloudways at `https://mcp.cloudways.com/mcp/` that you connect to directly. The source of truth for connecting is the **official article**: `support.cloudways.com/en/articles/14654372`. See `references/installation.md`.
>
> **Tool names match the official articles.** The tool catalog and workflows in this skill use the official Cloudways MCP tool names (verified against the setup article and the dedicated [tools article](https://support.cloudways.com/en/articles/15798823-cloudways-mcp-server-tools)). Always treat the live `mcp__cloudways*__*` tools as the source of truth if Cloudways changes them (see "Versioning and source of truth" below).

> **Context:** The skill is built for day-to-day work managing clients/environments on Cloudways — monitoring, routine maintenance, onboarding/audit for new clients, and automations. All monetary values reported by the API are in $ (USD), not ₪.

---

## Quick Route

| Intent | Load |
|--------|------|
| Initial installation/configuration of the MCP server | `references/installation.md` |
| Don't know which tool exists / searching for a tool by name | `references/tools-catalog.md` |
| Monitoring, status check, bandwidth, analytics | `references/workflows-monitoring.md` |
| Cache clear, SSL, backup, restart, IP whitelist | `references/workflows-maintenance.md` |
| New audit / onboarding a new client | `references/workflows-onboarding.md` |
| Building an automated workflow for n8n/Make/Claude Code | `references/workflows-automation.md` |
| Multiple Cloudways accounts / multi-account configuration | `references/installation.md` (Multi-account section) |

**Load only what's needed.** Maximum 2-3 references per task. If the user just asks "show me my servers", don't load the entire catalog — call `server_list` directly.

---

## Safety rules (read before every operation)

1. **Selecting the correct account — before anything else (multi-account).** There are **multiple Cloudways accounts**, each as a separate MCP connection with its own prefix (e.g. `mcp__cloudways-clientA__*`). Before every call — verify which account it belongs to. If more than one account is connected and it's not clear from context which one is meant — **stop and ask**, don't guess. server/app IDs are **not interchangeable between accounts** — ID 1234567 in account A is an entirely different resource (or nonexistent) in account B. Don't take an ID from one account's response and run it against another account. See the "Multi-account" section below.

2. **Write operations require explicit confirmation.** Before every call to a tool that belongs to the Write category (see list below), present to the user: **the account**, the tool name, the target server/application (ID + name), the parameters, the expected impact. Wait for a confirmation response before executing. Don't assume that confirming one operation grants confirmation for further operations — nor that confirmation on one account applies to another.

3. **Backup before a significant change.** Before `app_restore`, `app_delete`, `varnish_manage`, `varnish_app_manage`, or any configuration change — check with the user whether a recent backup exists. If not, offer to run `app_backup` / `server_backup` first.

4. **Multiple services = multiplied risk.** Cloudways usually hosts **several applications on the same server**. `server_stop`, `server_restart`, or `server_delete` affects **all** the applications. Always make sure the user is aware of the list of applications on the server before a server-level operation.

5. **`server_delete`, `app_delete`, and `app_cname_delete` = immediate destruction in production.** Requires double confirmation (W!): of both the operation and the specific domain/application/server.

6. **Credentials.** Each account authenticates with its own **Access Token** (case-sensitive `X-Access-Token` header; roles + legacy-key migration in the Authentication section below). Don't print tokens in responses. Don't mix credentials between accounts. If the user asks to see them, refer them to platform.cloudways.com → API section.

7. **Read-only by default.** If the user just asks "show me / check / monitor" — always choose the appropriate read-only tool. Don't suggest a destructive operation unless the user explicitly asked for it.

8. **`execute_tool` / toolset-proxy calls inherit their target tool's R/W/W! risk.** Most tools live in on-demand toolsets and are invoked through the `execute_tool` proxy (or surfaced via `get_toolset_tools`). Calling a write/destructive tool through the proxy is exactly as consequential as calling it directly — apply the **same** confirmation (and double-confirmation for W!) as you would for the named tool.

---

## Write operations require confirmation — the catalog is authoritative

**The authoritative list is `references/tools-catalog.md`: every tool flagged `W` or `W!` there requires explicit confirmation before execution, and every `W!` requires the double-confirmation pattern.** The grouping below is **illustrative, not exhaustive** — the live MCP (v1.2) exposes 244 tools — 241 across 22 toolsets plus 3 meta-tools — and 179 of them are **not** in your default tool list. If a tool is not named here but is flagged `W`/`W!` in the catalog (or its live schema describes a destructive/irreversible action), it needs the **same** confirmation. Never treat "it's not in this list" as "it's safe to run without confirmation."

**Server level (affects all applications on the server):**
- `server_start`, `server_stop`, `server_restart`
- `server_delete` ⚠️⚠️ (W! — immediate destruction)
- `server_scale` ⚠️ (W! — resize CPU/RAM with brief downtime for every app on the server)
- `server_backup`, `server_backup_settings_update`, `server_snapshot_frequency_update`
- `server_local_backup_delete` ⚠️ (W! — permanently deletes local backup snapshots)
- `server_package_update` (W! for the uninstall variant — removes a package + its data)
- `server_master_username_update`, `server_master_password_update` ⚠️ (W! — old SSH/SFTP creds stop working immediately)
- `service_start`, `service_stop`, `service_restart` (Apache/Nginx/Memcached/MySQL/Varnish)
- `varnish_manage`

**App level:**
- `app_create`, `app_clone`, `app_clone_to_server`, `staging_app_clone`, `staging_app_clone_to_server` (create new copies — consume resources)
- `app_backup`, `app_restore` ⚠️⚠️ (W! — full overwrite of current state)
- `app_restore_rollback` ⚠️ (W! — overwrites current state with the pre-restore copy; only within the rollback window)
- `app_local_backup_delete` ⚠️ (W! — permanently deletes the local pre-restore snapshot)
- `app_delete` ⚠️⚠️ (W! — immediate destruction)
- `app_db_password_update`, `app_admin_password_update`, `app_credentials_update`, `app_credentials_delete` ⚠️ (W! — old credentials stop working immediately)
- `app_enforce_https_update`, `app_stack_update`, `app_reset_permissions`, `app_wp_multisite_update`
- `app_cname_update`, `app_cname_delete` ⚠️ (W! — can break production)
- `app_purge_cache`, `varnish_app_manage`

**DNS / Projects / SSH keys (live via their toolsets):**
- `dns_made_easy_delete_domains`, `dns_made_easy_delete_records` ⚠️ (W! — DNS records/domains gone; can break mail + site resolution)
- `project_delete` ⚠️ (W! — ungroups the project)
- `ssh_key_delete` ⚠️ (W! — revokes SSH/SFTP access immediately)

**Add-ons:**
- `addon_activate`, `addon_activate_on_server`, `addon_deactivate`, `addon_deactivate_on_server` (W — can change the account subscription / incur cost)

**Security — SSL & IP access (new in MCP v1.2):**
- `security_lets_encrypt_install`, `security_lets_encrypt_renew`, `security_lets_encrypt_auto_renewal`
- `security_lets_encrypt_revoke`, `security_remove_own_ssl` ⚠️ (W! — HTTPS breaks until a new cert is installed)
- `security_update_whitelisted_ips` ⚠️ (W! — **replaces** the SSH/SFTP or MySQL whitelist; a wrong list locks people out — always read the current list first)
- `security_whitelist_ip_siab`, `security_whitelist_ip_adminer`

**Security Suite / staging / team / transfer (new in MCP v1.2):**
- `security_suite_app_files_restore` ⚠️ (W! — restoring quarantined files can put malware back on the live site)
- `security_suite_server_countries_blacklist_update` ⚠️ (W! — blocks all traffic from entire countries)
- `staging_sync_tables`, `staging_sync_code` ⚠️ (W! — overwrite data/code on the target; confirm **direction** — a push to live overwrites production)
- `team_member_update`, `team_member_delete` ⚠️ (W! — changes/revokes a person's access)
- `server_transfer_request` ⚠️ (W! — hands server **ownership** to another Cloudways account)
- `agency_os_*` create/update (W — client-facing financial records: clients, services, plan prices, tax rates, invoices)
- `agency_os_client_delete` ⚠️ (W! — deletes a client-facing financial record, archiving their services + invoice history)
- `copilot_subscribe`, `copilot_plan_change`, `addon_upgrade` (W — change the account's subscription cost)

**Git deployment:**

- `git_clone`, `git_pull` (can break production if there's a conflict)
- `git_generate_key` ⚠️ (W! — overwrites the app's existing deploy key; the old key stops working)

---

## Confirmation pattern for a destructive operation

Before execution, present a block like this:

```
🔒 Confirm operation execution?
   Account: clientA (mcp__cloudways-clientA)
   Tool: server_stop
   Server: production-shop-il (ID: 1234567)
   Applications affected: woocommerce-prod, staging-clone, admin-tools
   Impact: all 3 applications will be offline until a manual restart
   Proceed? (yes / no / pause and check backup first)
```

Wait for an explicit response. A literal "yes" only = confirmation. Implied consent is not enough. The **account line is mandatory** when more than one account is connected — it prevents executing an operation on the wrong account.

---

## Authentication — quick overview

The official MCP is hosted at `https://mcp.cloudways.com/mcp/` and authenticates via two **case-sensitive** HTTP headers:

- `X-Access-Token` — a Cloudways **Access Token** generated in the platform
- `X-Mcp-Host` — the client identifier (`claude-code` / `claude-desktop`; full list of official values in `references/installation.md`)

Tokens are **role-based (RBAC)**: **READ** (look-ups only), **LIMITED** (selected endpoint groups), **FULL ACCESS** (everything, including destructive actions). Start new integrations with READ and escalate only when a connection must write. This platform-level control **complements** (does not replace) this skill's write-confirmation discipline — even FULL ACCESS has no per-tool gating at the MCP layer.

> **Legacy:** the old `X-CW-Email` + `X-CW-Api-Key` API-key headers are deprecated — the API key stops working on **October 15, 2026** — and until migrated such connections retain unrestricted full-account access. Migration: `references/installation.md`.

Treat tokens like passwords and **never print them in responses**. If the user asks to see one, refer them to platform.cloudways.com.

For the full connection, role guidance, and multi-account setup, see `references/installation.md`.

---

## Multi-account — working with multiple Cloudways accounts

There are usually **multiple Cloudways accounts** (different clients / different environments). Each account is connected as a **separate** MCP connection with its own credentials, and therefore appears in Claude with **its own prefix**:

```
mcp__cloudways-clientA__server_list
mcp__cloudways-clientB__server_list
mcp__cloudways-internal__server_list
```

> The configuration (how multiple accounts are connected — one connection per account, each with its own credentials) is documented in `references/installation.md` section **Multi-account configuration**. The runtime rules are here.

### The golden rule: identify the account before every operation

1. **A single account connected** → use it, no need to ask.
2. **Multiple accounts connected** → determine which account the request belongs to **before** you call a tool:
   - If the user explicitly specified a client/account ("check clientB's prod") → use the matching connection.
   - If the server/domain name unambiguously identifies a single account → you may infer, but explicitly state which account you're operating on.
   - If **it's unclear** → stop and ask: "Which account? (clientA / clientB / internal)". Don't guess, and don't run on all of them "just to be safe".

### Complete isolation between accounts

- **IDs don't cross accounts.** A server_id / app_id you received from `mcp__cloudways-clientA` is valid **only** against clientA. Never take an ID from one account's response and pass it to a tool of another connection.
- **Per-account confirmation.** A write confirmation on one account does not apply to another. Every write operation on a new account = a new confirmation block (including the account line).
- **Credentials don't mix.** Each connection has its own Access Token. Don't assume the same credentials work on another account.

### Cross-account search (read only)

When the user asks for something broad — "which account does the domain shop.example.co.il live on?", "give me a disk overview for all accounts" — it's permitted and legitimate to **read (read-only)** from all the connections, but:
- Run the same sequence of reads on each connection **separately**, and tag each result with the account name.
- Summarize in a table with a clear "Account" column.
- **Never** perform a broad write operation across multiple accounts without individual confirmation for each one.

```
Example tagging in the response:
| Account  | Server           | disk |
|----------|------------------|------|
| clientA  | prod-shop-il     | 87%  |
| clientB  | prod-blog        | 41%  |
| internal | ops-tools        | 63%  |
```

---

## Common usage patterns (examples)

### Quick snapshot of an account
```
1. server_list               → list of all servers
2. copilot_insights_list     → active insights/alerts
```

(No account/whoami tool exists — infer the account from the connection prefix + `server_list`.)

### Health check before a weekend (production client)
```
1. server_get                   → CPU/RAM/disk
2. monitoring_server_graph      → metrics (CPU/mem/etc.)
3. monitoring_app_summary       → for each application
4. copilot_insights_list        → open insights/alerts
5. monitoring_server_summary    → disk/bandwidth; if disk > 80% — red flag
```

### Checking an app's details
```
1. app_list                  → find the app
2. app_get                   → details, FQDN, config
```

(SSL / Let's Encrypt **is** an MCP tool as of v1.2 — `security_lets_encrypt_install` / `_renew` / `_auto_renewal` / `_revoke`, via the security toolset. Install/renew are W; revoke is W!.)

For more detailed patterns, load the relevant workflows.

---

## Versioning and source of truth

- **Tool names match the official articles.** The tool names and categories in this catalog are **verified** against the official Cloudways support articles (setup + tools reference, MCP v1.2). They are the official MCP tool names. The v1.2 additions have not yet been re-enumerated against the live server — see the note in `references/tools-catalog.md`.
- **The live MCP remains the source of truth if Cloudways changes them.** If a tool name or capability differs from what's documented here, the live list of tools connected in Claude (`mcp__cloudways*__*`) wins — check it and update the catalog accordingly.
- **Every write tool still goes through the confirmation pattern.** W = single confirmation, W! = double-confirmation (destructive — e.g. `server_delete`, `app_delete`, `app_restore`, `app_cname_delete`), per `references/tools-catalog.md`. This discipline is **more** important now that the official destructive tools are confirmed to exist.

name: cloudways-mcp version: 1.4.0 license: MIT description: | Operational guide for managing Cloudways servers and applications, across one or several Cloudways accounts, via the official Cloudways MCP server (Cloudways' hosted MCP / Remote MCP, per their support docs). Use whenever the user mentions Cloudways, a Cloudways server or app, server monitoring, app monitoring, bandwidth, disk usage, PHP/MySQL/traffic analytics, Varnish cache, app cloning, backups/restore on Cloudways, Git deployments on Cloudways, SSL/Let's Encrypt on Cloudways, malware scans / Security Suite, staging sync, team members, AgencyOS client billing, or running an audit/onboarding on a Cloudways-hosted client site. Any write operation (start/stop/restart server, backup, restore, update CNAME, purge cache, change service state, git pull, SSL install/revoke, IP whitelist update, staging sync, team/billing changes, delete server/app) requires explicit confirmation of target server/app and intended action before execution.

Cloudways MCP — Operational Skill

Managing Cloudways infrastructure through the Cloudways MCP server.

Connection: This skill targets the official Cloudways (Remote) MCP — an MCP hosted by Cloudways at https://mcp.cloudways.com/mcp/ that you connect to directly. The source of truth for connecting is the official article: support.cloudways.com/en/articles/14654372. See references/installation.md.

Tool names match the official articles. The tool catalog and workflows in this skill use the official Cloudways MCP tool names (verified against the setup article and the dedicated tools article). Always treat the live mcp__cloudways*__* tools as the source of truth if Cloudways changes them (see "Versioning and source of truth" below).

Context: The skill is built for day-to-day work managing clients/environments on Cloudways — monitoring, routine maintenance, onboarding/audit for new clients, and automations. All monetary values reported by the API are in $ (USD), not ₪.

Quick Route

Intent	Load
Initial installation/configuration of the MCP server	`references/installation.md`
Don't know which tool exists / searching for a tool by name	`references/tools-catalog.md`
Monitoring, status check, bandwidth, analytics	`references/workflows-monitoring.md`
Cache clear, SSL, backup, restart, IP whitelist	`references/workflows-maintenance.md`
New audit / onboarding a new client	`references/workflows-onboarding.md`
Building an automated workflow for n8n/Make/Claude Code	`references/workflows-automation.md`
Multiple Cloudways accounts / multi-account configuration	`references/installation.md` (Multi-account section)

Load only what's needed. Maximum 2-3 references per task. If the user just asks "show me my servers", don't load the entire catalog — call server_list directly.

Safety rules (read before every operation)

Selecting the correct account — before anything else (multi-account). There are multiple Cloudways accounts, each as a separate MCP connection with its own prefix (e.g. mcp__cloudways-clientA__*). Before every call — verify which account it belongs to. If more than one account is connected and it's not clear from context which one is meant — stop and ask, don't guess. server/app IDs are not interchangeable between accounts — ID 1234567 in account A is an entirely different resource (or nonexistent) in account B. Don't take an ID from one account's response and run it against another account. See the "Multi-account" section below.
Write operations require explicit confirmation. Before every call to a tool that belongs to the Write category (see list below), present to the user: the account, the tool name, the target server/application (ID + name), the parameters, the expected impact. Wait for a confirmation response before executing. Don't assume that confirming one operation grants confirmation for further operations — nor that confirmation on one account applies to another.
Backup before a significant change. Before app_restore, app_delete, varnish_manage, varnish_app_manage, or any configuration change — check with the user whether a recent backup exists. If not, offer to run app_backup / server_backup first.
Multiple services = multiplied risk. Cloudways usually hosts several applications on the same server. server_stop, server_restart, or server_delete affects all the applications. Always make sure the user is aware of the list of applications on the server before a server-level operation.
server_delete, app_delete, and app_cname_delete = immediate destruction in production. Requires double confirmation (W!): of both the operation and the specific domain/application/server.
Credentials. Each account authenticates with its own Access Token (case-sensitive X-Access-Token header; roles + legacy-key migration in the Authentication section below). Don't print tokens in responses. Don't mix credentials between accounts. If the user asks to see them, refer them to platform.cloudways.com → API section.
Read-only by default. If the user just asks "show me / check / monitor" — always choose the appropriate read-only tool. Don't suggest a destructive operation unless the user explicitly asked for it.
execute_tool / toolset-proxy calls inherit their target tool's R/W/W! risk. Most tools live in on-demand toolsets and are invoked through the execute_tool proxy (or surfaced via get_toolset_tools). Calling a write/destructive tool through the proxy is exactly as consequential as calling it directly — apply the same confirmation (and double-confirmation for W!) as you would for the named tool.

Write operations require confirmation — the catalog is authoritative

The authoritative list is references/tools-catalog.md: every tool flagged W or W! there requires explicit confirmation before execution, and every W! requires the double-confirmation pattern. The grouping below is illustrative, not exhaustive — the live MCP (v1.2) exposes 244 tools — 241 across 22 toolsets plus 3 meta-tools — and 179 of them are not in your default tool list. If a tool is not named here but is flagged W/W! in the catalog (or its live schema describes a destructive/irreversible action), it needs the same confirmation. Never treat "it's not in this list" as "it's safe to run without confirmation."

Server level (affects all applications on the server):

server_start, server_stop, server_restart
server_delete ⚠️⚠️ (W! — immediate destruction)
server_scale ⚠️ (W! — resize CPU/RAM with brief downtime for every app on the server)
server_backup, server_backup_settings_update, server_snapshot_frequency_update
server_local_backup_delete ⚠️ (W! — permanently deletes local backup snapshots)
server_package_update (W! for the uninstall variant — removes a package + its data)
server_master_username_update, server_master_password_update ⚠️ (W! — old SSH/SFTP creds stop working immediately)
service_start, service_stop, service_restart (Apache/Nginx/Memcached/MySQL/Varnish)
varnish_manage

App level:

app_create, app_clone, app_clone_to_server, staging_app_clone, staging_app_clone_to_server (create new copies — consume resources)
app_backup, app_restore ⚠️⚠️ (W! — full overwrite of current state)
app_restore_rollback ⚠️ (W! — overwrites current state with the pre-restore copy; only within the rollback window)
app_local_backup_delete ⚠️ (W! — permanently deletes the local pre-restore snapshot)
app_delete ⚠️⚠️ (W! — immediate destruction)
app_db_password_update, app_admin_password_update, app_credentials_update, app_credentials_delete ⚠️ (W! — old credentials stop working immediately)
app_enforce_https_update, app_stack_update, app_reset_permissions, app_wp_multisite_update
app_cname_update, app_cname_delete ⚠️ (W! — can break production)
app_purge_cache, varnish_app_manage

DNS / Projects / SSH keys (live via their toolsets):

dns_made_easy_delete_domains, dns_made_easy_delete_records ⚠️ (W! — DNS records/domains gone; can break mail + site resolution)
project_delete ⚠️ (W! — ungroups the project)
ssh_key_delete ⚠️ (W! — revokes SSH/SFTP access immediately)

Add-ons:

addon_activate, addon_activate_on_server, addon_deactivate, addon_deactivate_on_server (W — can change the account subscription / incur cost)

Security — SSL & IP access (new in MCP v1.2):

security_lets_encrypt_install, security_lets_encrypt_renew, security_lets_encrypt_auto_renewal
security_lets_encrypt_revoke, security_remove_own_ssl ⚠️ (W! — HTTPS breaks until a new cert is installed)
security_update_whitelisted_ips ⚠️ (W! — replaces the SSH/SFTP or MySQL whitelist; a wrong list locks people out — always read the current list first)
security_whitelist_ip_siab, security_whitelist_ip_adminer

Security Suite / staging / team / transfer (new in MCP v1.2):

security_suite_app_files_restore ⚠️ (W! — restoring quarantined files can put malware back on the live site)
security_suite_server_countries_blacklist_update ⚠️ (W! — blocks all traffic from entire countries)
staging_sync_tables, staging_sync_code ⚠️ (W! — overwrite data/code on the target; confirm direction — a push to live overwrites production)
team_member_update, team_member_delete ⚠️ (W! — changes/revokes a person's access)
server_transfer_request ⚠️ (W! — hands server ownership to another Cloudways account)
agency_os_* create/update (W — client-facing financial records: clients, services, plan prices, tax rates, invoices)
agency_os_client_delete ⚠️ (W! — deletes a client-facing financial record, archiving their services + invoice history)
copilot_subscribe, copilot_plan_change, addon_upgrade (W — change the account's subscription cost)

Git deployment:

git_clone, git_pull (can break production if there's a conflict)
git_generate_key ⚠️ (W! — overwrites the app's existing deploy key; the old key stops working)

Confirmation pattern for a destructive operation

Before execution, present a block like this:

🔒 Confirm operation execution?
   Account: clientA (mcp__cloudways-clientA)
   Tool: server_stop
   Server: production-shop-il (ID: 1234567)
   Applications affected: woocommerce-prod, staging-clone, admin-tools
   Impact: all 3 applications will be offline until a manual restart
   Proceed? (yes / no / pause and check backup first)

Wait for an explicit response. A literal "yes" only = confirmation. Implied consent is not enough. The account line is mandatory when more than one account is connected — it prevents executing an operation on the wrong account.

Authentication — quick overview

The official MCP is hosted at https://mcp.cloudways.com/mcp/ and authenticates via two case-sensitive HTTP headers:

X-Access-Token — a Cloudways Access Token generated in the platform
X-Mcp-Host — the client identifier (claude-code / claude-desktop; full list of official values in references/installation.md)

Tokens are role-based (RBAC): READ (look-ups only), LIMITED (selected endpoint groups), FULL ACCESS (everything, including destructive actions). Start new integrations with READ and escalate only when a connection must write. This platform-level control complements (does not replace) this skill's write-confirmation discipline — even FULL ACCESS has no per-tool gating at the MCP layer.

Legacy: the old X-CW-Email + X-CW-Api-Key API-key headers are deprecated — the API key stops working on October 15, 2026 — and until migrated such connections retain unrestricted full-account access. Migration: references/installation.md.

Treat tokens like passwords and never print them in responses. If the user asks to see one, refer them to platform.cloudways.com.

For the full connection, role guidance, and multi-account setup, see references/installation.md.

Multi-account — working with multiple Cloudways accounts

There are usually multiple Cloudways accounts (different clients / different environments). Each account is connected as a separate MCP connection with its own credentials, and therefore appears in Claude with its own prefix:

mcp__cloudways-clientA__server_list
mcp__cloudways-clientB__server_list
mcp__cloudways-internal__server_list

The configuration (how multiple accounts are connected — one connection per account, each with its own credentials) is documented in references/installation.md section Multi-account configuration. The runtime rules are here.

The golden rule: identify the account before every operation

A single account connected → use it, no need to ask.
Multiple accounts connected → determine which account the request belongs to before you call a tool:
- If the user explicitly specified a client/account ("check clientB's prod") → use the matching connection.
- If the server/domain name unambiguously identifies a single account → you may infer, but explicitly state which account you're operating on.
- If it's unclear → stop and ask: "Which account? (clientA / clientB / internal)". Don't guess, and don't run on all of them "just to be safe".

Complete isolation between accounts

IDs don't cross accounts. A server_id / app_id you received from mcp__cloudways-clientA is valid only against clientA. Never take an ID from one account's response and pass it to a tool of another connection.
Per-account confirmation. A write confirmation on one account does not apply to another. Every write operation on a new account = a new confirmation block (including the account line).
Credentials don't mix. Each connection has its own Access Token. Don't assume the same credentials work on another account.

Cross-account search (read only)

When the user asks for something broad — "which account does the domain shop.example.co.il live on?", "give me a disk overview for all accounts" — it's permitted and legitimate to read (read-only) from all the connections, but:

Run the same sequence of reads on each connection separately, and tag each result with the account name.
Summarize in a table with a clear "Account" column.
Never perform a broad write operation across multiple accounts without individual confirmation for each one.

Example tagging in the response:
| Account  | Server           | disk |
|----------|------------------|------|
| clientA  | prod-shop-il     | 87%  |
| clientB  | prod-blog        | 41%  |
| internal | ops-tools        | 63%  |

Common usage patterns (examples)

Quick snapshot of an account

1. server_list               → list of all servers
2. copilot_insights_list     → active insights/alerts

(No account/whoami tool exists — infer the account from the connection prefix + server_list.)

Health check before a weekend (production client)

1. server_get                   → CPU/RAM/disk
2. monitoring_server_graph      → metrics (CPU/mem/etc.)
3. monitoring_app_summary       → for each application
4. copilot_insights_list        → open insights/alerts
5. monitoring_server_summary    → disk/bandwidth; if disk > 80% — red flag

Checking an app's details

1. app_list                  → find the app
2. app_get                   → details, FQDN, config

(SSL / Let's Encrypt is an MCP tool as of v1.2 — security_lets_encrypt_install / _renew / _auto_renewal / _revoke, via the security toolset. Install/renew are W; revoke is W!.)

For more detailed patterns, load the relevant workflows.

Versioning and source of truth

Tool names match the official articles. The tool names and categories in this catalog are verified against the official Cloudways support articles (setup + tools reference, MCP v1.2). They are the official MCP tool names. The v1.2 additions have not yet been re-enumerated against the live server — see the note in references/tools-catalog.md.
The live MCP remains the source of truth if Cloudways changes them. If a tool name or capability differs from what's documented here, the live list of tools connected in Claude (mcp__cloudways*__*) wins — check it and update the catalog accordingly.
Every write tool still goes through the confirmation pattern. W = single confirmation, W! = double-confirmation (destructive — e.g. server_delete, app_delete, app_restore, app_cname_delete), per references/tools-catalog.md. This discipline is more important now that the official destructive tools are confirmed to exist.