Gemini CLI + xCloud

Manage servers with Gemini CLI on xCloud

Managing servers with Gemini CLI means asking Google's terminal agent to check your xCloud servers and change them, with Gemini CLI's own confirmation dialog and xCloud's approval rule both standing between a request and a change.

Skill: xcloud:servers
Toolsets: servers, alerts, user
Free with every xCloud account

Set up Gemini CLI All Gemini CLI guides

YouRestart Redis on the staging server and tell me when the task has finished.

mcp_xcloud_servers_servicesread-only

AgentRedis is running on staging-fra, which hosts 3 sites. A restart briefly interrupts anything that uses the cache. Restart it?

YouYes.

mcp_xcloud_servers_services_restartneeds approval

AgentTask finished. Redis is running again and the three sites answer.

Last updated: October 2026. Keep a human in the loop: xCloud stops and asks before anything that creates, deploys, updates, reboots, deletes or buys.

Setup

How Do You Set Up Gemini CLI to Manage servers on xCloud?

Connect Gemini CLI once; every job on this account uses the same connection. Then ask in plain words.

1
Add the xCloud MCP server
Run this in your terminal, then start gemini. The --scope user flag writes the server to ~/.gemini/settings.json so it is available in every project; without it, gemini mcp add writes to the current project's .gemini/settings.json and refuses to run from your home directory. The first time it calls xCloud it finds the OAuth endpoints, opens your browser on the xCloud approval screen and asks you to tick the teams and choose Read-only or Full access.
Terminal
```
gemini mcp add --scope user --transport http xcloud https://app.xcloud.host/mcp
```
2
Or edit settings.json
Add this to ~/.gemini/settings.json for every project, or to .gemini/settings.json in one project. This is the entry gemini mcp add writes: url plus type set to http. The older httpUrl key still works, but a url without a type is treated as an SSE server and will not connect. If the browser sign-in does not start, type /mcp auth xcloud inside Gemini CLI.
JSON
```
{
  "mcpServers": {
    "xcloud": {
      "url": "https://app.xcloud.host/mcp",
      "type": "http"
    }
  }
}
```
3
No browser? Use an API key
For a headless machine, create a token with the mcp:invoke scope plus the read abilities for the areas it will use (read:servers and read:sites, with read:billing and read:addons for billing and add-on tools) and the matching write: abilities if it should change things in Settings, Developers, API Tokens and send it in the headers field. Keep the token out of version control, and keep the quotes: xCloud tokens contain a pipe character.
JSON
```
{
  "mcpServers": {
    "xcloud": {
      "url": "https://app.xcloud.host/mcp",
      "type": "http",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}
```
✓
Check it worked
Then ask Gemini CLI for the job itself, for example:
Prompt
```
List the cron jobs on the Frankfurt server with their schedules.
```

In practice

How Does Server management Work from Gemini CLI?

Gemini CLI names every xCloud tool with a prefix, mcp_xcloud_ followed by the operation. In practice that means the confirmation dialog tells you plainly what is about to run: mcp_xcloud_servers_reboots_store reads as a reboot before you press anything. That naming is the main thing to know when you manage servers from this client. Ask it to list the cron jobs on the Frankfurt server with their schedules and it calls the servers_cron-jobs operation, prints a short table and stops. Ask it to switch the server's default Node.js to the latest LTS major and it first tells you the default is server-wide, so every Node site on that server moves with it, then asks.

You can narrow what a session is able to do. The xcloud entry in settings.json accepts includeTools and excludeTools, so for a monitoring-only session you can list just the read operations, such as servers_index, servers_show, servers_monitoring and servers_tasks, and leave the reboot, firewall and sudo-user tools out. Check the exact names with /mcp first. A narrow list keeps the dialog quiet and means a casual question can never reach a change. For a maintenance window, widen it again and let each dialog slow you down at the right moments.

