Server providing Argo CD integration for MCP clients.
Nothing to run from here
Redu Cloud MCP is installed from its publisher's own source and answers where it runs, so this marketplace is not in the path of a single call. There is no address here to send one to, and a panel that pretended otherwise would be showing you an answer we made up. Install it and call it from your own client — the Installation tab has the entry for each one.
86
tools declared
—
trust score
remote
at its publisher
—
calls last 7d
What it does
Agent-native cloud, EU-hosted. Provision VMs, networks & databases on redu.cloud via MCP.
Quickstart
# 1 — add it to Claude Code
claude mcp add --scope user --transport http mcp-redu-cloud-mcp https://mcp.redu.cloud/mcp
# 2 — ask your agent for something these tools do
# whoami, check_deploy_prerequisites, deploy_overview and 83 more
Redu Cloud MCP costs nothing on mcprush: there is no plan to choose here, no cap to set and nothing mcprush can bill you for.
Publishernot claimed
MRAll 1 server
mcp.redu.cloud1 server
1 category
Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.
Installation
Where are you running it?
Every route below installs the same thing and ends at the same approval screen. Nothing here runs on your machine and nothing runs on ours: this server answers at its publisher’s own address, and what you install is the connection straight to it.
Claude Codedeclared by this listing
This is a public server: it answers at its publisher’s own address and this marketplace is not in the path. Claude Code registers it in one command; --scope user makes it available in every project. The transport below is http, read from the address; if the publisher says otherwise, swap that one word.
claude mcp add --scope user --transport http mcp-redu-cloud-mcp https://mcp.redu.cloud/mcpReconnect, or start a new session, and the tools appear in the model’s tool list.
Free on mcprush, and it answers at its publisher’s own address: this marketplace is not in the path, so there is no key of ours to hold and no card to add.
What it writes
One config entry pointing straight at the publisher’s own address — this marketplace is not in the path, and nothing from this listing executes on your machine.
What you approve
86 tools, with what each one reads, writes and reaches shown before you agree — the same list on every route above. Read the tool surface.
Tool surface
What the model actually sees. Descriptions are diffed on every release — see version history.
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 merely that one is configured. Use this first if anything is 401ing.
No parameter schema on file.
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 deploy_app (so you never hunt for them): (1) account reachable + quota, (2) a private network (picks your default — every account has one), (3) an SSH keypair (if you have none, returns ssh_key_recipe: the exact local ssh-keygen → import_keypai
| Parameter | Type | Required | Notes |
|---|---|---|---|
| mode | string | no | OMIT by default: the session deploys end to end with no questions (yolo: the default network, a keypair created if missing). Pass 'guided' ONLY when the user explicitly said they want to approve or to |
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, when (and when NOT) to split a deploy across multiple VMs, verifying a deploy functionally, and how to debug a failed build. Call this first when a user asks to deploy/ship/host an app and you're unsure where to start.
No parameter schema on file.
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 anything. It returns a confirmation the user must approve, because a key is a long-lived credential that acts on the account and ANY usage of it is BILLED to the account owner. Show the user the name, the exact scopes, and the billing notice, ge
| Parameter | Type | Required | Notes |
|---|---|---|---|
| name | string | yes | A recognizable name for the key, e.g. 'supabase-backups'. |
| scopes | array | yes | LEAST-PRIVILEGE scopes the key may use, e.g. ['instance:read','backup:read','backup:create','backup:restore']. Grant only what the feature needs. Discover the catalog via GET /v1/capabilities (grammar |
| expires_in_days | integer | no | Optional: auto-expire the key after N days. |
| confirm | boolean | no | Set true ONLY after the user has explicitly approved (see the confirmation the first call returns). Leave unset to get the approval prompt first. Do NOT set it yourself. |
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 find a key to delete with delete_api_key, or to check what keys exist before minting another.
No parameter schema on file.
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 (name, scopes, last used) for the user to approve; call again with confirm:true only after their yes. Use it to clean up a key you created for a task that is finished.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | no | The key's id, from list_api_keys. | |
| name | string | no | Or the key's name, when exactly one key has it. |
| confirm | boolean | no | Set true ONLY after the user has explicitly approved deleting this key (see the confirmation the first call returns). Do NOT set it yourself. |
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 to the Supabase I deployed on redu'. Explains the pattern: mint a LEAST-PRIVILEGE scoped API key (with the user's approval via create_api_key), inject it into the app, and call the redu API from the app. Call this when a user asks to add/i
No parameter schema on file.
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, capture source_token from the upload's JSON response, then call deploy_app with that source_token (omit repo). The upload authenticates AUTOMATICALLY with a short-lived ticket minted from your MCP credential — NO API key needed in the comma
| Parameter | Type | Required | Notes |
|---|---|---|---|
| project_dir | string | no | Path to the local app directory to upload (default current dir). |
| is_git_repo | boolean | no | If the dir is a git checkout, set true to honor .gitignore (tracked files plus untracked, non-ignored ones). Either way a TRACKED file is never dropped, also one under vendor/, dist/, build/ or target |
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 — to see it run / sanity-check the container. Requires local podman/podman-compose. It's a suggestion, not a gate — skip it and go straight to deploy_app any time. Honest caveat: the local Postgres is NOT the managed Postgres, so a green loc
| Parameter | Type | Required | Notes |
|---|---|---|---|
| runtime | string | yes | App runtime (node/python/go/…) — from plan_deploy. |
| port | integer | no | Port the app listens on. |
| needs_postgres | boolean | no | Include a local Postgres container + wire PG* env. |
| has_container | boolean | no | Repo already has a Dockerfile/Containerfile (the compose builds it). If false, write the plan_deploy-generated Dockerfile to ./Dockerfile first. |
Aggregates images/flavors/keypairs/networks/security groups into human-friendly choices. Does not create anything. Happy path: import_keypair → plan_instance → create_instance → get_ssh_command. Call this second (after import_keypair, if you have no keypairs).
| Parameter | Type | Required | Notes |
|---|---|---|---|
| osHint | string | no | — |
| sizeHint | string | no | — |
Plans a direct managed datastore create without provisioning anything. Use this before create_database, create_relational_database, create_redis, create_clickhouse or create_qdrant (engine 'qdrant', the vector database). For app deployments you need none of these: datastores are managed by default, so the ones you report in send_signals are started and wired for you. Pass ha:true to plan a highly
| Parameter | Type | Required | Notes |
|---|---|---|---|
| engine | string | no | — |
| sizeHint | string | no | — |
| ha | boolean | no | Plan a highly available datastore (three machines on three different physical hosts behind a load balancer, surviving the loss of a machine with no manual failover) instead of the default single machi |
For a repo with SEVERAL runnable parts, call this BEFORE plan_deploy. You enumerate the candidate surfaces (find every Dockerfile/Containerfile, OPEN each, classify by its EXPOSE + CMD — never by directory name) and pass them in; redu RANKS them with fixed rules (a standalone browser desktop/noVNC > a self-contained web app > a keys-required playground > an API > a headless worker > docs/examples)
| Parameter | Type | Required | Notes |
|---|---|---|---|
| surfaces | array | yes | EVERY runnable surface you found (run find . -name Dockerfile -o -name Containerfile, open each). Be exhaustive — a missed browser-desktop subdir is the #1 cause of a wrong pick. |
| mode | string | no | Drive mode; omit to use the session's sticky mode. |
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 FILES IF THEY EXIST - redu.md, the compose file, the Dockerfile - and there are two ways to give them. ⭐ BEST, for an upload-mode deploy: run prepare_upload FIRST and pass its source_token; redu reads all three straight out of the upload
| Parameter | Type | Required | Notes |
|---|---|---|---|
| source_token | string | no | The source_token returned by your prepare_upload upload. ⚡ PREFER THIS over pasting: redu reads redu.md, the compose file and the Dockerfile straight out of the upload you ALREADY made, so you do no |
| redu_md | string | no | PASTE the raw contents of redu.md from the repo root if the file exists (just cat redu.md). ⚠️ Only needed when you have NO source_token (a git-mode deploy): with a token, redu reads this file out |
| compose_yaml | string | no | PASTE the raw contents of the repo's docker-compose.yml / compose.yaml if it has one. redu scans it server-side for known deploy-breaking patterns (Docker-only local log driver, depends_on:service_h |
| dockerfile | string | no | PASTE the raw contents of the repo's Dockerfile if it has one. redu scans it server-side for BuildKit heredocs, empty EXPOSE ${ARG}, and source-build fetches (go/cargo/npm/pip/apt) that are known to |
| runtime | string | yes | Detected app language/runtime (node, python, go, ruby, ...). Informational — the app deploys as a container, so the language does not gate the deploy. |
| containerizable | boolean | no | Whether the app can run in a container. Almost always true (a container is the delivery unit); set false ONLY if the app fundamentally can't be containerized — then redu can't deploy it yet. |
| serves_http | boolean | no | Whether the repo actually RUNS an HTTP server that listens on a port. Set FALSE for a library, CLI tool, or language runtime that has no web server (e.g. a package you import, or a bun/node-styl |
| port | integer | no | Port the app's HTTP server listens on (PORT env / framework default / Dockerfile EXPOSE of a real app port — NOT a debug/IPC port). Omit if the repo has no HTTP server. |
| worker | boolean | no | HEADLESS WORKER / daemon: the repo runs a long-lived process with NO HTTP server (a chaos-monkey, a background/queue worker, an on-infra agent runner). Set TRUE to plan a WORKER deploy — a private VM |
| start | string | no | How the app starts (package.json start script / Procfile / Dockerfile CMD). |
| has_container | boolean | no | Whether the repo already has a Dockerfile / compose file. |
| needs_postgres | boolean | no | App uses Postgres (deps pg/prisma/sqlalchemy/drizzle or DATABASE_URL). |
| needs_redis | boolean | no | App uses Redis (deps redis/ioredis/bullmq/celery or REDIS_URL). |
| needs_clickhouse | boolean | no | App uses ClickHouse: the ANALYTICS / EVENTS store, a separate tier from the app's Postgres/MySQL. Set TRUE on ANY signal: a clickhouse/clickhouse-server image in the compose, a CLICKHOUSE_* / CLICKHOU |
| needs_vector_db | boolean | no | App uses a vector DB (deps qdrant-client / langchain+embeddings or QDRANT_URL). |
| needs_compose | boolean | no | Set TRUE when the repo ships a docker-compose.yml / compose.yaml that runs MULTIPLE services (app + its own db/redis/worker containers) as a stack — then deploy with deploy_compose (podman-compose on |
| app_profile | string | no | Detected app profile. Set wordpress/woocommerce when source inspection finds wp-config.php, wp-content, WordPress/WooCommerce packages/plugins, or wordpress/woocommerce compose images. This is used fo |
| cluster_target | boolean | no | Set TRUE when the user asked to deploy this app as an autoscaling cluster. For WordPress/WooCommerce this requires managed MySQL/MariaDB plus a Redu media space mounted at wp-content/uploads (or an ex |
| cluster_media_mode | string | no | For WordPress/WooCommerce cluster_target:true, use media_space as the default real fix: Redu creates/reuses an NFS media VM backed by a volume and mounts it at wp-content/uploads. central_media_origin |
| media_origin_url | string | no | Public base URL where WordPress wp-content/uploads is served when cluster_media_mode:'central_media_origin'. Do not use the DB VM as this origin. |
Lists your compute instances.
No parameter schema on file.
Lists available instance sizes.
No parameter schema on file.
Lists available OS images.
No parameter schema on file.
Lists your SSH keypairs. If empty, call import_keypair first before creating instances.
No parameter schema on file.
Lists your security groups.
No parameter schema on file.
Lists your private networks.
No parameter schema on file.
Lists your block storage volumes.
No parameter schema on file.
Lists your instance snapshots.
No parameter schema on file.
Lists your volume backups.
No parameter schema on file.
Lists your autoscaling clusters.
No parameter schema on file.
Lists DNS proxy host entries.
No parameter schema on file.
Lists custom domains you have verified ownership of.
No parameter schema on file.
Lists available regions.
No parameter schema on file.
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_user).
No parameter schema on file.
Lists your managed MySQL/MariaDB databases (the relational-database resource). Each row carries its engine ('mysql'|'mariadb'); once status is 'ready' it has the private-network connection details (private_ip, port 3306, db_name, db_user).
No parameter schema on file.
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-content/uploads, or pass create_media_space:true to deploy_app/deploy_compose/upgrade_to_cluster so Redu creates one.
No parameter schema on file.
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-network connection details (private_ip, ClickHouse HTTP port 8123, db_name, db_user).
No parameter schema on file.
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 another instance on the same private network with redis-cli -h <private_ip> -p 6379 -a <password>.
No parameter schema on file.
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 6334); the API key is never listed.
No parameter schema on file.
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. Prefer letting deploy_app/deploy_compose create this by passing create_media_space:true after plan_deploy approval; use this tool when manually preparing or reusing shared uploads storage.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| name | string | yes | Name for the media space, e.g. myshop-media. |
| size_gb | integer | no | Persistent media volume size in GB. |
| flavor_id | string | no | Small VM flavor id for the NFS media server. m1.small is enough for most WordPress uploads. |
| network_id | string | no | Private network id. Use the same network as the WordPress app and managed DB. |
| keypair_name | string | yes | Existing SSH keypair name. |
| security_group_names | array | no | Security groups for the media VM. Redu opens NFS 2049 from private networks only. |
| mount_path | string | no | Host mount path that app VMs will use before binding into /var/www/html/wp-content/uploads. |
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, or 'stay up if a machine dies', this is the tool: point it at their running VM and pass high_availability:true. It needs no rebuild and no redeploy, and the URL does not change. Turns a single running instance into a horizontally-autoscal
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| instance_id | string | yes | The instance to turn into a cluster (from list_instances, or the VM of a deploy_app/deploy_compose deployment). It is snapshotted, and the autoscaling members are booted from that snapshot. |
| name | string | yes | Name for the cluster (lowercase letters, numbers, hyphens). |
| flavor_id | string | yes | Member VM size — from list_flavors. Every autoscaling member uses this flavor. STRONGLY prefer m1.mem16/m1.mem32 (memory-optimized, 40 GB disk): clustering snapshots the source disk, so a lean disk ma |
| network_id | string | yes | Private network id — from list_private_networks. Use the SAME network the app's managed DB / other services are on, so members can reach them by private IP. |
| keypair_name | string | yes | SSH keypair name — from list_keypairs. |
| port | integer | no | Port the app listens on / the load balancer forwards to (default 80). Your source VM must actually serve on this port — the load balancer health-checks it. |
| high_availability | boolean | no | Set TRUE whenever the user asks for HIGH AVAILABILITY, redundancy, 'no single point of failure', 'survive a host/node failure', or 'stay up if a VM dies'. This is the ONLY way to get an HA cluster and |
| max_size | integer | no | Peak member count under load (default 5). In the default mode this is EXTRA members added on top of your always-on source VM, and the floor is 0 extra. With high_availability:true the group runs betwe |
| startup_command | string | no | Single-line shell command to (re)start the app on each fresh member if the snapshot's own services do not auto-start it. For a podman-compose app: 'cd /opt/app && podman-compose up -d'. Omit to rely o |
| scale_out_threshold | number | no | Average CPU fraction (0-1) above which a member is added (default 0.7). |
| scale_in_threshold | number | no | Average CPU fraction (0-1) below which a member is removed (default 0.2). |
| dname | string | no | Optional public DNS name for the cluster's load-balancer access point (a .redu.cloud name is auto-generated if omitted). |
| app_profile | string | no | Set wordpress/woocommerce when upgrading an older deployment or raw VM that the backend has not profiled. WordPress/WooCommerce clusters require managed MySQL/MariaDB plus a media_space or explicitly |
| cluster_media_mode | string | no | For WordPress/WooCommerce, use media_space as the default real cluster fix. local_uploads is refused because wp-content/uploads would diverge across members. |
| media_origin_url | string | no | Public base URL where WordPress wp-content/uploads is served from the central media origin. This should be a separate media origin, not the DB VM. |
| media_space_id | integer | no | Existing Redu media space id to mount on every WordPress/WooCommerce cluster member. |
| create_media_space | boolean | no | Set TRUE when upgrading a WordPress/WooCommerce deployment that has no media_space_id yet. Redu creates a small NFS media VM + volume, records it, and mounts it on all members. |
| media_space_name | string | no | Optional name for the media space when create_media_space:true. Defaults to <cluster-name>-media. |
| media_space_size_gb | integer | no | Media space data volume size in GB when create_media_space:true (default 20). |
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 — it is also the always-on baseline member that serves traffic), then redu rolling-updates the autoscaled extra members to that snapshot ONE AT A TIME and refreshes the image the group boots future members from — the SAME load balancer and S
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| stack_name | string | yes | Cluster stack name, from list_clusters (stack_name). |
| stack_id | string | yes | Cluster stack id, from list_clusters (id). |
| instance_id | string | yes | The 'hero' VM to snapshot and roll to every extra member: the source/master VM you upgraded to a cluster and SSH into to make changes. It is your cluster's always-on baseline member. Its CURRENT disk |
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 the auto-generated redu.cloud URL. That is what this tool is for: a real product on a real brand. The cluster itself is untouched - same members, same load balancer, same data - only the name in front of it changes. TWO RULES, and getting
| Parameter | Type | Required | Notes |
|---|---|---|---|
| stack_id | string | yes | Cluster id, from list_clusters (the row's id). |
| domain | string | yes | The hostname to bind. Either your OWN production domain (e.g. shop.acme.com) - which must be verified FIRST, see the tool description - or a .redu.cloud label. A .redu.cloud value is NOT taken literal |
Deletes an autoscaling cluster — tears down the WHOLE cluster: every autoscaled EXTRA member VM, the load balancer, the pool, the cluster security group, and the cluster's *.redu.cloud proxy host. Your SOURCE (hero) VM is NOT part of the stack and is NOT deleted — it was the always-on baseline member but it is your own VM; delete_instance it separately if you no longer need it. Pass stack_name + s
| Parameter | Type | Required | Notes |
|---|---|---|---|
| stack_name | string | yes | Cluster stack name, from list_clusters (stack_name). |
| stack_id | string | yes | Cluster stack id, from list_clusters (id). |
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 machine.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| name | string | yes | Name for the keypair (e.g. 'my-laptop'). Must be unique on your account. |
| public_key | string | yes | SSH public key to import (the contents of your id_rsa.pub or id_ed25519.pub). |
Removes an SSH keypair from your account by name.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| name | string | yes | Name of the keypair to delete. |
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 DATASTORE's id / name / instance_id (Postgres, MySQL/MariaDB, ClickHouse, Redis) - it resolves all of them, so you do not have to work out which one you are holding (a deployment's instance_id is a placeholder until provisioning finishes, and
| Parameter | Type | Required | Notes |
|---|---|---|---|
| instance_id | string | yes | An instance id, a deployment's id / name / instance_id, or a managed datastore's id / name / instance_id. All are resolved. |
| keypair_name | string | no | The SSH keypair the instance was created with (read it from get_deployment for a deploy VM). When given, the command uses -i ~/.ssh/<keypair_name> so it authenticates with the right key. |
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 failed DB connection - use get_container_logs, which returns what the containers actually printed. Reach for this one only for boot-level questions: the machine never came up, the disk did not mount, cloud-init failed before the app existed.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| instance_id | string | yes | ID of the instance to fetch BOOT/console logs for. For app logs use get_container_logs instead. |
Start, stop, or reboot an instance. action must be START, STOP, REBOOT_SOFT, or REBOOT_HARD.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| instanceId | string | yes | — |
| action | string | yes | — |
Creates a raw compute instance for custom OS/cloud-init workflows. For app/source deployments, prefer check_deploy_prerequisites -> plan_deploy -> deploy_app/deploy_compose; do not use create_instance as a shortcut around the deployment plan. Requires a recent plan_instance. For reduOS, set cloud_init_template='reduos' and flavor m1.xlarge (16GB). SSH keypair must exist. For a public web app on a
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| name | string | yes | — |
| image_id | string | yes | — |
| flavor_id | string | yes | — |
| keypair_name | string | yes | — |
| network_id | string | yes | — |
| security_group_names | array | no | — |
| port | integer | no | — |
| dname | string | no | — |
| dns_entries | array | no | Public DNS/proxy entries to create automatically. Use [{ dname:'', port:8080 }] to generate a redu.cloud URL pointing at an origin process on port 8080. |
| user_data | string | no | — |
| cloud_init_template | string | no | — |
| volume | object | no | — |
| boot_volume_id | string | no | DISASTER RECOVERY: boot this new VM from an EXISTING volume (one restore_backup just created) instead of a fresh image, so the machine comes back with the restored filesystem AS its root disk. The vol |
| imageName | string | no | — |
Permanently deletes an instance. This cannot be undone.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
Provisions a managed PostgreSQL database on a dedicated VM on your private network. Requires a recent plan_managed_datastore. For app deployments, prefer deploy_app database:'managed' so plan_deploy includes and wires the DB automatically. It is PRIVATE — reachable only from another instance on the same private network, via the DB's internal/private IP (not a public address). Get the ids from plan
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| name | string | yes | Name for the managed database (lowercase letters, numbers, hyphens). |
| flavor_id | string | yes | Instance size for the DB VM — from list_flavors. |
| network_id | string | yes | Private network id — from list_private_networks. The DB is reachable only from this network. |
| keypair_name | string | yes | SSH keypair name — from list_keypairs (for operating the DB VM). |
| db_name | string | no | The database to create (default 'app'). |
| db_user | string | no | The database user (default 'appuser'). |
| db_password | string | no | Password for the db user. Auto-generated and returned once if omitted. |
| version | string | no | Postgres major version (default 16). |
| extensions | array | no | Postgres extensions to pre-install at provision time (allowlisted): 'pgvector'/'vector' (embeddings), 'postgis' (geo), 'pgaudit', 'pg_trgm', 'pgcrypto', 'hstore', 'uuid-ossp', 'citext', 'ltree', 'pg_s |
| superuser | boolean | no | Grant the db user SUPERUSER — safe here (a dedicated single-tenant DB VM). Use when the app's own migrations must CREATE EXTENSION or alter roles. |
| ha | boolean | no | High availability. FALSE (the default) = ONE machine: right for dev, staging and most side projects, but if that machine dies the database is down until it is rebuilt. TRUE = THREE machines on three d |
| security_group_names | array | no | — |
Deletes a managed Postgres database and its underlying VM. Pass the numeric database id from list_databases. This cannot be undone.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
Provisions a managed MySQL (or MariaDB) database on a dedicated VM on your private network — the relational-database resource (use this instead of create_database when the app needs MySQL/MariaDB, e.g. WordPress, NextCloud, Matomo, many PHP/LAMP apps). Requires a recent plan_managed_datastore. For app deployments, prefer deploy_app database:'managed' with db_engine mysql/mariadb so plan_deploy inc
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| name | string | yes | Name for the managed database (lowercase letters, numbers, hyphens). |
| engine | string | no | Database engine: 'mysql' (default) or 'mariadb'. Both speak the MySQL protocol (mysql:// URL). Pick the one your app/stack uses. (For analytics/column-store needs use create_clickhouse instead — Click |
| flavor_id | string | yes | Instance size for the DB VM — from list_flavors. |
| network_id | string | yes | Private network id — from list_private_networks. The DB is reachable only from this network. |
| keypair_name | string | yes | SSH keypair name — from list_keypairs (for operating the DB VM). |
| db_name | string | no | The database to create (default 'app'). |
| db_user | string | no | The database user (default 'appuser'). |
| db_password | string | no | Password for the db user (letters/numbers/_/- only). Auto-generated and returned once if omitted. |
| version | string | no | Engine version (e.g. mysql '8.0', mariadb '11.4'). Defaults to the engine's current major if omitted. |
| security_group_names | array | no | — |
Deletes a managed MySQL/MariaDB database and its underlying VM. Pass the numeric id from list_relational_databases. This cannot be undone.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
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 relational database. Requires a recent plan_managed_datastore. Use it for analytics / observability workloads that need a column store (PostHog, Langfuse, event analytics, time-series). It is PRIVATE — reachable only from another instance on th
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| name | string | yes | Name for the managed ClickHouse database (lowercase letters, numbers, hyphens). |
| flavor_id | string | yes | Instance size for the ClickHouse VM — from list_flavors. ClickHouse is RAM-hungry; pick m1.small (2GB) or larger. |
| network_id | string | yes | Private network id — from list_private_networks. The DB is reachable only from this network. |
| keypair_name | string | yes | SSH keypair name — from list_keypairs. |
| db_name | string | no | The database to create (default 'analytics'). |
| db_user | string | no | The database user (default 'appuser'). |
| db_password | string | no | Password for the db user (letters/numbers/_/- only). Auto-generated and returned once if omitted. |
| superuser | boolean | no | Grant the db user global rights (CURRENT GRANTS(ALL ON *.*)) on top of its own database - safe here, it is a dedicated single-tenant VM. SET IT for any app whose own MIGRATIONS create ClickHouse objec |
| ha | boolean | no | High availability. FALSE (the default) = ONE machine: right for dev, staging and most side projects, but if that machine dies the database is down until it is rebuilt. TRUE = THREE machines on three d |
| security_group_names | array | no | — |
Deletes a managed ClickHouse database and its underlying VM. Pass the numeric id from list_clickhouse_databases. This cannot be undone.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
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 username, password and database name. Use this when the user has a live database and wants it to survive a machine or host failure: they do NOT have to create a new one and migrate by hand. How it works: a full backup is taken first (kept w
| Parameter | Type | Required | Notes |
|---|---|---|---|
| service | string | yes | Which managed database type the id belongs to. 'postgres' for one from create_database/list_databases; 'clickhouse' for one from create_clickhouse/list_clickhouse_databases. MySQL, MariaDB, Redis and |
| id | yes | Numeric id of the EXISTING single-machine database (from list_databases / list_clickhouse_databases). It must be status='ready'. | |
| acknowledge_write_loss | boolean | no | REQUIRED, and you must tell the user this in your own words and get a yes BEFORE you set it true. The upgrade copies the data while the old machine is still serving, so anything the application writes |
| flavor_id | string | no | Only needed for an old database whose build settings were not recorded; the API says so if it is missing. Otherwise the cluster reuses the machine size the database already has. |
| network_id | string | no | Only needed for an old database whose build settings were not recorded. Otherwise the cluster joins the same private network. |
| keypair_name | string | no | Only needed for an old database whose build settings were not recorded. |
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 another instance on the same private network, via its internal/private IP on port 6379 (not a public address). AUTH (requirepass) is always enabled. Get the ids from plan_managed_datastore/list_flavors, list_private_networks (or check_deploy_p
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| name | string | yes | Name for the managed Redis instance (lowercase letters, numbers, hyphens). |
| flavor_id | string | yes | Instance size for the Redis VM — from list_flavors. m1.small (2GB) is plenty for most caches/queues. |
| network_id | string | yes | Private network id — from list_private_networks (or check_deploy_prerequisites). Redis is reachable only from this network; use the SAME network as the app that will connect. |
| keypair_name | string | yes | SSH keypair name — from list_keypairs (for operating the Redis VM). |
| version | string | no | Redis major version (default '7'). |
| password | string | no | Redis AUTH password (requirepass). Auto-generated and returned once if omitted. |
| security_group_names | array | no | — |
Deletes a managed Redis instance and its underlying VM. Pass the numeric id from list_redis. This cannot be undone.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
Provisions a managed Qdrant vector database on a dedicated VM. Requires a recent plan_managed_datastore (engine 'qdrant'). Reachable from your private network at <private_ip>:6333 (REST) and :6334 (gRPC), and at a public https URL; every request must carry the api-key header (always required). Backups: set_managed_backups with service 'qdrant'. FOR AN APP YOU DEPLOY YOU DO NOT NEED THIS: report ve
| Parameter | Type | Required | Notes |
|---|---|---|---|
| idempotency_key | string | no | — |
| name | string | yes | Name for the managed Qdrant (lowercase letters, numbers, hyphens). |
| flavor_id | string | yes | Instance size, from plan_managed_datastore/list_flavors. m1.small (2GB) holds most collections; vectors live in RAM, so size up for millions of large vectors. |
| network_id | string | yes | Private network id, from list_private_networks (or check_deploy_prerequisites). Use the SAME network as the app that will connect. |
| keypair_name | string | yes | SSH keypair name, from list_keypairs (for operating the Qdrant VM). |
| api_key | string | no | The API key every request must send (the api-key header). Auto-generated and returned once if omitted. A managed Qdrant always requires one. |
| security_group_names | array | no | — |
Deletes a managed Qdrant and its underlying VM, with every collection in it. Pass the numeric id from list_qdrant. This cannot be undone.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
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 first for network_id + keypair_name, then plan_deploy for cost approval. Source can be git repo or prepare_upload source_token. PORT must be the real app listen port. DATASTORES ARE MANAGED BY DEFAULT: each one you reported in send_signals
| Parameter | Type | Required | Notes |
|---|---|---|---|
| approved | boolean | no | ONLY when send_signals said approval_required (this account approves before anything paid starts): true after the USER said yes to the plan and its cost in this conversation. Never set it yourself, an |
| idempotency_key | string | no | — |
| name | string | yes | Name for the deployment / VM (lowercase letters, numbers, hyphens). |
| repo | string | no | Filled in for you with the repository URL the USER gave (url_given_by_user in send_signals); the VM clones it. Otherwise omit it and pass source_token: the folder you work in is the source, and the pl |
| source_token | string | no | UPLOAD MODE: token from prepare_upload's curl step — deploys an uploaded tarball of your LOCAL working dir (no git, no PAT). Use this to deploy uncommitted code, a fixed clone of a repo you don't own, |
| dockerfile_content | string | no | A Dockerfile to write into the build dir before building — pass the Dockerfile that plan_deploy generated when the repo has none, or to override a broken one. (In upload mode you can instead just incl |
| dockerfile | string | no | Path within the source to the Dockerfile (e.g. 'scripts/Dockerfile') when it's NOT at the root. Pair with context when the Dockerfile is in a subfolder but COPYs from the repo root. |
| context | string | no | Build-context dir within the source (default: repo root, or subdir). Set when the Dockerfile lives in a subfolder but builds from the repo root. |
| git_ref | string | no | git mode only: branch/tag/commit to deploy (default: the repo's default branch). |
| subdir | string | no | Build context within the source (e.g. 'demo-go') when the Containerfile/Dockerfile isn't at the root. |
| git_token | string | no | git mode only: token to clone a PRIVATE repo. Omit for public repos. |
| runtime | string | no | Informational: node/python/go/… (e.g. from plan_deploy). |
| port | integer | no | REQUIRED in practice: the port the app actually listens on inside the container — pass the port plan_deploy detected / the Dockerfile EXPOSE / the framework default. redu probes THIS port for health, |
| app_profile | string | no | Detected app profile from source inspection. For WordPress/WooCommerce pass wordpress/woocommerce so cluster deploys enforce managed DB + shared media instead of treating local uploads as stateless. |
| cluster_target | boolean | no | Set TRUE when the user asked to deploy this app as an autoscaling cluster. For WordPress/WooCommerce this makes the backend require managed MySQL/MariaDB plus media_space/central_media_origin before d |
| cluster_media_mode | string | no | Record the WordPress media strategy for future clustering. For real WordPress clusters use media_space by default: Redu mounts a shared uploads filesystem into every member. local_uploads is single-VM |
| media_origin_url | string | no | Public base URL where WordPress wp-content/uploads is served when using central_media_origin. Do not put this on the DB VM. |
| media_space_id | integer | no | Existing Redu media space id to mount at WordPress wp-content/uploads. Get it from list_media_spaces. |
| create_media_space | boolean | no | For WordPress/WooCommerce cluster_target:true: set TRUE when no suitable media space exists. Redu creates an NFS media VM + persistent volume and mounts it into /var/www/html/wp-content/uploads. |
| media_space_name | string | no | Optional media space name when create_media_space:true. Defaults to <deployment-name>-media. |
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.cloud URLs. Use this instead of deploy_app when the repo is a compose stack. Same prereqs + source modes as deploy_app; always run plan_deploy first. PORT is the HOST port for the exposed service. DATASTORES ARE MANAGED BY DEFAULT: each one
| Parameter | Type | Required | Notes |
|---|---|---|---|
| approved | boolean | no | ONLY when send_signals said approval_required (this account approves before anything paid starts): true after the USER said yes to the plan and its cost in this conversation. Never set it yourself, an |
| idempotency_key | string | no | — |
| name | string | yes | Name for the deployment / VM (lowercase letters, numbers, hyphens). |
| repo | string | no | Filled in for you with the repository URL the USER gave (url_given_by_user in send_signals); the VM clones it. Otherwise omit it and pass source_token: the folder you work in is the source. Private re |
| source_token | string | no | UPLOAD MODE: token from prepare_upload — deploys an uploaded tarball of your LOCAL dir (no git). Omit repo when set. |
| git_ref | string | no | git mode only: branch/tag/commit (default: the repo's default branch). |
| subdir | string | no | Directory within the source that contains the compose file (if not at the root). |
| git_token | string | no | git mode only: token to clone a PRIVATE repo. |
| compose_file | string | no | Path within the source to the compose file (e.g. 'deploy/docker-compose.yml'). Auto-detected (docker-compose.yml / compose.yaml / …) if omitted. |
| migrate_command | string | no | One-time DB prepare/migrate/seed, run AFTER up -d and BEFORE the app is marked ready — redu runs podman-compose run --rm <migrate_service|service> <cmd> (Rails bundle exec rails db:prepare, Djan |
| migrate_service | string | no | Compose service to run migrate_command in (defaults to service). |
| compose_engine | string | no | Container engine for the compose build (default: the server's choice, usually podman). Set 'docker' to force the docker engine. |
| service | string | no | The compose SERVICE to expose at the public URL (informational; the exposed port is port). |
| port | integer | no | REQUIRED in practice: the HOST port the exposed service publishes (the LEFT side of its compose ports: mapping) — redu health-probes + proxies THIS port, so a wrong value fails the deploy. plan_depl |
| dname | string | no | Custom *.redu.cloud subdomain. For a STABLE, KNOWN-AHEAD URL (needed when the app must be told its OWN url — OAuth callbacks, cookie domain, a frontend that calls its API), generate the FULL auto-gen |
| expose | array | no | MULTI-SURFACE apps: expose several services, each gets its OWN *.redu.cloud URL. The FIRST entry is the primary one redu health-gates (its port overrides port). CRITICAL when one surface must KNOW a |
| env | object | no | Env vars APPENDED to the compose project's .env (for ${VAR} interpolation). We never rewrite your compose file. |
| app_profile | string | no | Detected app profile from source inspection. For WordPress/WooCommerce pass wordpress/woocommerce so cluster deploys enforce managed DB + shared media instead of treating local uploads as stateless. |
| cluster_target | boolean | no | Set TRUE when the user asked to deploy this compose app as an autoscaling cluster. For WordPress/WooCommerce this requires managed MySQL/MariaDB plus media_space/central_media_origin. |
| cluster_media_mode | string | no | Record the WordPress media strategy for future clustering. For real WordPress clusters use media_space by default: Redu mounts a shared uploads filesystem into every member. local_uploads is single-VM |
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 you deployed on redu, over a single https endpoint — no UDP, no extra ports. This is the TENANT VPN for reaching your OWN deployed resources; it is NOT a general internet VPN. GUARDRAIL: the first call does NOT deploy — it returns the plan
| Parameter | Type | Required | Notes |
|---|---|---|---|
| keypair_name | string | yes | REQUIRED. An EXISTING SSH keypair name (from list_keypairs / import_keypair) for the gateway VM. |
| name | string | no | Deployment name (default auto 'vpn-<id>'). Becomes the VM name + the wss://<name>.redu.cloud endpoint. |
| network_id | string | no | Private network id (from list_networks). Auto-selected from your default private network if omitted — the VMs you want to reach must be on this network. |
| flavor_id | string | no | Gateway VM size (from list_flavors). The gateway is light; m1.small ('2') is plenty. |
| client_cidr | string | no | Your tenant PRIVATE-network CIDR (e.g. '10.1.0.0/24') so the client routes it through the tunnel. If omitted, the returned client config only routes the tunnel subnet and you add your CIDR to AllowedI |
| confirm | boolean | no | Set true ONLY after the user has explicitly approved (the first call returns the plan + cost). Do NOT set it yourself. |
Lists your app deployments. Each row carries status (provisioning/ready/build_failed/error), the current build phase while provisioning (installing/source/building/built/starting), the public access_point URL, port, repo, and build_log on failure.
No parameter schema on file.
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 deployment that ended 'error' or 'build_failed' but is now serving becomes 'ready' again, and you do NOT need to redeploy it to get a green status. Redeploying working infrastructure to clear a red flag wastes the user's money and throws away the f
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | integer | yes | Deployment id from list_deployments. |
Deletes a deployment and its underlying app VM. Pass the numeric id from list_deployments. IMPORTANT: its managed datastores are NOT deleted (data safety): its database, Redis and Qdrant keep running and billing, and this tool returns each id so you can delete_database / delete_relational_database / delete_redis / delete_qdrant them when you're done with the data. Cannot be undone.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | integer | yes | Deployment id from list_deployments. |
⭐ 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, build_failed, error or vm_missing) and returns, in ONE response, everything you would otherwise fetch afterwards: the HTTP status of the PUBLIC url (not the VM's private interface, which can answer 401 while the public path still 502s), the
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | integer | yes | Deployment id, from the deploy call or list_deployments. |
| timeout_s | integer | no | Seconds to wait in this call before returning timed_out:true: at most 50 (the default); a larger value waits 50, because an MCP client cuts a call at about 60 s (ROADMAP 7). Call again until it is ter |
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_log - IN FULL when status is 'build_failed' or 'error', which is when it is the diagnosis and you should read it; otherwise the LAST 40 LINES only, with build_log_truncated:true and build_log_total_lines so you can tell a short build from a
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | integer | yes | Deployment id from list_deployments. |
| redu_md | string | no | ⭐ USUALLY UNNECESSARY NOW: if you POST your current redu.md to the redu_md_post_url this tool returns (curl -fsS --data-binary @redu.md <url>), redu merges against that and you never paste the fil |
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 that have CRASHED, which are the ones you need. Use this the moment a deployment says 'ready' but the URL misbehaves, and before you reach for SSH. get_deployment returns the deployment ROW (status, URL, build log); it cannot see inside the
| Parameter | Type | Required | Notes |
|---|---|---|---|
| deployment_id | string | yes | A deployment's id, name, or instance_id - all three resolve. |
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 not work': a 500, a crash loop, a failed DB connection, a missing env var all announce themselves here and NOWHERE else. ⛔ DO NOT use get_instance_logs for this. That returns the VM's SERIAL CONSOLE (kernel messages and cloud-init), which a
| Parameter | Type | Required | Notes |
|---|---|---|---|
| deployment_id | string | yes | A deployment's id, name, or instance_id - all three resolve. |
| service | string | no | Container/service name (substring matches). Omit for every container the VM reports. Get exact names from get_containers. |
| tail | integer | no | Lines per container (default 120). Over 120 asks the VM for a fresh pull, which takes up to ~15s. |
| since | string | no | Only logs newer than this, e.g. '30m', '2h', '7d'. Always triggers a fresh pull from the VM. |
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-container memory and CPU. Use it to answer 'is this flavor big enough', to size the NEXT deploy of the same app honestly instead of guessing, and to explain a container that keeps dying (an OOM kill leaves no application log at all - the proces
| Parameter | Type | Required | Notes |
|---|---|---|---|
| deployment_id | string | yes | A deployment's id, name, or instance_id - all three resolve. |
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. Most of the time the real question is 'did DATABASE_URL get wired, or is the app reading a name I did not set', and the name answers it: you can confirm the DB was connected, spot a typo'd key, and see which of the app's documented variable
| Parameter | Type | Required | Notes |
|---|---|---|---|
| deployment_id | string | yes | A deployment's id, name, or instance_id - all three resolve. |
Read-only. Fetches EVERY resource on your redu.cloud account (VMs, volumes, private networks, managed databases: Postgres/MySQL/MariaDB/ClickHouse/Redis/Qdrant, load balancers, and DNS access points) and renders ONE Mermaid diagram of the whole account, grouped into per-private-network subgraphs with repetition collapsed into count nodes (e.g. "App VM x12"). Returns report_markdown to save as redu
| Parameter | Type | Required | Notes |
|---|---|---|---|
| include_volumes | boolean | no | Include block volumes in the map (default true). |
| include_load_balancers | boolean | no | Include load balancers in the map (default true). |
| include_managed | boolean | no | Include managed databases (Postgres/MySQL/MariaDB/ClickHouse/Redis/Qdrant) in the map (default true). |
Creates a snapshot of a running instance.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| instanceId | string | yes | — |
| snapshotName | string | yes | — |
Deletes a snapshot by ID.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
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 VM. Poll list_backups until the new backup is available.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| volumeId | string | no | ID of the volume to back up (see list_volumes). Provide this OR instanceId. |
| instanceId | string | no | ID of the instance to back up — its bootable (else first) attached volume is resolved automatically, so no volume:list scope is needed. Provide this OR volumeId. |
| backupName | string | yes | A name for the 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. DISASTER RECOVERY (the original VM is gone, so its volume died with it): restore with volumeName to rebuild the data as a NEW volume. To bring the MACHINE back, pass that volume as create_instance's boot_volume_id - it boots from the restore
| Parameter | Type | Required | Notes |
|---|---|---|---|
| backupId | string | yes | ID of the backup to restore (see list_backups). |
| volumeId | string | no | Optional: restore into this existing volume. |
| instanceId | string | no | Optional: restore into this instance's volume (resolved automatically). The target volume must be available (detached), so stop the instance first. |
| volumeName | string | no | Optional: name for a new volume to restore into. Omit volumeId and instanceId to restore into a new volume. |
Deletes a backup by ID.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
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 enabled, redu's nightly job backs the service up on its own and prunes to the retention window; see them with list_backups and recover with the service's restore. Works for managed Postgres/MySQL/MariaDB/Redis/Qdrant/ClickHouse and can be flipped
| Parameter | Type | Required | Notes |
|---|---|---|---|
| service | string | yes | Which managed data-service type the id belongs to. A managed Postgres from create_database/list_databases is 'postgres'; MySQL/MariaDB from create_relational_database; plus redis/qdrant/clickhouse. |
| id | yes | Numeric id of the managed service (from list_databases / list_redis / list_relational_databases / etc.). | |
| enabled | boolean | yes | true = turn ON nightly AUTOMATED backups for this service; false = turn them off. |
| retention | integer | no | How many days of nightly backups to keep (optional; keeps the current setting if omitted). |
Creates a block storage volume.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| name | string | yes | — |
| size | integer | yes | — |
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) rebuilds the data into a new volume, then attach_volume puts that volume on a replacement instance — then SSH in (get_ssh_command) and mount it (lsblk to find it, usually /dev/vdb, then mount /dev/vdb /mnt/...). The volume must be 'available
| Parameter | Type | Required | Notes |
|---|---|---|---|
| volume_id | string | yes | Volume to attach/detach — from list_volumes (id). For a recovery, this is the volume restore_backup created (restore_backup with volumeName makes a NEW volume from a backup). |
| instance_id | string | yes | Instance to attach it to / detach it from — from list_instances (id). |
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 (umount /mnt/...) or you risk a dirty filesystem. You cannot detach an instance's ROOT/boot disk while it runs. Use this to move a data volume to another VM, or to free a restore target before restore_backup writes into it. Poll list_volumes un
| Parameter | Type | Required | Notes |
|---|---|---|---|
| volume_id | string | yes | Volume to attach/detach — from list_volumes (id). For a recovery, this is the volume restore_backup created (restore_backup with volumeName makes a NEW volume from a backup). |
| instance_id | string | yes | Instance to attach it to / detach it from — from list_instances (id). |
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 note you cannot detach a running instance's boot disk. A volume left behind after a restore keeps billing, so delete the ones you no longer need. Any BACKUP the volume was restored from is independent and survives this.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | yes | ID of the resource to delete. |
Returns the DNS TXT record to add for custom domain ownership verification. Add the record to your DNS provider, then call verify_domain.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| domain | string | yes | The custom domain to verify ownership of (e.g. app.example.com). |
Checks the DNS TXT ownership record for a custom domain and marks it verified when the record is present. Call get_domain_verification first, add the TXT record at your DNS provider, then call this until status is verified.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| domain | string | yes | The custom domain to verify ownership of (e.g. app.example.com). |
Checks if your account has everything needed to run autonomous coding agents. Returns a checklist: API key validity, private network, SSH keypair, and billing. Safe to call anytime — read-only. Call this first before create_controller.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| github_pat | string | no | GitHub Personal Access Token to validate (repo + workflow scopes required) |
Creates a self-configuring controller VM on redu.cloud. Auto-discovers your network, Ubuntu image, and flavor. Generates and uploads an SSH keypair if you don't have one. The VM bootstraps itself — no SSH or VPN needed. After ~7 minutes, authorize the fleet (run the authorize.sh one-liner it returns) then call trigger_agent_batch.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| github_pat | string | yes | GitHub Personal Access Token (repo + workflow scopes) |
| repo | string | yes | GitHub repo to run agents on, e.g. 'owner/repo' |
| worker_count | integer | no | Number of worker VMs to provision (default 3) |
Starts the autonomous agent batch on your controller VM. Agents read agent-ready tasks from your ROADMAP.md, implement them in parallel, and open PRs. No VPN needed — runs over HTTPS; the controller stays running after you disconnect. Each ROADMAP task MUST be a single checkbox line - [ ] Title — short description *(agent-ready)* (the - [ ], bold title, and *(agent-ready)* are all
| Parameter | Type | Required | Notes |
|---|---|---|---|
| controller_url | string | yes | HTTPS URL of your controller VM |
| trigger_token | string | yes | Trigger token from the controller |
Returns the current status of your controller VM. On a freshly set-up VM also returns the trigger token needed to authorize the fleet and to call trigger_agent_batch. Call this after setup_agent_fleet to confirm the VM is ready.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| controller_url | string | yes | HTTPS URL of your controller VM, e.g. https://redu-controller-abc123.redu.cloud |
| log_token | string | no | Log token for fetching controller logs (optional — returned by this tool on first call) |
One-shot tool that guides you through the complete agent setup: checks prerequisites, creates the controller VM, and returns next steps. Ideal for first-time setup. Call this when a user says 'set up autocoding agents for my repo'.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| github_pat | string | yes | GitHub Personal Access Token (repo + workflow scopes) |
| repo | string | yes | GitHub repo, e.g. 'owner/repo' |
Complete one-shot setup: validates prerequisites, creates a controller VM + worker VMs, auto-creates a public HTTPS URL on port 7070, seeds a starter ROADMAP.md into the repo if absent, and returns the trigger token. Call this when a user says 'set up autocoding agents for my repo' or 'I want agents to work on my codebase'. HOW THE AGENT WORKS: each worker runs Claude Code inside the repo, impleme
| Parameter | Type | Required | Notes |
|---|---|---|---|
| github_pat | string | yes | GitHub Personal Access Token with repo + workflow scopes. Used to clone the repo and open PRs. |
| repo | string | yes | GitHub repo to run agents on, e.g. 'owner/my-app'. Must be accessible with the PAT. |
| worker_count | integer | no | Number of parallel worker VMs (default 3). Each works on a separate task simultaneously. |
Free
$0 forever
- Every tool — any call limit is its publisher’s, not ours
- No card, and mcprush charges nothing for it
- Runs at its publisher’s own address — this marketplace is not in the path
- Nothing to cap, because mcprush bills nothing
What counts against your monthly calls
| Tool | Unit | Calls used | Out of the allowance |
|---|
Nothing here is billable: mcprush charges nothing to install Redu Cloud MCP or to call it, at any volume.
Call allowance · this installenforced at the gateway
Monthly allowance, in calls
—
—
Alert at 80% · then the tool returns a normal MCP error
Used this month: —
—Grade not published
No rule-by-rule report on file for this release
Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.
This listing is an address its publisher runs, and you connect to it directly — this marketplace is not in the path. The scanner reads packages and public source, and an address is neither. So there is no grade — not a withheld one, an unmeasured one.
Release history
This is an address its publisher runs: which release it serves is theirs to choose, so there is nothing here to pin. The history below is for reading; the current release on file is 2.0.0.
2.0.0
undated
latestNo release note was published with this version.
—
no reviews yet
Who can review
One review per account, from a signed-in account that does not publish this listing. Nothing else is asked — you can say what you think before you install it. Publishers can reply once per review, and a review can be edited or deleted by whoever wrote it.
Sign in to write one
Any signed-in account that does not publish Redu Cloud MCP can review it, once — before installing it or after. A review from an account that has installed it is marked as one.
No reviews yet
Nobody has reviewed this listing. The rating on the card is the mean of the reviews written here and nothing else, so there is no rating until somebody writes the first — which takes a signed-in account that does not publish it, and nothing else.