cloud.redu/mcp · v0.1.1 · cloud-and-infra
cloud.redu/mcp is healthy: it completed an MCP handshake in 4225 ms and exposes 86 tools. It scores 52/100.
Agent-native cloud, EU-hosted. Provision VMs, networks & databases on redu.cloud via MCP.
Endpoint: https://mcp.redu.cloud/mcp (streamable-http)
No repository listed · JSON · Add to my inventory
| health | 17 / 25 |
| authEase | 15 / 15 |
| toolQuality | 12 / 15 |
| maintenance | 3 / 15 |
| adoption | 0 / 10 |
| usage | 0 / 10 |
| security | 5 / 10 |
Scoring v0.3, computed 2026-10-14T17:26:05.075Z.
| Checked (UTC) | Status | Latency | Error |
|---|---|---|---|
| 2026-10-14T17:25:46.395Z | Healthy | 4225 |
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 merely that one is configured. Use this first if anything is 401ing. |
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 deploy_app (so you never hunt for them): (1) account reachable + quota, (2) a private network (picks your default — every account has one), (3) |
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, 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 wh |
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 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 |
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 find a key to delete with delete_api_key, or to check what keys exist before minting another. |
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 (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 fo |
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 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_k |
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, capture `source_token` from the upload's JSON response, then call deploy_app with that source_token (omit repo). The upload authenticates AUTO |
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 — 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 t |
plan_instance | 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). |
plan_managed_datastore | 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, |
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, classify by its EXPOSE + CMD — never by directory name) and pass them in; redu RANKS them with fixed rules (a standalone browser desktop/noVNC > |
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 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: r |
list_instances | Lists your compute instances. |
list_flavors | Lists available instance sizes. |
list_images | Lists available OS images. |
list_keypairs | Lists your SSH keypairs. If empty, call import_keypair first before creating instances. |
list_security_groups | Lists your security groups. |
list_private_networks | Lists your private networks. |
list_volumes | Lists your block storage volumes. |
list_snapshots | Lists your instance snapshots. |
list_backups | Lists your volume backups. |
list_clusters | Lists your autoscaling clusters. |
list_dns_entries | Lists DNS proxy host entries. |
list_domains | Lists custom domains you have verified ownership of. |
list_regions | Lists available regions. |
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_user). |
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 the private-network connection details (private_ip, port 3306, db_name, db_user). |
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-content/uploads, or pass create_media_space:true to deploy_app/deploy_compose/upgrade_to_cluster so Redu creates one. |
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-network connection details (private_ip, ClickHouse HTTP port 8123, db_name, db_user). |
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 another instance on the same private network with redis-cli -h <private_ip> -p 6379 -a <password>. |
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 6334); the API key is never listed. |
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. Prefer letting deploy_app/deploy_compose create this by passing create_media_space:true after plan_deploy approval; use this tool when manu |
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, 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 |
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 — it is also the always-on baseline member that serves traffic), then redu rolling-updates the autoscaled extra members to that snapshot ONE |
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 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 me |
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 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 membe |
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 machine. |
delete_keypair | Removes an SSH keypair from your account by name. |
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 DATASTORE's id / name / instance_id (Postgres, MySQL/MariaDB, ClickHouse, Redis) - it resolves all of them, so you do not have to work out whic |
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 failed DB connection - use get_container_logs, which returns what the containers actually printed. Reach for this one only for boot-level ques |
instance_action | Start, stop, or reboot an instance. action must be START, STOP, REBOOT_SOFT, or REBOOT_HARD. |
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/deploy_compose; do not use create_instance as a shortcut around the deployment plan. Requires a recent plan_instance. For reduOS, set cloud_in |
delete_instance | Permanently deletes an instance. This cannot be undone. |
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_app database:'managed' so plan_deploy includes and wires the DB automatically. It is PRIVATE — reachable only from another instance on the |
delete_database | Deletes a managed Postgres database and its underlying VM. Pass the numeric database id from list_databases. This cannot be undone. |
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_database when the app needs MySQL/MariaDB, e.g. WordPress, NextCloud, Matomo, many PHP/LAMP apps). Requires a recent plan_managed_datastore. For a |
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. |
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 relational database. Requires a recent plan_managed_datastore. Use it for analytics / observability workloads that need a column store (PostHog, |
delete_clickhouse | Deletes a managed ClickHouse database and its underlying VM. Pass the numeric id from list_clickhouse_databases. This cannot be undone. |
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 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 |
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 another instance on the same private network, via its internal/private IP on port 6379 (not a public address). AUTH (requirepass) is always ena |
delete_redis | Deletes a managed Redis instance and its underlying VM. Pass the numeric id from list_redis. This cannot be undone. |
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 at <private_ip>:6333 (REST) and :6334 (gRPC), and at a public https URL; every request must carry the api-key header (always required). Backu |
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. |
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 first for network_id + keypair_name, then plan_deploy for cost approval. Source can be git repo or prepare_upload source_token. PORT must b |
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.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_deplo |
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 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 |
list_deployments | 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. |
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 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. |
delete_deployment | 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 / |
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, build_failed, error or vm_missing) and returns, in ONE response, everything you would otherwise fetch afterwards: the HTTP status of the PUBL |
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_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 |
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 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 fo |
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 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_in |
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-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, an |
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. 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 |
architecture_diagram | 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 wit |
create_snapshot | Creates a snapshot of a running instance. |
delete_snapshot | Deletes a snapshot by ID. |
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 VM. Poll list_backups until the new backup is available. |
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. 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 brin |
delete_backup | Deletes a backup by ID. |
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 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 se |
create_volume | Creates a block storage volume. |
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) 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 ( |
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 (`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 t |
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 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 ne |
get_domain_verification | Returns the DNS TXT record to add for custom domain ownership verification. Add the record to your DNS provider, then call verify_domain. |
verify_domain | 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. |
check_agent_prerequisites | 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. |
create_controller | 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 |
trigger_agent_batch | 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** |
get_agent_status | 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. |
setup_agent_session | 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'. |
setup_agent_fleet | 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 |