How to Connect Grok Bot to xCloud MCP

Grok Bot is xAI’s app for always-on AI teammates: named Bots that work on a persistent cloud computer with a browser, files and a terminal, and keep going while your laptop is closed. Connected to xCloud through the MCP server, a Bot deploys, backs up, updates and diagnoses your servers and sites on request or on a routine, and stops for your approval before it creates, deploys, updates, reboots or deletes anything.

This guide covers the connection only. For what Grok Bot can do once it is connected, with one guide per hosting job, see the Grok Bot and xCloud guide. The xCloud side is free with every account, including the free plan.

What you need

• An xCloud account. If you do not have one yet, sign up for free.
• The Grok Bot desktop app signed in with a Cursor account, on a paid Cursor plan or with a linked SuperGrok subscription.
• A browser for the OAuth sign-in. A Team Bot can carry an API key instead; the steps below show both.

The xCloud MCP server lives at one endpoint, https://app.xcloud.host/mcp, over the MCP Streamable HTTP transport. The same setup also lives in your dashboard under Settings → Developers → MCP.

Step 1: Ask a Bot to add xCloud as a Remote HTTPS MCP server

In the Grok Bot desktop app, open any Bot’s chat and ask it to add a custom MCP server of the Remote HTTPS kind, named xcloud, with this URL. The Bot adds it as a personal plugin from your own chat; the Marketplace in the sidebar only lists catalog connectors. The owner of a Team Bot adds the same kind of server from the Plugins card in the Bot’s Setup panel instead. When the browser opens, sign in with xCloud, tick the teams the Bot may act on and choose Read-only or Full access.

https://app.xcloud.host/mcp

Step 2: Attach it to a task and check it works

In a Bot chat, type @ and pick xcloud to attach the connector to the task, then ask. A plugin you added from your own chat is personal and account-wide, so every Bot on your account can use it; a plugin added from a Team Bot’s Setup panel belongs to that Team Bot, so check it in that Bot’s chat. Put a standing boundary in the description of each Bot that may touch hosting, for example: never change production without approval.

@xcloud Who am I on xCloud, and which servers and sites do I have?

Step 3: Team Bot without sign-ins? Use an API key

A Remote HTTPS server added from the Plugins card in a Team Bot’s Setup panel can run on the Bot’s own credential instead of each person’s sign-in, which suits a Team Bot that answers hosting questions for everyone. 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 give the plugin this header where its form asks for one. Everyone who talks to that Bot then acts with the token’s access, so keep it read-only unless the team should change things.

Authorization: Bearer YOUR_TOKEN

Approve access in your browser

The first time Grok Bot reaches for an xCloud tool, your browser opens on the xCloud authorization screen. Tick the teams the connection may act on and choose Read-only or Full access. With OAuth each person signs in with xCloud once in the browser and approves the teams and the access level; the tokens stay on Cursor’s connector backend and the Bot calls tools without seeing them. A Team Bot can instead carry an xCloud API key with the mcp:invoke scope and the abilities it needs as its own credential.

Every connection is listed with your API keys, so you can revoke it at any time. Read-only is enough for reports and checks; choose Full access when you want the agent to deploy, update or change things. With Full access, routine actions such as a backup, a cache purge or a service restart run without an xCloud prompt, while creating, deploying, updating, rebooting, deleting or buying still waits for your confirmation.

Check it worked

Ask Grok Bot:

@xcloud Who am I on xCloud?

It should answer with your real account name, email and teams, not a guess. If it says it has no xCloud tools, re-check the step above and restart the client.

What Grok Bot can do on xCloud

On the xCloud side, reads run straight away, and anything that creates, deploys, updates, reboots, deletes or buys is previewed first and waits for your confirmation. Grok Bot’s own approval prompts, where it has them, apply on top of that. A few prompts to start with:

@xcloud Every weekday at 8:00 AM, check all my sites for downtime, expiring SSL certificates and pending WordPress updates, and post a short report here. Change nothing.

@xcloud Deploy https://github.com/example/shop to my Frankfurt server on a staging hostname. Show me the dry run and wait for my approval before you create anything.

@xcloud Back up every WordPress site that has pending updates, list what each update would change and wait for my go-ahead.

There is a guide for each hosting job, from deploying a repository to fixing a 502, on the Grok Bot and xCloud guide, and a longer prompt library in What You Can Ask xCloud MCP to Do.

Run hosting checks on a schedule with routines