A typical maintenance flow is short. Read the state with servers_index and servers_monitoring, install or restart a service with the servers_services operations, and follow the work with servers_tasks until it settles. If the change is a reboot, Gemini CLI calls servers_reboots_store, reads servers_reboots_show and reports a verified new boot rather than a started reboot. If the reading is unconfirmed, it investigates instead of rebooting again. Leave trust off on the xcloud entry, because trust set to true makes Gemini CLI skip its own dialogs, and those dialogs are exactly the pause you want before a service change.

Gemini CLI specific: The browser sign-in redirects to a localhost port, so it needs a browser on the same machine as Gemini CLI. Server work often happens on a remote jump host over ssh, where that redirect cannot complete. In that case use the API-key form with a token that carries the mcp:invoke scope plus the read:servers and write:servers abilities you need in the headers field, keep the quotes because the token contains a pipe, and keep the token out of version control. Remember the xcloud entry is url plus type set to http, the form gemini mcp add writes; a url with no type is treated as an SSE server and will not connect.

What xCloud does for server management

xCloud lets the agent list your servers, read their monitoring, and manage services, Node.js and PHP versions, cron jobs, firewall rules, Fail2Ban and sudo users. Changes that can interrupt a server stop for your approval, and a reboot is only reported as done after xCloud verifies a new boot.

Pick the team and the server. The agent works on one team at a time and uses the server you name. If a name is missing or matches several servers, it lists them and asks. It always restates which server it is about to change before it changes it.
Read the state first. It reads the server's status, installed services, runtimes and monitoring figures. A status such as low disk space or reboot required is worth surfacing on its own. Monitoring history is a paid-plan feature, so a free plan answers 403.
Say what will change, then ask. For a service, runtime, cron, firewall or sudo change, the agent names the server, the item and the impact, for example that a Node.js default affects every Node site on the server. It waits for your approval when the change could interrupt a service.
Follow the task to the end. xCloud accepts server work and returns before it finishes. The agent reads the server's task list until the task settles and reports the real outcome, not the acceptance.
Reboot with proof. A reboot starts a tracked operation. The agent reads that operation until xCloud reports a verified new boot. If the result is unconfirmed it investigates and never repeats the reboot just to check.
Buy a server only after approval. A new server is billable. The agent checks what you already have, reads the plans and the card on file, shows the plan, region and price, and waits for a yes. It sends the purchase once with an idempotency key so a retry cannot buy a second server.

Reference

Server management Settings and Limits on xCloud

The facts Gemini CLI works within when it manages servers. Where a row names the dashboard, that step stays yours to take there.

Setting or limit	What applies
Inventory	Every server on the team with its status, stack and the sites it hosts, plus the tasks, supervisor processes and site snapshots on a server
Monitoring	Current CPU, memory and disk are readable. Monitoring history is a paid-plan feature: xCloud answers 403 on the free plan, which is a plan limit and not a permission
Services	Install, enable, restart and disable. A restart runs without a server-side prompt; the agent still confirms the exact server, service and impact before any service change, because disabling ssh, nginx or a database can lock you out or cause downtime
Node.js versions	Read the installed versions and set the default. The default is server-wide and affects every Node site on the server
PHP versions	Install, uninstall, set the default, patch and toggle OPcache. The server default changes only the command-line php and the version new sites get; it does not change existing sites, and a single site's PHP version is a dashboard setting under Site > Site Settings
Cron jobs	List, create, update, delete, run now and read the last output for server cron jobs. Site cron is a separate resource
Firewall rules	List, create, delete, enable and disable rules with a name, protocol, allow or deny, port and optional source IP
Fail2Ban and IP access	List, ban and unban IP addresses, read the SSH restriction status, and whitelist your current IP or xCloud's own IPs
Sudo users	List, create or update and delete sudo users. A password is a secret and private keys are never returned
Verified reboots	Start a tracked reboot and read its operation; only a verified new boot proves it worked. An unconfirmed reboot can be rechecked without rebooting again
Buying a server	Billable, so it needs an approved plan, region and price, a card on file and an idempotency key. It buys xCloud-managed servers only
Dashboard-only	Resizing or deleting a server, a provider backup of the whole server (Server > Backup), bringing your own server, databases and database users, and PHP settings such as memory limit or upload size

