# Redu MCP server

Source: https://glimind.com/server/mcp-registry%2Fcloud.redu%2Fmcp
Registry id: `mcp-registry/cloud.redu/mcp`
Status: live (checked 2026-10-27T03:15:08.664Z)

## Measurements (30 days)

- Uptime: 99.88%
- Checks: 5021
- Outages (90 days): 19

## Install

```json
{
  "mcpServers": {
    "redu-mcp-server": {
      "type": "http",
      "url": "https://mcp.redu.cloud/mcp"
    }
  }
}
```

Claude Code:

```sh
claude mcp add --transport http redu-mcp-server https://mcp.redu.cloud/mcp
```

## Tools (91)

- `architecture_diagram`: Read-only. Fetches EVERY resource on your redu.cloud account (VMs, volumes, private networks, managed databases: Postgres/MySQL/MariaDB/ClickHouse/Redis/Qdrant,
- `attach_volume`: Attaches an EXISTING block volume to a running instance as an extra disk. This is how you finish a RESTORE after a VM is gone: restore_backup (volumeName) rebui
- `check_deploy_prerequisites`: The deploy ENTRY GATE - run this first when a user wants to deploy. Verifies the account is ready and AUTO-SELECTS the network_id + keypair_name to pass to depl
- `create_api_key`: Mints a NEW least-privilege redu API key for a deployed app or automation to use (e.g. to add a backup feature). GUARDRAIL: the first call does NOT create anyth
- `create_backup`: Creates a backup, by volumeId or by instanceId (the instance's volume is resolved for you). The backup is held independently of the instance, so it survives the
- `create_clickhouse`: Provisions a managed ClickHouse database (OLAP / columnar analytics engine, Apache-2.0) on a dedicated VM on your private network - its OWN resource, NOT a rela
- `create_database`: Provisions a managed PostgreSQL database on a dedicated VM on your private network. Requires a recent plan_managed_datastore. For app deployments, prefer deploy
- `create_instance`: Creates a raw compute instance for custom OS/cloud-init workflows. For app/source deployments, prefer check_deploy_prerequisites -> plan_deploy -> deploy_app/de
- `create_media_space`: Creates a private Redu media space: a small NFS VM backed by a persistent volume, intended for WordPress/WooCommerce wp-content/uploads in autoscaling clusters.
- `create_private_vps`: Approved pilot accounts only. Create one website VM (1 CPU, 2 GiB RAM, 10 GiB total disk) or one database VM (1 CPU, 1 GiB RAM, 2 GiB total disk). Both start wi
- `create_qdrant`: Provisions a managed Qdrant vector database on a dedicated VM. Requires a recent plan_managed_datastore (engine 'qdrant'). Reachable from your private network a
- `create_redis`: Provisions a managed Redis instance on a dedicated VM on your private network. Requires a recent plan_managed_datastore. It is PRIVATE - reachable only from ano
- `create_relational_database`: Provisions a managed MySQL (or MariaDB) database on a dedicated VM on your private network - the relational-database resource (use this instead of create_databa
- `create_snapshot`: Creates a snapshot of a running instance.
- `create_volume`: Creates a block storage volume.
- `delete_api_key`: Deletes one of the account's API keys, by id or by name. Anything that uses the key stops working at once, so the first call deletes nothing: it shows the key (
- `delete_backup`: Deletes a backup by ID.
- `delete_clickhouse`: Deletes a managed ClickHouse database and its underlying VM. Pass the numeric id from list_clickhouse_databases. This cannot be undone.
- `delete_cluster`: Deletes an autoscaling cluster - tears down the WHOLE cluster: every autoscaled EXTRA member VM, the load balancer, the pool, the cluster security group, and th
- `delete_database`: Deletes a managed Postgres database and its underlying VM. Pass the numeric database id from list_databases. This cannot be undone.
- `delete_deployment`: Deletes a deployment and its underlying app VM, with the data kept on that machine (its named volumes): the only way kept data is deleted, so ask the user first
- `delete_dns_entry`: Removes one public name (a DNS entry), by its id from list_dns_entries or by the name itself. The name stops serving at once, and anything reached through it (a
- `delete_instance`: Permanently deletes an instance. This cannot be undone.
- `delete_keypair`: Removes an SSH keypair from your account by name.
- `delete_private_vps`: Permanently delete one of your pilot VMs and its boot disk, including all stored data. Requires explicit user authorization. Use the occupied operation id from 
- `delete_qdrant`: Deletes a managed Qdrant and its underlying VM, with every collection in it. Pass the numeric id from list_qdrant. This cannot be undone.
- `delete_redis`: Deletes a managed Redis instance and its underlying VM. Pass the numeric id from list_redis. This cannot be undone.
- `delete_relational_database`: Deletes a managed MySQL/MariaDB database and its underlying VM. Pass the numeric id from list_relational_databases. This cannot be undone.
- `delete_snapshot`: Deletes a snapshot by ID.
- `delete_volume`: Permanently deletes a block storage volume and the data on it. This cannot be undone. The volume must be 'available' (detached) - detach_volume it first, and no
- `deploy_app`: Deploys an app to a VM and exposes it at a public https://<name>-<id>.redu.cloud URL. The container is built ON the VM. PREREQS - run check_deploy_prerequisites
- `deploy_compose`: Deploys a MULTI-CONTAINER app - a repo that ships docker-compose.yml / compose.yaml - onto ONE VM via podman-compose, and exposes one or more services at redu.c
- `deploy_overview`: Orientation for deploying an app on redu.cloud: the end-to-end flow, the two source modes (git vs upload), how to handle a missing Dockerfile or a database, whe
- `deploy_vpn`: Stands up a redu VPN gateway (WireGuard tunnelled over wstunnel on WSS/443) on your PRIVATE network, so you (or your team) can reach the private IPs of the VMs 
- `detach_volume`: Detaches a block volume from an instance, leaving the volume (and its data) intact and 'available' to attach elsewhere. Unmount it INSIDE the guest first (`umou
- `exec_private_vps`: Run a user-requested shell script as ubuntu on an active pilot VM (sudo is available). Both pilots start as plain Ubuntu: install only the database or app the u
- `get_container_logs`: THE APPLICATION'S OWN LOGS - what `docker logs`/`podman logs` would show for each container in a deployment. This is the tool for 'it deployed fine but it does 
- `get_containers`: WHAT IS ACTUALLY RUNNING on a deployment's VM: every container's name, image, state, health, restart count, exit code and published ports - including the ones t
- `get_deployment`: Fetches ONE deployment by its numeric id (from list_deployments). Returns its current status, the public access_point URL, the underlying VM id, AND the build_l
- `get_domain_verification`: Starts (or resumes) a claim on a custom domain and returns the DNS TXT record that proves it is the user's: they add it at the domain's DNS provider, then you c
- `get_env_keys`: WHICH ENVIRONMENT VARIABLES the deployment was actually given, BY NAME - the keys in the env files on the VM (/opt/app-src/.env and friends), never the values. 
- `get_instance_logs`: The VM's SERIAL CONSOLE: kernel messages and early-boot/cloud-init output. ⛔ THIS IS NOT YOUR APPLICATION'S LOGS. For a deployed app - a crash loop, a 500, a fa
- `get_private_vps_action`: Read the status, bounded output and exit code of your pilot command, or the SSH access instructions. An unknown result must be inspected before submitting a new
- `get_private_vps_pilot`: Read your private VPS pilot approval and occupied website/database slots. This does not create a VM or change billing.
- `get_private_vps_ssh`: Install the user's SSH PUBLIC key on either pilot and return its SSH connection instructions through the restricted relay. The smaller database pilot works on i
- `get_resource_usage`: HOW MUCH ROOM IS LEFT on a deployment's VM: total/used/available memory, swap, disk free, load average, CPU count, and OOM kills in the last 24h - plus per-cont
- `get_ssh_command`: Returns the SSH command to connect to an instance via the redu.cloud TCP proxy. ACCEPTS an instance id, a deployment's id / name / instance_id, OR a MANAGED DAT
- `import_keypair`: Registers an existing SSH public key on your account. Use this to import your own public key so you can SSH into instances. The private key never leaves your ma
- `instance_action`: Start, stop, or reboot an instance. action must be START, STOP, REBOOT_SOFT, or REBOOT_HARD.
- `integrate_overview`: Orientation for wiring a redu.cloud capability (backups, DNS, extra storage, a managed DB, ...) INTO an app already deployed on redu, e.g. 'add a backup feature
- `list_api_keys`: Lists the account's API keys: id, name, scopes, when each was created and last used, and when it expires. Never the secret (redu keeps only a hash). Use it to f
- `list_backups`: Lists your volume backups.
- `list_clickhouse_databases`: Lists your managed ClickHouse databases (OLAP / analytics - its own resource, not a relational DB). Once a row's status is 'ready' it carries the private-networ
- `list_clusters`: Lists your autoscaling clusters.
- `list_databases`: Lists your managed PostgreSQL databases. Once a row's status is 'ready', it carries the private-network connection details (private_ip, port 5432, db_name, db_u
- `list_deployments`: Lists your app deployments. Each row carries status (provisioning/ready/build_failed/error), the current build phase while provisioning (installing/source/build
- `list_dns_entries`: Lists the public names (DNS entries) on this account: each entry's id, the names it serves (domain_names) and the address it forwards to. delete_dns_entry remov
- `list_domains`: Lists the custom domains on this account with their status: verified (it can be bound with dname on deploy_app/deploy_compose, dns_entries on create_instance, o
- `list_flavors`: Lists available instance sizes.
- `list_images`: Lists available OS images.
- `list_instances`: Lists your compute instances.
- `list_keypairs`: Lists your SSH keypairs. If empty, call import_keypair first before creating instances.
- `list_media_spaces`: Lists Redu media spaces: private NFS media VMs backed by persistent volumes. For WordPress/WooCommerce clusters, reuse one on the app's private network for wp-c
- `list_private_networks`: Lists your private networks.
- `list_qdrant`: Lists your managed Qdrant vector databases (create_qdrant, or started for a deploy). Once a row's status is 'ready' it carries private_ip (REST port 6333, gRPC 
- `list_redis`: Lists your managed Redis instances. Once a row's status is 'ready' it carries the private-network connection details (private_ip, port 6379) - connect from anot
- `list_regions`: Lists available regions.
- `list_relational_databases`: Lists your managed MySQL/MariaDB databases (the relational-database resource). Each row carries its engine ('mysql'|'mariadb'); once status is 'ready' it has th
- `list_security_groups`: Lists your security groups.
- `list_snapshots`: Lists your instance snapshots.
- `list_volumes`: Lists your block storage volumes.
- `plan_deploy`: Turns YOUR repo classification (you scan the repo and pass what you found) into a complete, approvable deploy plan WITHOUT creating anything. ⚡ REDU NEEDS THREE
- `plan_instance`: Aggregates images/flavors/keypairs/networks/security groups into human-friendly choices. Does not create anything. Happy path: import_keypair → plan_instance → 
- `plan_managed_datastore`: Plans a direct managed datastore create without provisioning anything. Use this before create_database, create_relational_database, create_redis, create_clickho
- `postgres_data_change`: Changes the data INSIDE a managed Postgres database, as the console does: rows, tables and columns, a SQL write, a CSV import, saved queries, the editing lock. 
- `postgres_data_read`: Reads the data INSIDE a managed Postgres database, as the console's data view does: tables, rows (sorted, found), a table's info, one cell, a related row, one r
- `prepare_upload`: Returns the LOCAL shell commands to package your working directory and upload it for an upload-mode deploy (no git, no PAT). Run them in the user's terminal, ca
- `publish_private_vps`: Publish a user-requested HTTP application from either pilot, including the smaller pilot on its own, at a generated public HTTPS URL. First install and start th
- `release_domain`: Removes a custom domain from this account: a verified domain is no longer verified for it (using it again needs a new TXT check), and a pending claim is cancell
- `restore_backup`: Restores a backup into an existing volume (volumeId), an instance's volume (instanceId), or a new one (volumeName). Poll list_volumes for the restored volume. D
- `scaffold_local`: OPTIONAL preflight: returns a podman-compose.yml + .env so the user can run the app (and a throwaway local Postgres) on THEIR machine before deploying to redu -
- `select_surface`: For a repo with SEVERAL runnable parts, call this BEFORE plan_deploy. You enumerate the candidate surfaces (find every Dockerfile/Containerfile, OPEN each, clas
- `set_cluster_domain`: Changes the PUBLIC HOSTNAME a cluster serves on, so the user can put THEIR OWN production domain (shop.acme.com, app.theircompany.com) in front of it instead of
- `set_managed_backups`: Turns nightly AUTOMATED (scheduled) backups ON or OFF for a MANAGED data service - the toggle that create_backup (a one-off volume snapshot) is NOT. Once enable
- `update_cluster`: Updates a running autoscaling cluster to a new app version IN PLACE, with NO URL change: snapshots the 'hero' VM (the source/master VM you SSH into and change -
- `upgrade_to_cluster`: THE WAY TO MAKE AN EXISTING APP HIGHLY AVAILABLE. If the user asks for high availability, redundancy, no single point of failure, surviving a host or VM failure
- `upgrade_to_ha`: Turns an EXISTING, running single-machine managed Postgres or ClickHouse into a THREE-machine highly available cluster, in place, keeping the data and the same 
- `verify_deployment`: Asks redu to re-probe a deployment's public URL and update its status from what it actually observes. USE THIS AFTER YOU HAVE FIXED A FAILED DEPLOY - a deployme
- `verify_domain`: Checks the DNS TXT ownership record of a custom domain and, when it matches, marks the domain verified for this account. Call get_domain_verification first for 
- `wait_for_deployment`: ⭐ CALL THIS INSTEAD OF POLLING. Waits up to 50 seconds per call (an MCP client cuts a call at about 60 s) for the deployment to reach a TERMINAL state (ready, b
- `whoami`: Verifies your redu.cloud credential with a REAL server round-trip and returns your identity + live quota. A green result means the key actually works - not mere

Measured by Glimind (https://glimind.com): MCP handshake + tool list only, no tool is ever called. CC BY 4.0.