A routine tells one Bot when to run a workflow, on a schedule or, where supported, after an event. Ask the Bot that should own hosting checks in plain words: when to run, what to check, where to report and what it must not do. The Bot creates the routine and shows its next run. Use Test run before you rely on it, and open Routines under View conversation details to pause it, edit its schedule or read recent runs. Background routines run while your laptop is closed. Keep them to reads, PageSpeed and vulnerability scans and reports, and say so in the routine; start a backup only from a chat you are watching, because a Docker backup stops the app while it captures, and a broken-link scan, like any change, waits for your yes. xCloud refuses to create, deploy, update, reboot or delete without an explicit confirmation, so a routine that finds one of those jobs reports it and waits for you. Routine actions are different: a backup, a cache purge or a service restart runs without an xCloud prompt, and Test run performs real work, so a routine paired with an Always allow rule could carry them out unattended unless you write it to report only.

Every weekday at 8:00 AM, use @xcloud to check every site for downtime, expiring SSL certificates, pending WordPress updates and new vulnerabilities. Post a short report in this conversation. Report only and change nothing. If xCloud is unreachable, say so instead of reusing yesterday's data.

Good to know

• Grok Bot works from a cloud computer in Cursor’s cloud, so its calls to xCloud come from there, not from your laptop. The xCloud MCP URL is public and protected by OAuth, so that works; a server that only answers on a private network would not be reachable. Its traffic leaves through Cursor’s shared static IP ranges; there is no dedicated per-customer egress IP, and an Enterprise team that needs its own source address routes the Bot through a member’s desktop or its own network.
• Personal plugins are account-wide, so a connector you add from your own chat is available to all of your Bots, and your personal Bots all work on one computer in Cursor’s cloud. A plugin on a Team Bot stays with that Team Bot, and a Team Bot’s work runs on the computer of whoever is talking to it: the owner’s in the owner’s chat, each teammate’s in their own chat or 1:1 Slack DM, and one shared computer, separate from everyone’s, for Slack channels, group DMs and threads. Do not use separate Bots as a security boundary: put the boundary in each Bot’s description and add an Ask first Auto-review rule for changes to production. Personal Auto-review rules are desktop-local and do not apply where nobody can answer a card, so for a Team Bot that works in Slack channels have your admin enforce the rule for the team or connect its xCloud plugin Read-only.
• Grok Bot inherits your team’s Cursor connector policy. If the xcloud plugin shows Disabled by team admin, an admin enables it in the Teams Marketplace and, on Enterprise, adds https://app.xcloud.host/mcp to the MCP allowlist. Grok Bot itself needs a paid Cursor plan or a linked SuperGrok subscription.
• Grok Bot is not Grok chat and not Grok Build. The chat assistant on grok.com and the terminal coding agent have their own setups, and the Grok Build guide lives at /agents/grok/. This page is only for Bots in the Grok Bot app.

Frequently asked questions

How do I connect Grok Bot to xCloud?

Ask any Bot in the Grok Bot desktop app to add a custom MCP server of the Remote HTTPS kind, named xcloud, with the URL https://app.xcloud.host/mcp; it becomes a personal plugin from your own chat. The owner of a Team Bot adds it from the Plugins card in the Bot’s Setup panel instead. Sign in with xCloud in the browser, tick your teams and choose Read-only or Full access. Then type @xcloud and ask who am I on xCloud to confirm: in any Bot chat for a personal plugin, or in that Team Bot’s chat for a plugin added from its Setup panel.

Do I need an xCloud API key for Grok Bot?

Not for your own Bots. A Remote HTTPS server that uses OAuth asks you to sign in once, and xCloud supports dynamic client registration, so there is no client ID or token to paste. A Team Bot that should answer for everyone without sign-ins can carry an xCloud API key with the mcp:invoke scope as its own credential instead.

Can Grok Bot run xCloud checks on a schedule?

Yes. Ask the Bot that should own the job to create a routine, for example every weekday at 8:00 AM check my sites and post a report here. Routines run in the background on the Bot’s cloud computer, a Bot can own up to 50 of them, and you manage them under Routines in the conversation details. Keep them to reads and reports and say so in the routine: xCloud stops for confirmation before it creates, deploys, updates, reboots or deletes, but routine actions such as a backup, a cache purge or a service restart run without that step, so an Always allow rule would let a routine carry them out unattended.

Can Grok Bot change my servers without asking?

Not for the operations xCloud gates. Grok Bot shows an approval card for consequential actions and lets you Allow once, Always allow or Deny, and you can add Ask first rules under Auto-review. xCloud refuses to create a site or server, deploy, update plugins, reboot, delete or buy without an explicit confirmation. Reads and routine actions such as a backup, a scan or a service restart run without an xCloud prompt, so for those your Grok Bot rule is the only gate, and an Always allow rule would let them run unattended, as would a Team Bot in a channel where nobody can answer a card, since personal Auto-review rules are desktop-local and only team-enforced rules apply there.

Next steps

• Grok Bot and xCloud: every job guide
• How to connect xCloud MCP to your AI agent for the other clients
• Multi-team API tokens and MCP access

If you run into any issues connecting, feel free to reach out to our support team.