Rules Gemini CLI has to follow

A change that can interrupt a server stops for your approval, and the agent names the server, the service and the impact first.
Buying a server is billable: the agent shows the plan, region and price and waits for your yes, and it never retries a purchase without checking your server list first.
A reboot is only reported as done when xCloud verifies a new boot, and an unconfirmed reboot is investigated, not repeated.
Disabling ssh, nginx, a database or a runtime service needs your explicit confirmation immediately before the call, because it can lock you out or take sites offline.
Resizing or deleting a server, provider server backups, bringing your own server and per-site PHP versions are dashboard steps; the agent gives you the path and the dashboard link xCloud returned.

Example prompts

What Can You Ask Gemini CLI to Do for Server management?

Type these as written and swap in your own repository, site and server names. Reads and routine actions such as backups, cache purges, PageSpeed scans and vulnerability scans run straight away; creating, deploying, updating, rebooting, deleting, buying or starting a broken-link scan stops and asks first.

Prompt

List the cron jobs on the Frankfurt server with their schedules.

Prompt

Restart Redis on the staging server and tell me when the task has finished.

Prompt

Show the status, CPU, memory and disk of every server and flag any above 80% disk.

Prompt

List all my xCloud servers with CPU, RAM and disk usage, and flag any server above 80% disk.

Prompt

Create a server cron job for the WooCommerce Action Scheduler every five minutes. Show me the final command and schedule before creating it.

Prompt

Install Redis on the Frankfurt server and enable the service.

Prompt

Switch the Frankfurt server's default Node.js to the latest LTS major.

Prompt

Reboot the staging server and tell me when it is back.

Prompt

Show me the IP addresses Fail2Ban has banned on the Frankfurt server, and unban 203.0.113.10.

Prompt

Create a new xCloud server on the smallest plan in Singapore. Show me the plan and price first and wait for my approval.

Gemini CLI and Server management: Frequently Asked Questions

What people ask before they let Gemini CLI manage servers through xCloud.

Why do the xCloud tools in Gemini CLI start with mcp_xcloud_?

Gemini CLI names each MCP tool with mcp_ then the server name, then the operation, so tools from different servers never collide. A reboot therefore appears as mcp_xcloud_servers_reboots_store in the confirmation dialog, which makes it easy to see what you are approving.

Can I limit Gemini CLI to read-only server tools?

Yes. Add includeTools to the xcloud entry in settings.json and list only the read operations, or choose Read-only on the xCloud approval screen so changes are refused. Do this when you want a monitoring session that cannot restart a service or reboot a server.

Does the agent ask before it reboots a server?

Yes. A reboot stops for your explicit confirmation, then the agent starts a tracked reboot and reads the operation until xCloud reports a verified new boot. If the result stays unconfirmed it investigates rather than rebooting a second time.

Can an AI agent buy a new server for me?

Yes, but only after you approve it. A new server is billable, so the agent first checks your existing servers, reads the available plans and your card on file, then shows the plan, region and price and waits for your yes. It sends the purchase once, so a retry cannot buy a second server.

If the agent changes the server's PHP default, do my sites change version?

No. The server default changes the command-line php and the version new sites get, and it moves no existing site. Each site keeps its own PHP version, which you change in the dashboard under Site > Site Settings.

Can the agent resize or delete a server?

No. Resizing and deleting a server are dashboard-only, as are a provider backup of the whole server, databases and bringing your own server. The agent can tell you where the control is and give you the server's dashboard link.

Why did the agent say monitoring history is not available?

Monitoring history is a paid-plan feature, so xCloud answers 403 on the free plan. Current CPU, memory and disk readings are still available, and the agent will say that it is a plan limit, not a missing permission.

Other agents