Agent-native cloud, EU-hosted. Provision VMs, networks & databases on redu.cloud via MCP.
| Endpoint | https://mcp.redu.cloud/mcp (streamable-http) |
|---|---|
| Registry version | 0.1.1 |
| Now | 90 tools · grade F (0) · pin ts_f46bfe67fb83d1d24d65c240c45fb77c · protocol 2025-06-18 |
| First / last listed | 2026-10-25 05:20 UTC / 2026-10-25 05:20 UTC |
| Grade over time | 2026-10-25: F (0), 90 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: get_private_vps_pilot create_private_vps whoami check_deploy_prerequisites deploy_overview create_api_key list_api_keys delete_api_key integrate_overview prepare_upload scaffold_local plan_instance plan_managed_datastore select_surface plan_deploy list_instances list_flavors list_images list_keypairs list_security_groups list_private_networks list_volumes list_snapshots list_backups list_clusters list_dns_entries list_domains list_regions list_databases list_relational_databases list_media_spaces list_clickhouse_databases list_redis list_qdrant create_media_space upgrade_to_cluster update_cluster set_cluster_domain delete_cluster import_keypair delete_keypair get_ssh_command get_instance_logs instance_action create_instance delete_instance create_database delete_database create_relational_database delete_relational_database create_clickhouse delete_clickhouse upgrade_to_ha create_redis delete_redis create_qdrant delete_qdrant deploy_app deploy_compose deploy_vpn list_deployments verify_deployment delete_deployment wait_for_deployment get_deployment get_containers get_container_logs get_resource_usage get_env_keys architecture_diagram create_snapshot delete_snapshot create_backup restore_backup delete_backup set_managed_backups create_volume attach_volume detach_volume delete_volume get_domain_verification verify_domain release_domain delete_dns_entry check_agent_prerequisites create_controller trigger_agent_batch get_agent_status setup_agent_session setup_agent_fleet
get_private_vps_pilot | Read your private VPS pilot approval and occupied website/database slots. This does not create a VM or change billing. params: none |
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 with plain Ubuntu. Maximum one of each, including pending and stopped VMs. The pair shares a 5 GB outgoing Internet budget; incoming and private traffic do not count. Pilot VMs and their specified boot disks have no charge. Existing paid reso params: kind*, name*, request_key* |
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. params: none |
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) an SSH keypair (if you have none, returns ssh_key_recipe: the exact local ssh-keygen → import_keypai params: mode |
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 when a user asks to deploy/ship/host an app and you're unsure where to start. params: none |
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 is BILLED to the account owner. Show the user the name, the exact scopes, and the billing notice, ge params: name*, scopes*, expires_in_days, confirm |
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. params: none |
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 for a task that is finished. params: id, name, confirm |
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_key), inject it into the app, and call the redu API from the app. Call this when a user asks to add/i params: none |
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 AUTOMATICALLY with a short-lived ticket minted from your MCP credential - NO API key needed in the comma params: project_dir, is_git_repo |
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 to deploy_app any time. Honest caveat: the local Postgres is NOT the managed Postgres, so a green loc params: runtime*, port, needs_postgres, has_container |
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). params: osHint, sizeHint |
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, so the ones you report in send_signals are started and wired for you. Pass ha:true to plan a highly params: engine, sizeHint, ha |
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 > a self-contained web app > a keys-required playground > an API > a headless worker > docs/examples) params: surfaces*, mode |
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: run prepare_upload FIRST and pass its `source_token`; redu reads all three straight out of the upload params: source_token, redu_md, compose_yaml, dockerfile, runtime*, containerizable, serves_http, port, worker, start, has_container, needs_postgres, needs_redis, needs_clickhouse, needs_vector_db, needs_compose, app_profile, cluster_target, cluster_media_mode, media_origin_url, media_space_id, create_media_space, media_space_size_gb, media_space_flavor, media_mount_path, db_engine, vm_count, single_vm, app_flavor, db_flavor, clickhouse_flavor, heavy_build, memory_heavy, deploy_mode |
list_instances | Lists your compute instances. params: none |
list_flavors | Lists available instance sizes. params: none |
list_images | Lists available OS images. params: none |
list_keypairs | Lists your SSH keypairs. If empty, call import_keypair first before creating instances. params: none |
list_security_groups | Lists your security groups. params: none |
list_private_networks | Lists your private networks. params: none |
list_volumes | Lists your block storage volumes. params: none |
list_snapshots | Lists your instance snapshots. params: none |
list_backups | Lists your volume backups. params: none |
list_clusters | Lists your autoscaling clusters. params: none |
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 removes one by its id. params: none |
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, or set_cluster_domain) or pending (its TXT check has not passed: get_domain_verification gives the record, verify_domain checks it). The public names that use a domain are in list_dns_entries. release_domain removes a domain from the account params: none |
list_regions | Lists available regions. params: none |
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). params: none |
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). params: none |
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. params: none |
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). params: none |
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>. params: none |
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. params: none |
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 manually preparing or reusing shared uploads storage. params: idempotency_key, name*, size_gb, flavor_id, network_id, keypair_name*, security_group_names, mount_path |
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 redeploy, and the URL does not change. Turns a single running instance into a horizontally-autoscal params: idempotency_key, instance_id*, name*, flavor_id*, network_id*, keypair_name*, port, high_availability, max_size, startup_command, scale_out_threshold, scale_in_threshold, dname, app_profile, cluster_media_mode, media_origin_url, media_space_id, create_media_space, media_space_name, media_space_size_gb, media_space_flavor_id, media_mount_path, confirm_stateless, auto_restructure, restructure_engine, restructure_db_flavor_id |
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 AT A TIME and refreshes the image the group boots future members from - the SAME load balancer and S params: idempotency_key, stack_name*, stack_id*, instance_id* |
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 members, same load balancer, same data - only the name in front of it changes. Pass stack_name + stack params: stack_name*, stack_id*, domain* |
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 member but it is your own VM; delete_instance it separately if you no longer need it. Pass stack_name + s params: stack_name*, stack_id* |
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. params: name*, public_key* |
delete_keypair | Removes an SSH keypair from your account by name. params: 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 which one you are holding (a deployment's instance_id is a placeholder until provisioning finishes, and params: instance_id*, keypair_name |
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 questions: the machine never came up, the disk did not mount, cloud-init failed before the app existed. params: instance_id* |
instance_action | Start, stop, or reboot an instance. action must be START, STOP, REBOOT_SOFT, or REBOOT_HARD. params: instanceId*, action* |
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_init_template='reduos' and flavor m1.xlarge (16GB). SSH keypair must exist. For a public web app on a params: idempotency_key, name*, image_id*, flavor_id*, keypair_name*, network_id*, security_group_names, port, dname, dns_entries, user_data, cloud_init_template, volume, boot_volume_id, imageName |
delete_instance | Permanently deletes an instance. This cannot be undone. params: id* |
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 same private network, via the DB's internal/private IP (not a public address). Get the ids from plan params: idempotency_key, name*, flavor_id*, network_id*, keypair_name*, db_name, db_user, db_password, version, extensions, superuser, ha, security_group_names |
delete_database | Deletes a managed Postgres database and its underlying VM. Pass the numeric database id from list_databases. This cannot be undone. params: id* |
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 app deployments, prefer deploy_app database:'managed' with db_engine mysql/mariadb so plan_deploy inc params: idempotency_key, name*, engine, flavor_id*, network_id*, keypair_name*, db_name, db_user, db_password, version, security_group_names |
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. params: id* |
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, Langfuse, event analytics, time-series). It is PRIVATE - reachable only from another instance on th params: idempotency_key, name*, flavor_id*, network_id*, keypair_name*, db_name, db_user, db_password, superuser, ha, security_group_names |
delete_clickhouse | Deletes a managed ClickHouse database and its underlying VM. Pass the numeric id from list_clickhouse_databases. This cannot be undone. params: id* |
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 NOT have to create a new one and migrate by hand. How it works: a full backup is taken first (a safe params: service*, id*, acknowledge_write_loss, flavor_id, network_id, keypair_name |
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 enabled. Get the ids from plan_managed_datastore/list_flavors, list_private_networks (or check_deploy_p params: idempotency_key, name*, flavor_id*, network_id*, keypair_name*, version, password, security_group_names |
delete_redis | Deletes a managed Redis instance and its underlying VM. Pass the numeric id from list_redis. This cannot be undone. params: id* |
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). Backups: set_managed_backups with service 'qdrant'. FOR AN APP YOU DEPLOY YOU DO NOT NEED THIS: report ve params: idempotency_key, name*, flavor_id*, network_id*, keypair_name*, api_key, security_group_names |
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. params: id* |
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 be the real app listen port. DATASTORES ARE MANAGED BY DEFAULT: each one you reported in send_signals params: approved, idempotency_key, name*, repo, source_token, dockerfile_content, dockerfile, context, git_ref, subdir, git_token, runtime, port, app_profile, cluster_target, cluster_media_mode, media_origin_url, media_space_id, create_media_space, media_space_name, media_space_size_gb, media_space_flavor_id, media_mount_path, worker, data_paths, dname, env, db_id, database, db_engine, db_name, db_user, db_version, db_flavor_id, db_extensions, db_superuser, redis, redis_version, redis_flavor_id, redis_password |
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_deploy first. PORT is the HOST port for the exposed service. DATASTORES ARE MANAGED BY DEFAULT: each one params: approved, idempotency_key, name*, repo, source_token, git_ref, subdir, git_token, compose_file, migrate_command, migrate_service, compose_engine, service, port, dname, expose, env, app_profile, cluster_target, cluster_media_mode, media_origin_url, media_space_id, create_media_space, media_space_name, media_space_size_gb, media_space_flavor_id, media_mount_path, database, db_engine, db_name, db_user, db_version, db_extensions, db_superuser, db_flavor_id, redis, redis_version, redis_flavor_id, redis_password, qdrant |
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; it is NOT a general internet VPN. GUARDRAIL: the first call does NOT deploy - it returns the plan params: keypair_name*, name, network_id, flavor_id, client_cidr, confirm |
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. params: none |
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. Redeploying working infrastructure to clear a red flag wastes the user's money and throws away the f params: id* |
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. 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_relatio params: id* |
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 PUBLIC url (not the VM's private interface, which can answer 401 while the public path still 502s), the params: id*, timeout_s |
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 only, with build_log_truncated:true and build_log_total_lines so you can tell a short build from a params: id*, redu_md |
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 for SSH. get_deployment returns the deployment ROW (status, URL, build log); it cannot see inside the params: deployment_id* |
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_instance_logs for this. That returns the VM's SERIAL CONSOLE (kernel messages and cloud-init), which a params: deployment_id*, service, tail, since |
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, and to explain a container that keeps dying (an OOM kill leaves no application log at all - the proces params: deployment_id* |
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 can confirm the DB was connected, spot a typo'd key, and see which of the app's documented variable params: deployment_id* |
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 with repetition collapsed into count nodes (e.g. "App VM x12"). Returns report_markdown to save as redu params: include_volumes, include_load_balancers, include_managed |
create_snapshot | Creates a snapshot of a running instance. params: instanceId*, snapshotName* |
delete_snapshot | Deletes a snapshot by ID. params: 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. params: volumeId, instanceId, backupName* |
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 bring the MACHINE back, pass that volume as create_instance's boot_volume_id - it boots from the restore params: backupId*, volumeId, instanceId, volumeName |
delete_backup | Deletes a backup by ID. params: 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 service's restore. Works for managed Postgres/MySQL/MariaDB/Redis/Qdrant/ClickHouse and can be flipped params: service*, id*, enabled*, retention |
create_volume | Creates a block storage volume. params: name*, size* |
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 (`lsblk` to find it, usually /dev/vdb, then `mount /dev/vdb /mnt/...`). The volume must be 'available params: volume_id*, instance_id* |
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 to another VM, or to free a restore target before restore_backup writes into it. Poll list_volumes un params: volume_id*, instance_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 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. params: id* |
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 call verify_domain. Until it verifies, list_domains shows the domain as pending. A pending claim's TXT value can change (values are specific to each account), so add exactly the value get_domain_verification returns now, never one saved earl params: domain* |
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 the record, have the user add it at their DNS provider, then call this until it reports verified (a new record can take minutes, sometimes hours, to show). A verified domain can be bound: dname on deploy_app/deploy_compose, dns_entries on c params: domain* |
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 cancelled. The first call releases nothing: it shows the domain for the user to approve; call again with confirm:true only after their yes. The second call reports the platform's answer: released, or refused. A refusal because public names still u params: domain*, confirm |
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 site, an API, an OAuth callback) stops working with it. When the name belongs to one of your instances or deployments, that instance's own list of its names is updated too, the way the console's DNS view does it; the instance, its app and params: id, name, confirm |
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. params: github_pat |
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) then call trigger_agent_batch. params: github_pat*, repo*, worker_count |
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** - short description *(agent-ready)*` (the `- [ ]`, `**bold title**`, and `*(agent-ready)*` are all params: controller_url*, trigger_token* |
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. params: controller_url*, log_token |
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'. params: github_pat*, 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 to work on my codebase'. HOW THE AGENT WORKS: each worker runs Claude Code inside the repo, impleme params: github_pat*, repo*, worker_count |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.