cubepath_alert_channel_delete
ChatGPTDeletes a notification channel. It only works if no Cloud Alert uses it yet: if any references it, the operation is rejected and it has to be removed from those alerts first with cubepath_alert_set. It is irreversible (the webhook URL would have to be pasted again), so confirm with the user; to silence it temporarily enabled = false is enough.
cubepath_alert_channel_set
ChatGPTCreates or edits the channel Cloud Alerts send their notifications to. Without channel_id it creates, and then name and type are required; with channel_id it only edits what you send. Type 'email' notifies the account's address and takes no configuration; 'slack' and 'discord' need the channel's incoming webhook URL, which the user has to provide. Use enabled = false to silence a channel without deleting it. Maximum 5 channels per organization. When read back, the webhook URL appears masked on purpose.
cubepath_alert_delete
ChatGPTDeletes a Cloud Alert together with its history. It stops watching and notifying immediately and cannot be undone. Confirm with the user before calling it. If they only want to silence it for a while, do not delete it: disable it with cubepath_alert_set and status = disabled.
cubepath_alert_list
ChatGPTReturns the organization's Cloud Alerts (which metric they watch, on which server, with which threshold and in which state) together with the available notification channels (email, Slack, Discord). It is the entry point for any question about alerts: call it first to translate the name of an alert or of a channel into its identifier. Pass alert_id to see a single alert with the detail of its actions, and include_history to know when it fired and when it recovered. The channels always come along because an alert's actions reference them by id.
cubepath_alert_set
ChatGPTCreates a new Cloud Alert or edits an existing one. Without alert_id it creates, and then project_id, name, target_type, target_id, metric, operator, threshold and channel_ids are required. With alert_id it updates and only the fields you send are touched. Use it also to enable or disable an alert without deleting it (status). Resolve the server id first with cubepath_project_list and the channel ids with cubepath_alert_list. The alert fires when the metric meets the condition for duration_seconds in a row, and does not notify again until cooldown_seconds have passed. Careful: not every metric is valid for every target ({'vps': ['cpu', 'disk', 'network_in', 'network_out', 'ram'], 'baremetal': ['network_in', 'network_out'], 'availability_group': ['cpu', 'disk', 'network_in', 'network_out', 'ram']}). Maximum 20 alerts per organization.
cubepath_baremetal_bmc_sensors
ChatGPTReturns the physical health of a server as read by its BMC/IPMI: temperatures and fan speeds summarized to minimum, maximum and average, with the worst readings in detail, plus whether the BMC responds and whether the machine is powered on. Use it when the user suspects overheating, noise or a hardware failure, or to check whether a server that does not answer over the network is at least powered on. It fails if the server has no BMC monitoring configured.
cubepath_baremetal_catalog
ChatGPTCatalog of dedicated servers, with two modes. Without baremetal_id it returns the models that can be ordered grouped by location, with specifications, monthly price, setup fee and available stock: use it before cubepath_baremetal_deploy or when the user asks about prices or availability. With baremetal_id it returns the operating systems and the disk layouts compatible with THAT specific server: use it before cubepath_baremetal_reinstall to pick a valid os_name and disk_layout_name, because the listing depends on the number and type of disks in the machine.
cubepath_baremetal_deploy
ChatGPTOrders a dedicated server and deploys it in a project. It CHARGES THE USER'S CARD on the spot (setup fee plus the first month) and commits physical hardware: it is not reversible and it is not prorated. ALWAYS confirm the model, the location and the amount with the user before calling it, checking cubepath_baremetal_catalog first to pick a valid model_name and location_name and to make sure there is stock. The installation is queued and takes a while: check cubepath_baremetal_list to follow the status, do not repeat the call. If the bank asks for 3D Secure the operation is left halfway and the user has to finish it in the panel.
cubepath_baremetal_list
ChatGPTReturns every dedicated (baremetal) server in the organization with its hostname, status, model and physical specifications (CPU, RAM, disks), installed operating system, public IPs, SSH keys, location, project, protection and billing cycle. This is how to resolve a server identifier from its hostname: call it before any tool that takes a baremetal_id. There is no individual detail endpoint, this listing already brings all the information about each server.
cubepath_baremetal_metrics
ChatGPTReturns the network traffic of a dedicated server over a time window (inbound and outbound bytes and packets), summarized to minimum, maximum, average and last value plus a trimmed series, along with the total traffic used in the current month. Use it to diagnose port saturation, to see whether a server is transmitting when it should not, or when the user asks how much traffic they have used. It does not measure CPU or memory: that is monitored from the server itself. A server with no switch ports assigned returns empty series.
cubepath_baremetal_network
ChatGPTWith action='attach' it connects a dedicated server to a private network of the organization and assigns it an internal IP, adding the VLAN to the machine's switch port: use it so that it talks to other servers without going out to the Internet. A server can only be in one private network at a time, the network must be in its same location and the server must have switch ports assigned. With action='detach' it takes it out of the network and releases its internal IP, so any service that depended on that IP stops working: warn the user. In both cases the interface has to be configured inside the operating system for the change to take effect. Get the network_id with cubepath_project_list.
cubepath_baremetal_power
ChatGPTChanges the power state of a dedicated server through its BMC. The order is queued and takes a few seconds: check the result with cubepath_baremetal_bmc_sensors (power_on field) instead of repeating the call. Stopping or restarting cuts the service abruptly, with no orderly shutdown of the system: warn the user first. It is rejected if the server is suspended or has an installation in progress.
cubepath_baremetal_recovery
ChatGPTOut-of-band recovery operations on a dedicated server. With action='rescue' it reboots the machine into an in-memory rescue environment to repair the system, recover data or check the disks: it does NOT delete anything, but the service is down until it is booted normally again. The rescue credentials are emailed to the technical contact, they are not returned here. With action='reset_bmc' it cold-restarts the management controller, which stops responding for 1 or 2 minutes, without touching the operating system: use it when the BMC is hung and the console or the power actions do not answer. Confirm with the user in both cases.
cubepath_baremetal_reinstall
ChatGPTWith action='install' it wipes the server disks and installs the given operating system from scratch. ALL the content is lost and there is no way back, and there are no automatic backups on baremetal. Always confirm with the user, identifying the server by hostname. Use cubepath_baremetal_catalog with baremetal_id first to get a compatible os_name and disk_layout_name. It fails if the server has protection enabled: remove it with cubepath_baremetal_update only if the user explicitly asks for it. With action='cancel' it aborts an installation that has not started writing to disk yet.
cubepath_baremetal_update
ChatGPTChanges the configuration of a dedicated server: hostname, labels, monitoring, protection against reinstallations, project it belongs to and authorized SSH keys. Give only the fields you want to change; if you give none the call is rejected. Use it also to unlock a protected server before reinstalling it, when the user explicitly asks for it. The changes are applied one by one: if one fails, the previous ones have already been saved. None of this restarts the server or interrupts the service, and the new SSH keys do not reach the installed system until the next reinstallation.
cubepath_cdn_metrics
ChatGPTTraffic analytics for a CDN zone over the last minutes minutes. The value of metric picks what is returned: 'summary' totals of requests and bytes served with cache hit rate and error rate; 'requests' requests per second over time; 'bandwidth' bytes per second over time, or split by region with group_by='region'; 'cache' cache hits and misses over time with their total; 'status_codes' breakdown of 2xx/3xx/4xx/5xx responses; 'top_urls' most requested paths with their traffic; 'top_countries' countries that request the most; 'top_asn' networks (carriers) that request the most; 'top_user_agents' clients that request the most, useful to spot bots; 'blocked' blocked requests grouped by reason, to see what the WAF is doing; 'pops' split by CDN PoP with their cache hit rate; 'file_extensions' file types served the most. Time series are grouped into about 24 points and top-N lists are shortened so they do not fill the context: raise limit or interval_seconds only if needed. The filters (country, asn, status, cache_status, device_type, path_prefix...) narrow the analysis; the ones that do not apply to the requested metric are ignored and reported.
cubepath_cdn_origin_delete
ChatGPTRemoves an origin from the zone. If it was the only one, the zone is left with nothing to serve and starts returning errors: confirm with the user. To take it out of rotation without losing the configuration use cubepath_cdn_origin_set with enabled set to false. Deleting the origin of an Object Storage bucket also revokes the CDN's access to that bucket, which stops being served. Resolve the UUID first with cubepath_cdn_zone_list.
cubepath_cdn_origin_set
ChatGPTConfigures where the CDN pulls the content from. Without origin_uuid it creates a new origin; with origin_uuid it updates the existing one and only changes the fields you send. The easiest way is to pass the full origin_url (e.g. https://s3.eu-central-2.wasabisys.com/my-bucket/): address, port, protocol, Host header and base path are derived from it. A zone can have several origins with weights and priorities, and one marked as backup. For private S3 buckets at another provider (AWS, Wasabi, R2, Backblaze) enable s3_auth_enabled and pass the credentials: the edge signs every request with SigV4. To publish one of the user's CubePath Object Storage buckets (the only way to serve a bucket publicly), create the origin with name and object_storage_bucket_uuid and nothing else: the connection is configured from the bucket and the origin starts serving a few seconds later. That needs the object_storage:write scope as well, one CDN origin per bucket; delete the origin with cubepath_cdn_origin_delete to stop serving the bucket. A zone's current origins are visible through cubepath_cdn_zone_list by passing its zone_uuid.
cubepath_cdn_purge_cache
ChatGPTRemoves cached copies from every CDN location so the next request fetches the file again from the origin. Use it after the user changed files at the origin and the CDN still serves the old version. Send everything: true to purge the whole zone, or paths (up to 100) to purge specific files; a path ending in '*' purges everything under that prefix. Prefer paths over everything: purging the whole zone sends all traffic back to the origin until the cache fills again. It is asynchronous: check progress with cubepath_cdn_purge_list. An identical purge that is queued but not started yet is reused, not duplicated. Only works on active zones. Each organization may request 300 purges per hour, at most 60 of them whole-zone or prefix purges; past that the call fails with 429.
cubepath_cdn_purge_list
ChatGPTShows the latest 100 cache purges of a zone, newest first, with their status (pending, in_progress, completed, partial, failed, expired) and node progress. Use it to check whether a purge requested with cubepath_cdn_purge_cache has finished.
cubepath_cdn_rule_delete
ChatGPTDeletes a rule from the zone. The behavior it enforced (cache, redirect, block or limit) disappears as soon as it propagates and cannot be undone. If you only want to pause it, use cubepath_cdn_rule_set with enabled set to false. Resolve the UUID first with cubepath_cdn_rule_list.
cubepath_cdn_rule_list
ChatGPTReturns a zone's rules with their conditions and configuration. There are two families: 'edge' (cache, cache_bypass, redirect, header_request, header_response), which controls how content is cached and answered, and 'waf' (firewall_ip, firewall_country, firewall_ua, rate_limit, js_challenge and the speed, request, connection and bandwidth limits), which controls what gets blocked or throttled. By default it lists both. Use it to find out why the CDN caches or blocks something, and to resolve a rule's UUID before modifying it; with rule_uuid it returns only that one.
cubepath_cdn_rule_set
ChatGPTCreates or updates a rule of the zone. Without rule_uuid it creates a new one and rule_type plus action_config are required; with rule_uuid it updates the existing one and only changes what you send (the type cannot be changed: delete and create). Use it to cache specific paths with their TTL (rule_type 'cache'), bypass the cache ('cache_bypass'), redirect ('redirect'), add headers ('header_request'/'header_response'), or block and throttle traffic: by IP, country or user-agent, with a rate limit, with a JavaScript challenge or with caps on speed, requests, connections and monthly bandwidth. match_conditions narrows which requests it applies to and priority decides the order (lower goes first).
cubepath_cdn_token_sign_url
ChatGPTReturns a signed, expiring URL for a file in a zone with Token Auth enabled, without having to reimplement the signature. Use it when the user wants to grant temporary access to protected content or to check that Token Auth works. If the zone binds signatures to the client IP, client_ip is required. It does not expose the zone's secret.
cubepath_cdn_zone_create
ChatGPTCreates a CDN zone. The zone starts with no origins: it serves nothing until you add at least one with cubepath_cdn_origin_set. It is published at '{name}.cubecdn.io' (SSL for that domain is already in place); to serve it under a custom domain pass custom_domain and then point a CNAME from that domain to the system one. It is a billable resource: it charges the plan's hourly rate plus the traffic served, so confirm the plan with the user. Check the plans with cubepath_cdn_zone_list(include_plans=true).
cubepath_cdn_zone_delete
ChatGPTDeletes a CDN zone along with its origins and rules. The content stops being served through the CDN and it cannot be undone: domains pointing there stop responding. Confirm with the user before calling it. There is no soft delete to stop the charges while keeping the configuration: consider disabling the origins with cubepath_cdn_origin_set instead.
cubepath_cdn_zone_list
ChatGPTEntry point for any CDN question. With no arguments it returns the organization's CDN zones in short form (name, system domain, custom domain and its SSL status, plan, status, number of origins and rules, month-to-date charges). With zone_uuid it returns the full detail of one zone: origins with their health status, rules, plan and effective price per GB. With include_plans it adds the CDN plan catalog, which is what you need before creating a zone. Call it first to translate a domain into a UUID: every other CDN tool identifies the zone by its UUID.
cubepath_cdn_zone_update
ChatGPTChanges a CDN zone's configuration: rename it, set or change the custom domain and its SSL (automatic from Let's Encrypt or an already uploaded certificate), enable Token Auth (signed URLs) or CORS, and move it to another project with project_id. Only what you send is touched. With retry_ssl it retries issuing the custom domain's certificate when the first attempt failed on DNS and you have already fixed it; do not retry in a loop, Let's Encrypt caps failed validations at 5 per hour. Enabling Token Auth only works if the zone has had a secret at some point: enabling it from scratch generates a key that is shown only once and this channel cannot hand it over, so that is done from the panel.
cubepath_ddos_attack_list
ChatGPTReturns the DDoS attacks the platform has detected against the organization's IPs, with their date, duration, peak packets per second, peak in Gbps, a description of the attack type and whether they are still active. Use it when the user asks whether they have been attacked, when they report an outage or slowness with no clear cause, and before touching the mitigation configuration, to know which real attack has to be answered. With attack_id and view='details' it gives the breakdown of the mitigations that acted during that attack, and with view='traffic_graph' the traffic evolution during the attack, summarized. Only inbound attacks against own IPs and the recent history are visible, not the entire past.
cubepath_ddos_catalog_list
ChatGPTQueries the catalogs that feed a protection profile's filters: the countries available for the geographic filter, the ASNs (carriers) available for the source network filter, the organization's prefix lists and the contents of one of those lists. Use it to translate what the user asks for ('block China', 'only let Cloudflare through') into the exact codes cubepath_ddos_protection_update needs, and to resolve the UUID of a prefix list. The ASN catalog is huge, which is why it requires a search string.
cubepath_ddos_firewall_rule_edit
ChatGPTManages the firewall rules the DDoS filtering applies to a protected IP: creates a rule, deletes a specific one by its identifier, or bulk-deletes every rule of a subnet matching a protocol and a port. Use it to open or close a port at the mitigation layer, to enable an application-specific protection (FiveM, RDP, DNS, Minecraft, TLS) or to set a rate limit per source IP. A rule that drops traffic cuts the service on that port immediately, and the bulk delete can leave a whole subnet unprotected: confirm with the user before calling it. Maximum 20 rules per IP. When creating on a subnet the rule is replicated on every IP of the block (IPv4 only and a /24 or more specific prefix). The identifier of an existing rule comes from cubepath_ddos_protection_get. Write the IP or subnet exactly as cubepath_ddos_ip_list returns it: a single IP with no mask ('185.20.30.40') or a subnet in CIDR notation ('185.20.30.0/24'). Only IPs of the organization with Premium protection are valid; those with Basic protection do not show up there and are rejected with 403.
cubepath_ddos_ip_list
ChatGPTReturns the organization's IPs and subnets that have Premium DDoS protection, with their location, whether they already have a saved protection profile and how many firewall rules they have applied. It is the starting point of any mitigation question: every other DDoS tool takes an IP or subnet that is resolved here. IPs with Basic protection do not show up, because they accept neither a profile nor rules. For each subnet a summary is returned, not its 254 addresses. The capture_targets field lists the exact strings the traffic queries of cubepath_ddos_traffic_query accept.
cubepath_ddos_prefix_list_edit
ChatGPTCreates or deletes prefix lists and adds or removes networks inside them. A prefix list is a set of CIDR ranges a protection profile can use as a whitelist or a blacklist, useful to always let the user's own networks through or to block specific ranges. Creating the list does not apply it to anything: it has to be assigned afterwards to an IP with cubepath_ddos_protection_update, setting prefix_list_mode there to 1 or 2. Deleting a list is irreversible: it removes all its networks and unassigns it from every profile that used it, so the filtering of those IPs changes immediately. Confirm it with the user. Maximum 3 lists per organization and 100 networks per list. The platform's global lists can be used but not modified. The UUIDs come from cubepath_ddos_catalog_list with catalog='prefix_lists'.
cubepath_ddos_protection_delete
ChatGPTRemoves the mitigation profile of an IP, or of every IP in a subnet, so they go back to the platform's default protection. It cannot be undone: the whole custom configuration (levels, rate limits, SYN flood, filtering modes) is lost and has to be rebuilt field by field. Confirm with the user before calling it; if all they want is to relax the protection, use cubepath_ddos_protection_update. It does not delete the firewall rules nor disable always-on mitigation, which are managed separately. If the IP had no profile it returns a 404. Write the IP or subnet exactly as cubepath_ddos_ip_list returns it: a single IP with no mask ('185.20.30.40') or a subnet in CIDR notation ('185.20.30.0/24'). Only IPs of the organization with Premium protection are valid; those with Basic protection do not show up there and are rejected with 403.
cubepath_ddos_protection_get
ChatGPTReturns everything configured on a protected IP: the mitigation profile (TCP/UDP validation levels, amplification and fragmentation filters, rate limits in packets per second and in Mbps, SYN flood protection, default action, always-on mitigation), the filtered countries and ASNs, the assigned prefix lists and the firewall rules. Use it before touching anything, to know what configuration you are starting from, and when the user asks why traffic is being blocked or let through. If the IP has no saved profile yet, the platform defaults are returned; cubepath_ddos_ip_list tells you through has_profile whether the profile really exists. Write the IP or subnet exactly as cubepath_ddos_ip_list returns it: a single IP with no mask ('185.20.30.40') or a subnet in CIDR notation ('185.20.30.0/24'). Only IPs of the organization with Premium protection are valid; those with Basic protection do not show up there and are rejected with 403.
cubepath_ddos_protection_update
ChatGPTAdjusts the DDoS mitigation profile of a protected IP and, if given, the country, ASN and prefix lists it filters on. Use it when an attack is getting through to the user, when they want to harden or relax the protection of a specific service (game, DNS, RDP, web) or when the mitigation is cutting good traffic and has to be dialed down. Only the fields that are sent get modified: the rest keep the value they already had. Hardening the protection can drop legitimate traffic: raising validation levels, lowering rate limits or setting the default action to DROP cuts real connections, not just the attack. Explain the change to the user and confirm it before applying it. Countries, ASNs and prefix lists are fully REPLACED by what is sent, they are not added to what was there: always send the final list, reading the current one first with cubepath_ddos_protection_get. Filtering by country or by ASN only takes effect if the corresponding mode (country_mode, asn_mode, prefix_list_mode) is also set to 1 or 2. If a subnet is given, the profile is applied to every IP in the block, but the country, ASN and prefix lists are assigned to the exact string given: for a subnet they have to be assigned IP by IP. Write the IP or subnet exactly as cubepath_ddos_ip_list returns it: a single IP with no mask ('185.20.30.40') or a subnet in CIDR notation ('185.20.30.0/24'). Only IPs of the organization with Premium protection are valid; those with Basic protection do not show up there and are rejected with 403.
cubepath_ddos_traffic_query
ChatGPTQueries the traffic the DDoS mitigation has seen on the organization's protected IPs. With mode='stats' it returns how accepted versus dropped traffic evolved over time, with totals and peaks: it is the view that answers 'am I under attack right now?' or 'how much traffic are they throwing at me?'. With mode='packets' it drills down to packet level and tells where the attack comes from: most active source IPs and countries, destination ports, protocols, TCP flags and which mitigation is acting, plus a few sample packets. The data is enormous, so both modes return aggregates and a sample, never the full dump: to see more detail narrow the window or filter by source IP or by port, do not just raise the limit. The time window is required and should be short (minutes or hours, not days). Packet contents are never returned, only their size.
cubepath_dns_health_check_delete
ChatGPTRemoves a record's health check: it stops being probed, it stops being billed and the record is answered again always, healthy target or not. Confirm with the user before calling it if the check was providing failover.
cubepath_dns_health_check_list
ChatGPTReturns the health checks configured on the zone's records and whether their target is healthy right now. A failing check pulls its record's value out of the DNS answers until it recovers, so check this when a domain stops resolving to an IP it should be serving. Pass record_uuid to see only that record's check; if the record has none, the call reports that no health check is configured.
cubepath_dns_health_check_set
ChatGPTCreates or replaces the health check of an A or AAAA record (one per record). While the target is failing, that value is withdrawn from the DNS answers and comes back once it recovers: this is how to get automatic failover between several IPs of the same name. It requires the DNS Pro or Business plan and is billed at $10/month per check, so confirm with the user before creating a new one. Careful: it replaces the whole configuration, so send the fields that are not changing as well.
cubepath_dns_record_create
ChatGPTAdds a record to a zone: point a domain or subdomain at an IP (A/AAAA), at another name (CNAME), set up mail (MX), verifications and SPF/DKIM (TXT), and so on. Use '@' in name for the root domain. If the zone is not verified yet the record is stored but not published until it is. SOA records and the root domain's NS records are managed by the system and get rejected.
cubepath_dns_record_delete
ChatGPTRemoves a record from the zone. The name stops resolving to that value as soon as the TTL expires and it cannot be undone. Confirm with the user and resolve the UUID first with cubepath_dns_record_list, above all when several records share the same name.
cubepath_dns_record_list
ChatGPTReturns the records of a zone: name, type, content, TTL and GeoDNS region. Use it to see what a domain points at, or to resolve a record's UUID before modifying or deleting it. A zone can hold up to 1000 records, more than fit in one response: filter with record_type or name_contains, or paginate with limit/offset.
cubepath_dns_record_update
ChatGPTChanges an existing record. Only the fields you send are touched; the rest stay as they are. Use it to repoint a domain at another IP, lower the TTL before a migration or rename the record (renaming it is the way to 'disable' it without losing it). Resolve the record UUID first with cubepath_dns_record_list. The record type cannot be changed: delete it and create a new one.
cubepath_dns_region_list
ChatGPTReturns the available GeoDNS regions: the code of each one and the part of the world it answers from. Call it when the user wants to serve different answers depending on where the query comes from (a server in Europe for European visitors and another in America for American ones) and you have to pick which region each record is bound to: the code it returns is the one that cubepath_dns_record_create and cubepath_dns_record_update accept in region. The 'global' region answers worldwide and is the default; the rest require the DNS Pro or Business plan.
cubepath_dns_soa_get
ChatGPTReturns the zone's SOA record: serial, refresh/retry/expire intervals, negative TTL (minimum), primary nameserver and hostmaster email. Check it when diagnosing propagation or the caching of negative answers.
cubepath_dns_soa_update
ChatGPTChanges the SOA timers and the hostmaster email. Only the fields you send are applied. Use it to tune how long resolvers cache negative answers (minimum) or the transfer intervals. The serial is bumped automatically; there is no need to touch it. The defaults are right for almost everything: change them only if the user asks.
cubepath_dns_zone_create
ChatGPTRegisters a domain in CubePath's DNS. The zone starts empty and in 'pending_verification' state: until the domain's nameservers point at CubePath's and it gets verified, records are stored but not published. Use it when the user wants to host a domain here. Hosting zones is free. Afterwards, add records and call cubepath_dns_zone_verify.
cubepath_dns_zone_delete
ChatGPTRemoves the domain from CubePath's DNS along with ALL its records. It is irreversible and the domain stops resolving through these nameservers as soon as it propagates. Confirm with the user before calling it. To stop serving a single name do not delete the zone: delete that record with cubepath_dns_record_delete.
cubepath_dns_zone_get
ChatGPTReturns the detail of one DNS zone: status, verification date, the nameservers the domain has to point at, plan and record count. Use it to check whether a domain is already verified and serving, or to read the nameservers that have to be configured at the registrar.
cubepath_dns_zone_list
ChatGPTReturns the organization's DNS zones (domains) with their verification status, assigned nameservers, DNS plan and record count. It is the entry point of any DNS question: every other tool identifies the zone by its UUID, so call this one first to translate a domain name into a UUID. It does not include the records: use cubepath_dns_record_list for that.
cubepath_dns_zone_move_project
ChatGPTMoves the DNS zone to another project of the same organization. It is purely organizational: it does not touch the records nor interrupt resolution of the domain. It does not work if the zone is suspended or being deleted.
cubepath_dns_zone_scan
ChatGPTDiscovers the records the domain publishes TODAY by querying public DNS servers and imports them into the zone. It is the way to migrate a domain from another provider without typing record by record. With zone_uuid it scans a zone already hosted here; without it the zone is created first, and then domain and project_id are required. Use preview (only with zone_uuid) to see what it would find without writing anything. The import only ADDS: it never deletes or overwrites what you already have, and it skips duplicates, the domain's NS records and anything clashing with a CNAME (counted in skipped and explained in errors). The scan only sees what public DNS answers, so it can fall short: review the result with cubepath_dns_record_list before changing the domain's nameservers.
cubepath_dns_zone_verify
ChatGPTAsks to check that the domain's nameservers point at CubePath's. The check is asynchronous: the tool queues the verification and returns immediately. Query cubepath_dns_zone_get afterwards to see whether the zone turned 'active'; do not retry in a loop. If the previous verification failed, it can only be retried once per hour.
cubepath_firewall_group_delete
ChatGPTDeletes a firewall rule group from the organization. It is irreversible: the rules are lost and would have to be written again one by one, so confirm with the user before calling it. It only works if the group is not applied to any server; if it is, the operation is rejected and it has to be removed from each VPS first with cubepath_firewall_vps_set (careful: that leaves those servers without that filtering). If the user only wants to stop applying it for a while, do not delete it: disable it with cubepath_firewall_group_set and enabled = false. Resolve the group_id with cubepath_firewall_group_list.
cubepath_firewall_group_list
ChatGPTReturns the organization's firewall rule groups with their rules and how many servers have them applied. Use it to see which ports are open, or to resolve a group's id before editing it or applying it to a VPS. A group on its own filters nothing: it has to be assigned to a server with cubepath_firewall_vps_set.
cubepath_firewall_group_set
ChatGPTCreates a firewall rule group or changes an existing one. Without group_id it creates, and then project_id, name and rules are required; with group_id it only edits what you send. rules REPLACES the whole list, so read the group first with cubepath_firewall_group_list and send the unchanged rules as well. When editing a group that is already applied, the changes sync themselves to the servers using it. Careful: leaving inbound port 22 out can lock the user out of SSH.
cubepath_firewall_vps_set
ChatGPTDefines which firewall groups filter a VPS's traffic. It REPLACES the whole assignment: send every group that must end up applied, in the order you want them evaluated. An empty list turns the server's firewall off and leaves it open, so confirm it with the user. The groups have to belong to the same project as the VPS. The change is applied in the background; check cubepath_project_list for the server status, do not repeat the call.
cubepath_floating_ip_acquire
ChatGPTReserves a free public IP from the pool for the organization in the given location. IT CREATES A RECURRING COST: the IP is billed monthly from the moment it is acquired, even while it is not assigned to any server, and the charge only stops when it is released with cubepath_floating_ip_release. ALWAYS confirm with the user before calling it. Use it when they need an extra public IP for a VPS or a dedicated server; check cubepath_floating_ip_list first, because they may already have an unassigned one. The platform picks the specific address, you cannot ask for a particular one. Acquiring it does not attach it to any server: that is a separate step. The organization has to be verified, not suspended and with a positive balance, and cannot exceed the IP limit of its plan.
cubepath_floating_ip_list
ChatGPTReturns the organization's public IPs: address, location, which server they are assigned to, whether they are that server's primary IP and their reverse DNS. Use it to know which IPs are free, which one points at which machine, or to resolve the exact address before touching the reverse DNS. Subnets come back aggregated; set include_subnet_ips only if you need every IP inside them, because a subnet can hold hundreds. The antiDDoS configuration does not come here: the DDoS tools cover that.
cubepath_floating_ip_release
ChatGPTReturns a floating IP to the pool: it is unassigned from whichever server held it, its reverse DNS is deleted and it stops being billed. The IP is lost and cannot be recovered (asking for another one yields a different address), so always confirm it with the user. It does not work on a server's primary IP. Only 3 IPs can be released every 24 hours.
cubepath_floating_ip_reverse_dns_set
ChatGPTSets or clears the reverse DNS (PTR record) of a floating IP, which is what a reverse lookup of that address returns. Use it when the user sets up a mail server or needs the IP to identify itself with a specific name. Omit hostname to clear the PTR. The IP has to be assigned to a server. The change propagates in the background.
cubepath_k8s_addon_install
ChatGPTInstalls a marketplace addon (ingress, monitoring, CI/CD, storage, security) on an active cluster. The installation runs in the background through helm and the record is born in state 'pending'. Resolve the slug with cubepath_k8s_catalog (catalog='addons') beforehand. If the addon is already installed the call is refused, unless the previous installation failed: in that case it retries it. Check cubepath_k8s_cluster_get with view='addons' afterwards to see the outcome.
cubepath_k8s_addon_uninstall
ChatGPTUninstalls an addon from the cluster: the helm release is removed and with it the resources it managed, which can take down the traffic or the monitoring that depend on it (an ingress controller, for example). It cannot be undone without reinstalling and reconfiguring. Confirm with the user before calling it. The addon_uuid is the addon.uuid field returned by cubepath_k8s_cluster_get with view='addons', not the UUID of the installation record.
cubepath_k8s_catalog
ChatGPTReturns the catalog of the Kubernetes platform depending on catalog: 'versions' are the available Kubernetes versions with the minimum CPU and RAM each one requires, 'plans' are the VPS plans that qualify as a worker for a version, and 'addons' is the marketplace of installable addons (or the detail of one if you pass addon_slug). Call it BEFORE creating a cluster or a node pool: the version and the plan those tools ask for have to come from here, not be made up. Use it too to translate the name of an addon into its slug before installing it.
cubepath_k8s_cluster_create
ChatGPTDeploys a managed Kubernetes cluster: CubePath operates the control plane and the workers run as billable VPS of the organization. This is an expensive and asynchronous operation: the workers are provisioned in the background and the cluster is born in state 'provisioning'. Confirm the plan, the number of workers and the location with the user before calling it, because it starts billing as soon as the VPS exist. Resolve version and the plan of each pool with cubepath_k8s_catalog beforehand. Afterwards check cubepath_k8s_cluster_get to see when it turns 'active'; do not retry the creation.
cubepath_k8s_cluster_get
ChatGPTReturns information about a specific cluster. view picks what to look at: 'overview' (the default) gives the detail of the cluster with its API endpoint, CIDRs, private network and node pools with their workers; 'node_pools' gives only the pools with their scaling, labels and taints; 'addons' lists the installed addons and the state of each installation; 'load_balancers' lists the balancers pointing at the cluster's workers; 'metrics' gives the health over a time window (ready nodes, pending and failed pods, API latency), or with node_name the series of one worker (Ready, kubelet CPU and memory, and the vps_* usage of its server). The overview also carries the latest health of the API server and of each worker (null when the cluster has not been polled yet). Use it to resolve the UUID of a node pool or the vps_id of a worker before scaling or deleting them, to diagnose a degraded cluster or a NotReady node, and to follow the progress of a queued operation instead of repeating it.
cubepath_k8s_cluster_list
ChatGPTReturns every Kubernetes cluster of the organization with its status, version, location, number of node pools and of workers, and whether it has delete protection enabled. It is the entry point of any Kubernetes query: the other tools identify the cluster by its UUID, so call this one first to translate a name into a UUID. It does not include the detail of the node pools: use cubepath_k8s_cluster_get for that.
cubepath_k8s_cluster_update
ChatGPTChanges the attributes of an existing cluster: name and label rename it, protected turns delete protection on or off, and project_id moves it to another project of the organization along with its network, its availability groups and its workers. It does not touch the infrastructure and does not interrupt service. Turning protected on is the way to shield a production cluster: while it is set, cubepath_k8s_delete refuses to run. Each field is applied separately, so if one fails the previous ones have already been saved. Moving the cluster requires that it has no operations in flight.
cubepath_k8s_delete
ChatGPTDestroys Kubernetes resources irreversibly. target says at which level: 'cluster' deletes the whole cluster, destroys ALL of its workers and removes the control plane, so the workloads disappear; 'node_pool' deletes a pool and its workers (the last pool of a cluster cannot be deleted); 'worker' takes a specific node out of the pool, drains it and destroys it. Always confirm with the user before calling it and resolve the identifiers with cubepath_k8s_cluster_get. A cluster with protection enabled is refused: it has to be removed first with cubepath_k8s_cluster_update.
cubepath_k8s_node_pool_create
ChatGPTAdds a new group of workers to a cluster that is already active. Use it when the user wants nodes with a different plan (more CPU or RAM), or a group kept apart by labels and taints for different workloads. The workers are billable VPS and are provisioned in the background. To add more nodes to a pool that already exists do not create another pool: use cubepath_k8s_node_pool_update. The plan has to come from cubepath_k8s_catalog with catalog='plans'.
cubepath_k8s_node_pool_update
ChatGPTChanges the configuration of an existing node pool. desired_nodes sets the total number of workers: raising it creates the missing ones and lowering it DESTROYS the surplus (newest first), so confirm with the user before reducing it. add_nodes is the incremental alternative: it adds that many workers without setting the total. min_nodes and max_nodes bound the autoscaling, and labels / taints reshape where pods land. Only what you send is applied. Do not send desired_nodes and add_nodes in the same call. The cluster has to be active and have no operations in flight.
cubepath_lb_create
ChatGPTDeploys a new load balancer inside a project. This is billed hourly: check cubepath_lb_plan_list first to pick a valid plan and location, and confirm with the user. The deployment is queued and the tool returns immediately with status 'deploying': follow the progress with cubepath_lb_list, do not repeat the call. The balancer is born empty and balances nothing until you create a listener for it with cubepath_lb_listener and add servers with cubepath_lb_target.
cubepath_lb_delete
ChatGPTDeletes a balancer permanently: its machine is destroyed, its public IPs are released and all of its listeners, health checks and targets disappear. The traffic that went through it stops being served and there is no way back: always confirm with the user, identifying the balancer by name. The servers behind it are left untouched. It fails if the balancer has protection enabled (remove it first with cubepath_lb_update, and only if the user explicitly asks for it), if it is already being deleted or if it has another operation in flight. The identifiers (the balancer UUID and those of its listeners and targets) come from cubepath_lb_list, which returns the full configuration of every balancer: call it first, do not make them up.
cubepath_lb_list
ChatGPTReturns every load balancer in the organization with its full configuration: status, plan, location, public IPs, project, month-to-date cost and, nested, its listeners with their balancing algorithm, their targets (with the health status of each one) and their health check. This is the module's central read tool: call it as the first step of any query or change on a balancer, because there is no individual detail endpoint and every UUID the other tools need (balancer, listener and target) comes from here. The internal balancers of a managed database do not appear: the platform administers those.
cubepath_lb_listener
ChatGPTCreates, modifies or deletes the listeners of a balancer and configures their health check. A listener is the rule that says which port the balancer listens on and which port of the servers behind it the traffic is forwarded to. The action parameter picks the operation: 'create' adds a new listener (it needs name and source_port); 'update' changes the configuration of an existing one, except the listening port and the protocol, which are fixed at creation time; 'delete' removes it along with its targets and its health check, traffic on that port stops being served instantly and it cannot be undone, so confirm it with the user; 'set_health_check' creates or updates the listener's health check with the values in health_check, so servers that fail it stop receiving traffic; 'delete_health_check' removes it and every server is considered healthy again. A new listener is born with no servers behind it: add them afterwards with cubepath_lb_target. The balancer must be in state 'active' or 'stopped': while it is deploying or resizing, changes are rejected. The identifiers (the balancer UUID and those of its listeners and targets) come from cubepath_lb_list, which returns the full configuration of every balancer: call it first, do not make them up.
cubepath_lb_metrics
ChatGPTReturns the performance of a balancer over a time window (active connections, new connections per second, and bytes in and out), summarized to minimum, maximum, average and last value plus a trimmed series, and also the total traffic consumed in the current calendar month. Use it to diagnose whether the balancer is saturated, whether it is worth moving it to a bigger plan, or when the user asks how much traffic they have used. The full series are huge and are never returned raw. A balancer that was just created or is stopped returns empty series and zeros. The identifiers (the balancer UUID and those of its listeners and targets) come from cubepath_lb_list, which returns the full configuration of every balancer: call it first, do not make them up.
cubepath_lb_plan_list
ChatGPTReturns the catalog of load balancer plans grouped by location, with the hourly price, the maximum number of listeners, the maximum number of targets and the connections per second of each one. Use it before creating or resizing a balancer to pick a valid plan_name and to know which locations it exists in, and whenever the user asks about pricing or about how many servers they can put behind it.
cubepath_lb_target
ChatGPTAdds, modifies, removes or drains the servers a listener spreads traffic to. A target is a VPS, a dedicated server or a whole availability group. The action parameter picks the operation: 'add' adds the servers in the targets list, one or several in the same call up to 50, and if any of them is invalid none is added; 'update' changes the port, the weight in the rotation or whether the server is active; 'remove' pulls it out of the listener immediately, cutting off the connections it was serving, and cannot be undone; 'drain' puts it into draining, that is, it stops receiving new requests but keeps serving the ones it already had, which is what to use before retiring or touching a production server. The servers themselves are not touched: removing a target neither powers off nor deletes the machine. The total number of targets is capped by the balancer's plan, and the resources of a managed database cannot be used as a target. The balancer must be in state 'active' or 'stopped': while it is deploying or resizing, changes are rejected. The identifiers (the balancer UUID and those of its listeners and targets) come from cubepath_lb_list, which returns the full configuration of every balancer: call it first, do not make them up.
cubepath_lb_update
ChatGPTApplies configuration changes to an already deployed balancer. It accepts several at once and each field triggers a different operation: name and label rename it, project_id moves it to another project of the same organization (regrouping only, no service interruption), protected turns the delete lock on or off, and plan_name resizes it. Careful with plan_name: it changes the billing and reboots the machine, so confirm it with the user and send it in a separate call, because it leaves an operation in flight that would block the rest of the changes. Changes are applied in order and independently: if one fails, the previous ones have already been saved. The balancer must be in state 'active' or 'stopped': while it is deploying or resizing, changes are rejected. The identifiers (the balancer UUID and those of its listeners and targets) come from cubepath_lb_list, which returns the full configuration of every balancer: call it first, do not make them up.
cubepath_mdb_create
ChatGPTDeploys a managed database (MySQL, PostgreSQL or Valkey) with high availability, automatic failover and a public connection endpoint: CubePath operates the whole infrastructure. It is a billable resource, charged per hour and per node, so confirm the plan and the replica count with the user before calling it. Pick the plan_uuid with cubepath_mdb_plan_list, because each plan is pinned to a location and an engine. The deployment takes several minutes: the tool returns as soon as it is queued and the status is followed with cubepath_mdb_list, not by retrying the creation.
cubepath_mdb_delete
ChatGPTDestroys the instance and ALL of its data, including its logical databases, users and backups. It is irreversible: confirm with the user and make sure they have an export before calling it. It is rejected if the instance has protection enabled (remove it first with cubepath_mdb_update) or if it is still being provisioned.
cubepath_mdb_inspect
ChatGPTDiagnostics for an instance. With view='metrics' it returns connections, CPU, memory and replication lag over a time window, summarized to minimum, maximum, average and last value plus a trimmed series: use it to tell whether the database is saturated or whether it should be scaled. With view='config' it returns the engine's tunable parameters with their default value, their allowed range and whether changing them requires a restart: check it ALWAYS before touching parameters with cubepath_mdb_reconfigure, because the list depends on the engine and anything not in it is rejected.
cubepath_mdb_list
ChatGPTReturns the organization's managed databases (MySQL, PostgreSQL or Valkey) with their engine, version, status, replica count and the connection host and port. Passing md_uuid also returns the detail of that instance (plan, location, backup policy, protection) together with its logical databases and its users. It is the entry point for any DBaaS question: the other tools identify the instance by its UUID, so call this one first to translate a name into a UUID. The admin password cannot be looked up from here: it lives only in the CubePath panel.
cubepath_mdb_object_create
ChatGPTCreates inside an instance either a logical database (object_type='database') or an access account (object_type='user'). This is what to use to give an application access: instead of handing out the admin account, a dedicated user is created. The platform reapplies them after every lifecycle event (failover, restart, scaling). When creating a user, password must be given explicitly: this channel never returns passwords, so one generated by the server would be lost and the user would be unusable. Valkey has no logical databases.
cubepath_mdb_object_delete
ChatGPTDeletes from an instance either a logical database (object_type='database') together with ALL of its data, or an access account (object_type='user'), which will no longer be able to connect. Neither can be undone: confirm with the user and resolve the object's UUID first with cubepath_mdb_list passing md_uuid.
cubepath_mdb_plan_list
ChatGPTReturns the catalog of managed database plans grouped by location, with CPU, memory, disk, maximum replicas and the price per hour AND PER NODE (the monthly cost is hourly_price x replicas x 730). Use it before creating or resizing an instance to pick a valid plan_uuid and to know in which locations it exists, and whenever the user asks about pricing.
cubepath_mdb_reconfigure
ChatGPTChanges the sizing or the engine parameters of an instance. Send EXACTLY ONE of: replicas to scale horizontally (add or remove nodes), plan_uuid to scale vertically to a bigger or smaller plan of the same location and engine, or params to tune the engine configuration (max_connections, timeouts, memory policy...). Check the valid parameters first with cubepath_mdb_inspect view='config': some of them trigger a rolling restart. Raising the replicas or the plan raises the bill, so confirm it with the user. The operation is queued and the instance goes through a transient state: follow the progress with cubepath_mdb_list instead of retrying.
cubepath_mdb_update
ChatGPTChanges the name, the label, the backup policy or the delete protection of an instance. Only what you send is touched. Protection is the switch that prevents destroying it: turn it on for production databases and turn it off only right before a deliberate deletion. It does not change the size or the engine parameters; use cubepath_mdb_reconfigure for that.
cubepath_nat_create
ChatGPTDeploys a NAT gateway on top of a private network so the servers of that network reach the Internet without having a public IP of their own. Use it when the user wants to give egress to isolated machines, or to unify the outbound IP of a group of servers. This is billed hourly and consumes one public IPv4 and one public IPv6: check cubepath_nat_list with include_plans as true first to pick a valid plan_name, and confirm with the user. Only one gateway fits per private network, and the deployment is queued and returns immediately with status 'deploying': follow the progress with cubepath_nat_list, do not repeat the call. The network's default route is created and maintained by the platform; there is no need to add it by hand. The UUID of the gateway comes from cubepath_nat_list, and the identifier of the private network from cubepath_project_list: resolve them before calling, do not make them up.
cubepath_nat_delete
ChatGPTDeletes a NAT gateway permanently: its machine is destroyed, its public IPs are released and the default route that gave the network its egress disappears. The servers of that private network are left WITHOUT Internet access as soon as it finishes, and outbound connections in flight are cut off: always confirm with the user, identifying the gateway by name, and warn them that the public egress IP is not recovered if they create another one afterwards. There is no way back. It fails if the gateway has protection enabled (remove it first with cubepath_nat_update, and only if the user explicitly asks for it), if it is already being deleted or if it has another operation in flight. The UUID of the gateway comes from cubepath_nat_list, and the identifier of the private network from cubepath_project_list: resolve them before calling, do not make them up.
cubepath_nat_list
ChatGPTReturns the NAT gateways of the organization: name, status, plan, location, private network they give egress to, public IPs their servers go out through, project and month-to-date cost. This is the module's central read tool and the only way to resolve the UUID of a gateway from its name: call it before any change. Pass ng_uuid to see a single one in more detail, including its private IP inside the network. Pass include_plans as true to add the plan catalog by location, which is what you need before creating or resizing a gateway and whenever the user asks about pricing or about the bandwidth of each plan. The internal gateways of a managed database do not appear: the platform administers those.
cubepath_nat_metrics
ChatGPTReturns the traffic that has gone through a NAT gateway: the time series of bytes in and out over the requested window, summarized to minimum, maximum, average and last value, and also the total consumed in the current calendar month. Use it when the user asks how much traffic the private network is sending out to the Internet, to spot an odd spike, or to decide whether the gateway is running short on bandwidth. The full series are huge and are never returned raw. A gateway that was just created, is stopped or has no machine assigned yet returns empty series and zeros. The UUID of the gateway comes from cubepath_nat_list, and the identifier of the private network from cubepath_project_list: resolve them before calling, do not make them up.
cubepath_nat_update
ChatGPTApplies configuration changes to an already deployed NAT gateway. It accepts several at once and each field triggers a different operation: name and label rename it, project_id moves it to another project of the same organization (the private network has to be in that project already), protected turns the delete lock on or off, and plan_name resizes it. Careful with plan_name: it changes the billing, reboots the machine and cuts Internet egress for a moment, so confirm it with the user and send it in a separate call, because it leaves an operation in flight that would block the rest of the changes. The private network it gives egress to cannot be changed: for that the gateway has to be deleted and another one created. Changes are applied in order and independently: if one fails, the previous ones have already been saved. The gateway must be in state 'active' or 'stopped' and have no operation in flight: while it is deploying, resizing or being deleted, changes are rejected. The UUID of the gateway comes from cubepath_nat_list, and the identifier of the private network from cubepath_project_list: resolve them before calling, do not make them up.
cubepath_network_bgp_peer_create
ChatGPTOpens a dynamic routing (eBGP) session between the private network's gateway and a server of the user's, so both exchange routes automatically instead of maintaining them by hand. Use it when the user talks about BGP, about announcing prefixes or about connecting an on-premise network over VPN. Maximum 8 sessions per network and only one session per neighbour. The network has to have a server attached already: on an empty network the gateway does not exist yet and the session would never come up. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_bgp_peer_delete
ChatGPTDeletes a BGP session from a private network. The routes learned from that neighbour disappear and the traffic that depended on them stops flowing, so confirm with the user before calling it. If the point is only to bring the session down for a while, cubepath_network_bgp_peer_update with enabled set to false is better, since it keeps the configuration. The peer identifier comes from cubepath_network_bgp_peer_list. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_bgp_peer_list
ChatGPTReturns the dynamic routing (BGP) sessions of a private network, with their remote ASN, the resolved neighbour IP, the prefix limit and the operational state the network reports ('Established', 'Active', 'Idle'), including the learned prefixes. Use it to check whether a BGP session is up or to diagnose why routes are not being learned, and before creating or deleting a peer. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_bgp_peer_update
ChatGPTAdjusts an existing BGP session: its prefix limit, its description or whether it is enabled. Setting enabled to false brings the session down without deleting the configuration, which is what you want to isolate a neighbour that is causing trouble. The remote ASN and the remote end cannot be changed: that means deleting the session and creating another one. The peer identifier is the id field returned by cubepath_network_bgp_peer_list. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_create
ChatGPTCreates an isolated private network inside a project so that the project's servers can talk to each other over private IP. Use it when the user wants to separate internal traffic or build a multi-tier architecture. It needs the project identifier and the location name: get both from cubepath_project_list before calling. Each organization has its own limit on the number of networks (3 by default) and the call fails once it is reached. The network starts empty: attaching servers is a separate step.
cubepath_network_delete
ChatGPTPermanently deletes a private network, along with its static routes and its BGP sessions. It cannot be undone: confirm with the user before calling it. It only works if no server and no active NAT Gateway is still attached, they have to be detached or deleted first. Networks that belong to a Kubernetes cluster or to a managed database are administered by the platform and cannot be deleted here. If the answer mentions a foreign key or integrity constraint failure, there are still already-deleted resources pointing at the network: do not retry, they have to be cleaned up by support. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_move_project
ChatGPTMoves the private network to another project within the same organization. It is only an administrative reorganization: the network keeps its range, its location and its attached servers. Use it when the user wants to regroup resources. Both identifiers, the network's and the destination project's, come from cubepath_project_list. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_route_create
ChatGPTAdds a static route that sends the traffic of a CIDR range to a next hop inside the private network: an IP, a VPS or a dedicated server. Use it when the user wants to push traffic through an appliance, a firewall or their own VPN, or to give Internet egress through a NAT server. Maximum 30 routes per network. The destination cannot be the network's own range, which is already routed, nor a reserved range (loopback, link-local, multicast), and its address family has to match the next hop's. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_route_delete
ChatGPTDeletes a static route from a private network. The traffic that depended on it stops reaching its destination immediately, so confirm with the user before calling it. The route identifier is the id field returned by cubepath_network_route_list: call it first, do not make it up. Routes managed by a NAT Gateway are rejected, those disappear when the gateway itself is deleted. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_route_list
ChatGPTReturns the static routes configured on a private network: for each one, the destination in CIDR, the next hop and the actual IP it resolves to. Use it to diagnose why internal traffic is not reaching where it should, or before creating or deleting a route, to see what is already in place. Routes marked with a NAT Gateway are managed by the platform and cannot be touched by hand. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own.
cubepath_network_update
ChatGPTChanges the name or the descriptive label of a private network. Only that: the IP range, the prefix and the location cannot be modified once the network is created, and changing them means creating another one. The network identifier comes from cubepath_project_list, which returns the networks of each project: no tool lists networks on its own. It does not affect the attached servers nor their addressing.
cubepath_object_storage_bucket_create
ChatGPTCreates an S3 compatible bucket. It is a billable resource: storage, egress and requests are charged by the hour beyond the free allowance, so confirm the tier and the name with the user. Names are global across all CubePath customers (3 to 63 lowercase letters, digits and hyphens). The bucket is pending for 10 to 20 seconds, then active (cubepath_wait_for_status with resource_type object_storage_bucket waits for it). To use it the user needs an access key, which is created from the panel, the API or cubecli, never from here.
cubepath_object_storage_bucket_delete
ChatGPTDeletes a bucket. Without force it only works on an empty bucket; with force EVERY object and version in it is permanently deleted first, which cannot be undone: confirm with the user. It is rejected while the bucket is protected or served by a CDN origin (delete that origin first with cubepath_cdn_origin_delete; the bucket's cdn block in cubepath_object_storage_bucket_get names it).
cubepath_object_storage_bucket_get
ChatGPTFull detail of one bucket: how to connect an S3 client to it (endpoint, region, path-style and virtual-host URLs), this month's storage in GiB-month, egress, CDN traffic and class A/B requests, the month's cost and its CDN connection (zone, domain and status). usage is null when metrics are temporarily unavailable.
cubepath_object_storage_bucket_list
ChatGPTEntry point for any Object Storage question: lists the organization's S3 buckets with tier, endpoint, status, cached size and object count, versioning, protection, CDN connection and the month-to-date cost. Use it to translate a bucket name into the UUID the other tools need.
cubepath_object_storage_bucket_update
ChatGPTTurns versioning on ('enabled') or suspends it ('suspended'; once enabled it cannot go back to 'off'), and enables or disables deletion protection. Only what you send is changed.
cubepath_object_storage_key_delete
ChatGPTRevokes an S3 access key: every application using it loses access within seconds. It cannot be undone (a new key has a new secret), so confirm with the user.
cubepath_object_storage_key_list
ChatGPTLists the organization's S3 access keys: access key id, permission (read_write or read_only), the buckets each one is limited to (null = every bucket of its project in its tier), status and expiry. Secrets are never returned.
cubepath_object_storage_tiers_list
ChatGPTLists the storage tiers buckets can be created in (for now Infrequent Access, on HDD, in Barcelona): location, S3 endpoint and region, prices per GiB-month, per GiB of egress and per 1,000 requests, the monthly free allowance and whether the tier accepts new buckets. Call it before creating a bucket or to answer pricing questions about Object Storage.
cubepath_object_storage_usage_get
ChatGPTA month of Object Storage usage per tier and per bucket: GiB-month stored, egress, CDN traffic, class A and B requests, the cost so far, the free allowance used and the projected cost of the month. Use it for 'how much is my storage costing' questions. Quantities are null when metrics are temporarily unavailable; costs are always returned.
cubepath_project_create
ChatGPTCreates an empty project to group servers and networks under. Use it when the user wants to separate environments or clients. It creates no resource inside: the project starts empty.
cubepath_project_delete
ChatGPTDeletes a project. It only works if it is empty: if it still holds servers or networks, the operation is rejected. Confirm with the user before calling it.
cubepath_project_list
ChatGPTReturns every project of the organization with the resources each one holds: VPS, private networks and dedicated servers, with their status, specs and IPs. Use it as the first step of almost any question about existing infrastructure: it is the only way to get the detail of one specific VPS or network, because there is no individual endpoint for them. Call it before asking for metrics or acting on a server, to resolve its identifier.
cubepath_project_update
ChatGPTChanges the name of an existing project. It does not affect the resources it holds.
cubepath_ssh_key_delete
ChatGPTDeletes a public SSH key from the organization. It cannot be undone and the key stops being available for new servers, so confirm it with the user. A key some server is using cannot be deleted. Deleting it does NOT remove it from the servers where it was already installed: that requires editing the machine's authorized_keys.
cubepath_ssh_key_list
ChatGPTReturns the public SSH keys stored in the organization, with their name, type and fingerprint. These are the ones that can be injected when creating a server, so call it to resolve a key's id before creating a VPS or deleting the key. Only public keys exist here: the private one never leaves the user's machine.
cubepath_ssh_key_set
ChatGPTStores a new public SSH key in the organization, or renames an existing one. Without key_id it creates, and then public_key is required: ask the user for it verbatim (a single line, starting with ssh-ed25519, ssh-rsa or similar) and do not make it up or generate it yourself. With key_id it only changes the name; the key material cannot be replaced. Storing a key sends an email notification to the organization.
cubepath_status_list
ChatGPTReturns the open or past incidents of the CubePath network and the scheduled maintenances, with their severity, the affected location and the published updates. It is the first thing to look at when the user says a server is slow, unresponsive or lost connectivity: before touching anything, check whether there is an incident or a maintenance in their location. The information is platform-wide, not organization-specific.
cubepath_transcoder_job_cancel
ChatGPTCancels a job that has not finished yet and drops the pending work. It cannot be resumed: converting the video again means creating another job from scratch, so confirm it with the user. Jobs that already completed or failed cannot be canceled. Files already written to the user's bucket stay where they are.
cubepath_transcoder_job_create
ChatGPTQueues the conversion of ONE video and leaves the resulting files in the user's bucket. The input is either a public URL (input_url) or an object in their bucket (input_s3): exactly one of the two. outputs describes what to generate (one or several formats at once). The bucket credentials have to be provided by the user; do not make them up or guess them. The conversion takes time: the tool returns as soon as it queues, and the progress is checked with cubepath_transcoder_job_list, not by repeating this call. Pass idempotency_key if you are retrying a submission: with the same key it returns the job that already existed instead of duplicating it.
cubepath_transcoder_job_create_batch
ChatGPTQueues the conversion of SEVERAL videos at once, all with the same outputs and the same destination. Use it when the user wants to process a folder or a whole library instead of a single video. Each element of inputs is a public URL or a key inside the bucket of input_defaults_s3 (so the credentials are given only once). out_subpath hangs that element's output off the common prefix. It returns a batch_id: follow the whole batch with cubepath_transcoder_job_list filtering by it, not by calling here again.
cubepath_transcoder_job_list
ChatGPTReturns the video transcoding jobs with their status, progress and the files already generated. Use it to know whether a video finished converting, how much is left or why it failed. With job_uuid it returns only that job (including the list of output files and the destination they are written to); with batch_id it filters the jobs of a batch submission. The customer's storage credentials are never returned.
cubepath_transcoder_job_outputs
ChatGPTReturns where the files produced by a transcoding job ended up and the destination bucket, without the rest of the job detail. Use it when the user asks 'where are my converted videos'. An empty list does not tell 'still encoding' apart from 'finished without generating anything': look at the job's status with cubepath_transcoder_job_list. CubePath does not generate download links; the files are in the user's own bucket.
cubepath_tunnel_list
ChatGPTReturns the organization's point-to-point network tunnels: the IPs of both ends, the peer IPs, the MTU, whether they carry BGP and the state of each one (Active, Deploying or Deactivated). Use it when the user asks about their site-to-site link or their interconnection with another datacenter, and when diagnosing why no traffic goes through it: a tunnel in 'Deploying' or 'Deactivated' explains the outage without touching anything else. Tunnels are provisioned outside the API, so they can only be read: there is no way to create, change or delete them from here.
cubepath_vps_availability_group_create
ChatGPTCreates an availability group in a project. The servers you put in it are spread across different physical hosts, so that the failure of one host does not take the whole service down. Use it before deploying several servers that have to survive that outage together. The group is tied to a location and only accepts servers in that same location: take a valid location_name from cubepath_vps_plan_list. Creating it costs nothing.
cubepath_vps_availability_group_delete
ChatGPTDeletes an availability group. It does not delete servers, but the spread across hosts it guaranteed stops applying to the ones created afterwards, and the group cannot be recovered. Confirm with the user. It is rejected if the group still has servers inside: take them out first with cubepath_vps_availability_group_member. Groups belonging to a Kubernetes cluster or to a managed database cannot be deleted here.
cubepath_vps_availability_group_list
ChatGPTReturns the availability groups of a project with their placement strategy (spread to keep the servers on different hosts, cluster to keep them together), their location and the servers they contain. Use it when the user asks how their servers are spread out or needs the UUID of a group to create a server inside it.
cubepath_vps_availability_group_member
ChatGPTWith action='add' it puts a server into an availability group; with action='remove' it takes it out. It is a logical grouping change: it does not move the machine to another host and does not interrupt the service, it only affects where the servers created afterwards are placed. Use it to reorganize the spread without recreating anything. The server and the group must be in the same location and the server must not be deploying or updating.
cubepath_vps_availability_group_metrics
ChatGPTReturns CPU usage (average across the servers in the group) and memory usage (sum of all of them) over a time window, summarized to minimum, maximum, average and last value plus a trimmed series. Use it when the user asks how a whole group is doing instead of a single server, or to decide whether more servers need to be added to the group. Only active or stopped servers count; an empty group returns empty series.
cubepath_vps_availability_group_move_project
ChatGPTReassigns an availability group to another project of the same organization. It is only a grouping change: it does not touch the servers in the group and does not interrupt the service. Use cubepath_project_list to get the target project. It is rejected if the group is already in that project, and if it belongs to a Kubernetes cluster or to a managed database.
cubepath_vps_backup_create
ChatGPTStarts an immediate backup of a server. Use it before a risky operation (reinstalling, changing plan, a big upgrade) or when the user asks for it. The backup is queued and takes a while: follow its progress with cubepath_vps_backup_list instead of repeating the call.
cubepath_vps_backup_delete
ChatGPTDeletes a backup permanently and frees its space. There is no way back and that point in time can no longer be restored: always confirm with the user, telling them the date of the backup. Get the backup_id with cubepath_vps_backup_list. A backup in progress cannot be deleted.
cubepath_vps_backup_list
ChatGPTReturns the backups of a server (manual and automatic) with their status, progress, size and date, plus the automatic backup settings. Use it to find out whether there is a recent backup before a destructive operation, or to locate the backup_id that cubepath_vps_backup_restore needs.
cubepath_vps_backup_restore
ChatGPTTakes a server back to the state of a backup. It overwrites ALL the current content of the disk, there is no way back, and the server is powered off during the process. Always confirm with the user, telling them the date of the backup you are about to restore. Get the backup_id with cubepath_vps_backup_list and check that the backup is completed.
cubepath_vps_backup_settings
ChatGPTReads and changes the automatic backup settings of a server: whether they are on, at what time they run, how many days each one is kept and how many are retained. With no change field it only reads; with any of them, it applies that change and keeps the rest of the values as they were. Turning them on has a monthly cost, confirm with the user. Turning them off is rejected while backups remain: they have to be deleted first with cubepath_vps_backup_delete. To read without write permission use cubepath_vps_backup_list, which already returns these same settings.
cubepath_vps_bandwidth_usage
ChatGPTReturns the inbound, outbound and total traffic used by a server in the current calendar month, in bytes, GB and TB. Use it when the user asks how much traffic they have used or whether they are getting close to the amount included in their plan: the included traffic comes from cubepath_vps_plan_list, expressed in TB. A freshly created server returns zeros until the first measurement.
cubepath_vps_change_password
ChatGPTSets a new password for the server's administrator user. The change is applied within a few minutes and the previous password stops working. Use it when the user has lost access or wants to rotate credentials. Do not make the password up: ask the user for it.
cubepath_vps_create
ChatGPTDeploys a new VPS server inside a project. It is a billable operation: check cubepath_vps_plan_list and cubepath_vps_template_list first to pick a valid plan, location and image, and confirm with the user before calling it. The deployment is queued and returns right away: check cubepath_vps_list to follow the status, do not repeat the call. If you disable both ipv4 and ipv6 the server is created without a public IP and needs a private network.
cubepath_vps_destroy
ChatGPTDestroys a server permanently and releases its resources. The data and the backups are lost and there is no way back. Always confirm with the user, identifying the server by name, before calling it. It fails if the server has protection enabled: remove it first with cubepath_vps_protection only if the user explicitly asks for it.
cubepath_vps_iso_attach
ChatGPTMounts an ISO image on the server's virtual drive, to boot from it and install a system by hand or rescue the machine. Get the iso_id with cubepath_vps_iso_list. The server has to be restarted to boot from the ISO, and the ISO has to be unmounted afterwards with cubepath_vps_iso_detach so that the server boots from its disk again.
cubepath_vps_iso_detach
ChatGPTRemoves the ISO mounted on a server so that it boots from its own disk again. Use it when a manual installation or a rescue is finished. The server has to be restarted afterwards.
cubepath_vps_iso_list
ChatGPTReturns the ISO images that can be mounted on a server and which one is mounted right now. Use it to get the iso_id that cubepath_vps_iso_attach needs, or to check whether a server will boot from an ISO instead of from its disk.
cubepath_vps_list
ChatGPTReturns every VPS server in the organization with its status, plan (CPU, RAM, disk), operating system, public IPs, SSH keys, private network, firewall groups and project. This is how to resolve a server identifier from its name: call it before any tool that takes a vps_id. There is no individual detail endpoint, this listing already brings all the information about each server.
cubepath_vps_metrics
ChatGPTReturns the CPU, memory, disk and network usage of a server over a time window, summarized to minimum, maximum, average and last value, plus a trimmed series. Use it to diagnose whether a server is saturated, whether it should move to another plan, or when the user asks about its performance. A freshly created or powered-off server may return empty series.
cubepath_vps_move_project
ChatGPTReassigns a server to another project of the same organization. It is only a grouping change: it does not touch the server or its configuration and there is no service interruption. Use cubepath_project_list to get the target project.
cubepath_vps_network_attach
ChatGPTConnects a server to a private network of the organization and assigns it an internal IP. Use it so that several servers talk to each other without going out to the Internet. The server has to be restarted for the change to take effect: warn the user. A server can only be in one private network at a time. Get the network_id with cubepath_project_list.
cubepath_vps_network_detach
ChatGPTTakes a server out of the private network it is in and releases its internal IP. Any service that depended on that IP will stop working: warn the user. The server has to be restarted for the change to take effect.
cubepath_vps_plan_list
ChatGPTReturns the catalog of VPS plans grouped by location and cluster, with CPU, RAM, disk, included traffic and hourly price. Use it before creating or resizing a server to pick a valid plan_name and to know in which locations it exists, and when the user asks about prices or about which machines they can deploy.
cubepath_vps_power
ChatGPTChanges the power state of a server: start it, stop it or restart it. The order is queued and the change takes a few seconds: check cubepath_vps_list to confirm it instead of repeating the call. Stopping or restarting interrupts the service, warn the user first. It returns a conflict if the server already has another operation in progress.
cubepath_vps_protection
ChatGPTLocks or unlocks a server against destructive operations. With protection on it cannot be destroyed or reinstalled. Use it to shield production servers, or to unlock one when the user has explicitly asked to destroy it.
cubepath_vps_reinstall
ChatGPTWipes the server disk and installs the given image from scratch. All the content is lost and there is no way back. Always confirm with the user and suggest taking a backup first. Use cubepath_vps_template_list to get a valid template_name. It fails if the server has protection enabled.
cubepath_vps_resize
ChatGPTMoves a server to another resource plan, to get more CPU, RAM or disk, or to go down and save money. It changes billing, confirm with the user. The disk cannot be shrunk, so moving to a plan with less storage is rejected. The server restarts during the change. Use cubepath_vps_plan_list to get a valid plan_name in its location.
cubepath_vps_ssh_key_add
ChatGPTAuthorizes one or more SSH keys of the organization on a server that is already deployed. Use it when someone new joins the team or the user changes machine. Get the identifiers with cubepath_ssh_key_list. It fails as a whole if any key does not exist or was already authorized: in that case none of them is added.
cubepath_vps_ssh_key_remove
ChatGPTRemoves the authorization of an SSH key on a server. Anyone who only had that key loses access: confirm with the user which key and which server it is before calling it. The key still exists in the organization, it just stops being authorized on that server. Adding it back requires cubepath_vps_ssh_key_add.
cubepath_vps_template_list
ChatGPTReturns the images available to deploy: operating systems (Debian, Ubuntu, Rocky, Windows...) and preinstalled applications. Use it before creating or reinstalling a server to pick a valid template_name, and when the user asks which systems they can install.
cubepath_vps_update
ChatGPTChanges the name (hostname) or the labels of a server. It is only identification: it does not touch resources, there is no service interruption and the bill does not change. Changing the name queues a task that applies the hostname inside the machine. Use it when the user wants to reorganize or rename their servers. Send label or labels, not both: labels wins.
cubepath_wait_for_status
ChatGPTWait until a resource is no longer in progress and return its final status. Use it after creating, resizing, reinstalling or destroying something, instead of calling the listing tool over and over: the polling happens on the server and you spend a single response. It returns as soon as the resource settles, or when the time runs out. If it times out, the resource keeps working normally: call it again, do NOT re-issue the original operation.
