# Stop Clicking Through Your Hosting Dashboard: What You Can Ask xCloud MCP to Do > xCloud MCP lets your AI assistant run your hosting for you. A plain-English tour of what to ask it, from backups to vulnerability fixes, and how to stay safe. Managing websites means a lot of clicking, and xCloud MCP exists to take most of it away. Open the dashboard, find the right server, open the right site, find the tab, change the thing, go back, and do it again for the next site. If you look after a handful of sites it is a chore. If you look after an agency's worth of them it is a job in itself. **xCloud MCP** removes most of that clicking. You connect xCloud to an AI assistant once, and from then on you say what you want in plain English: "back up the staging site", "which of my sites still have plugin updates pending?", "give me a login link for the client's dashboard". The assistant does it through your xCloud account, with the permissions you chose, and tells you what happened. This is a non-technical tour of what that looks like in practice. If you want the setup steps, they are short and live in [How to Connect xCloud MCP to Your AI Agent](/docs/how-to-connect-xcloud-mcp-to-ai-agent/). Here, we are only interested in what you can ask for. ## First, what is MCP? MCP stands for Model Context Protocol. It is an open standard that lets an AI assistant do things, rather than only talk about them. Without it, asking Claude "how do I clear the cache on my WordPress site?" gets you instructions to follow. With xCloud MCP connected, the same question can end with the cache cleared. Under the hood, xCloud exposes the actions of its Public API as "tools" the assistant may call. There are close to two hundred, generated from the same specification the API uses: 188 of the API's 199 operations, plus two search tools that help the assistant find the right one. The eleven left out are deliberate, and none of them are things you would ask for in a chat: the health check, managing your own API tokens, and the sign-in and push-notification plumbing used by the native apps. So most customer-facing operations are there, and the sensitive account-level ones are not. You do not need to know any of that to use it. ## What xCloud MCP can actually do Here are the everyday tasks, grouped the way you would think about them. Every prompt has a copy button in its corner: copy it, paste it into your assistant, and swap in your own site and server names. ### See everything at once The first thing most people notice is that they stop opening the dashboard just to check on things. ```text List all my xCloud servers with CPU, RAM and disk usage, and flag any server above 80% disk. ``` ```text Which of my sites have pending WordPress core, plugin or theme updates? Group them by site. ``` ```text Show the vulnerability count for every site on this team, sorted worst first, and name the top three findings. ``` ```text Are there any open incident alerts right now? Summarise each one in a line. ``` xCloud MCP can read server status, site status, monitoring figures, WordPress health, the [vulnerability rollup](/docs/vulnerability-checker-in-xcloud/) across your whole team and your open alerts. For someone who manages many sites, this alone changes the morning routine. You ask one question instead of opening thirty tabs. ### Create a site or a server, and preview it first ```text Dry-run a new WordPress site called Northwind on my Frankfurt server and show me the resolved configuration without creating anything. ``` ```text Which staging hostname would a site labelled northwind get on the Frankfurt server, and is it still free? ``` ```text That looks right. Create the site, tell me when it is ready, and give me the dashboard link. ``` ```text Create a new xCloud server on the smallest plan in Singapore. Show me the plan and price first and wait for my approval. ``` Site creation and server provisioning are both available, and both are billable, so xCloud makes the assistant work for it: it can run every check as a dry run first, then it has to show you the result, get your go-ahead, and pass an explicit confirmation before anything is created. The dry run is worth using every time. It answers "what would this actually build?" before a single euro is spent. For Git-backed apps (Laravel, Node.js, custom PHP, Lovable) you can also ask for a staging environment. WordPress staging stays a dashboard workflow for now. ```text Create a staging environment for the API site from the feature/checkout branch and give me its URL. ``` These are long-running jobs. xCloud starts the work and hands the assistant a status to poll, so it can tell you when the site is ready while you keep talking. If you close the conversation, the job still finishes on xCloud, but nobody is left to report back. ### Keep WordPress up to date This is the part agencies tend to fall in love with. ```text Update every plugin on the Northwind site, then confirm the homepage still loads. ``` ```text Which of my sites are running an outdated theme? List them, then update the ones I approve. ``` ```text Activate the Yoast SEO plugin on the client's site. ``` ```text Turn on WP_DEBUG for the shop site so I can see the error. Turn it off again when I say I'm done. ``` xCloud MCP can list plugins and themes, summarise pending updates, run the updates, activate items, and toggle debug mode. Combined with the "see everything" tools above, you can say "find every site with a pending security update and update them" and go make coffee. ### Log in without a password ```text Give me a magic login link for the Northwind WordPress admin. ``` xCloud's [magic login](/docs/magic-login-in-xcloud/) generates a short-lived link to the WordPress dashboard, valid for ten minutes. Ask for one and it appears in your chat. No password manager, no reset emails, no asking the client for credentials. Treat that link like a password. Do not paste it into a shared channel, a ticket or a document; whoever opens it is logged in as the admin. ### Check backups ```text When was the last backup of the shop site, did it succeed, and where is it stored? ``` ```text Check the backup settings on every site and list the ones with no schedule. ``` ```text Take a backup of the n8n Docker app now, before I upgrade it, and tell me when it is done. ``` Backup settings, status, counts and history are readable for every site, so "is this site actually being backed up?" is a one-line question. Triggering a backup on demand is currently available for Docker apps; for WordPress and other sites, on-demand backups and every restore still happen in the dashboard. ### Domains, SSL and going live ```text Check the SSL certificate on shop.example.com and tell me when it expires. ``` ```text Is the DNS A record for example.com pointing at my Frankfurt server yet? Tell me if the Cloudflare proxy is on. ``` Certificate status, DNS checks, issuing and renewing certificates are all reachable. Once DNS resolves, "issue SSL for example.com" finishes the job, and "renew the certificate on the shop site" is there for the day it matters. ### Performance and broken links ```text Run a PageSpeed scan on the Northwind homepage and compare the score with the previous scans. ``` ```text Scan the Northwind site for broken links and list the pages with the most broken links. ``` xCloud keeps PageSpeed history per site, so you can ask for a trend rather than a single number. The [broken link checker](/docs/monitor-and-fix-broken-links-in-xcloud/) works the same way: trigger a scan, then ask for the findings. ### Deploy code, and recover when it fails ```text Scan the docker-compose.yml in github.com/acme/api and tell me which services and ports xCloud would use. ``` ```text Deploy the main branch of github.com/acme/api to my Docker server as a Compose app on a staging hostname. ``` ```text Deploy github.com/acme/shop on shop.example.com using my connected Cloudflare zone, create the DNS record, and check that the proxy and SSL are ready. ``` ```text The last deploy of the API site failed. Diagnose it, show me the settings I can correct, fix the build command, and retry on the same site. ``` Git deployments to both regular and Docker servers can be started from chat, with a preview step that reads the repository first. The part developers use most is recovery: a failed deploy gets a deterministic diagnosis, which names the failing step, shows a redacted tail of its output and lists the fields that could fix it. The assistant can then update the deploy configuration and retry on the same site, instead of deleting and recreating it. Non-developers use the next line: "tell me in one sentence whether it is my fault or the server's." ### Server housekeeping ```text List the cron jobs on the Frankfurt server with their schedules. ``` ```text Add a cron job on the shop site that runs the WooCommerce Action Scheduler every five minutes. ``` ```text Install Redis on the Frankfurt server and enable the service. ``` ```text Switch the Frankfurt server's default Node.js to the latest LTS major. ``` ```text Purge all caches on the shop site. ``` ```text Reboot the staging server and tell me when it is back. ``` Cron jobs, services such as Redis and Docker, PHP and Node.js versions, cache purges and reboots are all there. Reboots and service changes are the kind of thing xCloud makes the assistant confirm before doing. The permissions section below covers exactly that. ### Install a one-click app ```text Which one-click apps are compatible with my Frankfurt server? ``` ```text Install n8n on the Frankfurt server, wait until it is ready, then give me the login details. ``` The one-click catalogue, a compatibility check for a given server, the install itself and the credentials afterwards are all available as tools. Same background-job pattern as site creation: the assistant starts it, waits, and reports back. ### Keep an eye on incidents ```text Show me the unread incident alerts for this team. ``` ```text Mark the alerts that are already resolved as read. ``` xCloud's incident alerts are readable and their read state is writable, so the assistant can act as a small inbox for what went wrong overnight. ### Let it find the right tool Two of the tools are searches rather than actions. `xcloud_docs_search` answers questions from the xCloud documentation ("how does the edge cache work?"), and `xcloud_agent_search` finds the right operation and the order to call things in ("how do I take a Git site from repo to live domain?"). You rarely call these yourself. The assistant uses them when it is not sure, which is what keeps a two-hundred-tool server usable from a plain sentence. ### Billing and addons ```text Show me last month's invoice and its total. ``` ```text What plan is my team on and what does it include? ``` ```text Buy a mailbox for example.com, then verify its DNS records and tell me what I still need to add. ``` Billing overviews, invoices, the current plan, and the MailBox and Mail Delivery addons are reachable too. Buying things is the one area where you will want the assistant to ask first. ## The interesting part: chaining tasks Single requests save clicks. Chained requests save afternoons. Because the assistant remembers the conversation, you can describe an outcome and let it work through the steps: ```text Update every plugin on the Northwind site, then run a vulnerability scan, and if the scan comes back clean give me a magic login link so I can check the pages. If it is not clean, stop and tell me what it found. ``` That is four tools, run in order, with the assistant checking each result before moving to the next. The "if it is not clean, stop" part is not a platform feature. It works because you said it and a good assistant follows it, which is a reason to state the condition rather than assume it. Another one agencies use on Monday mornings: ```text For every site on the team: tell me pending updates, vulnerability count and the last backup date. Put it in a table, worst first. ``` Or before a client call: ```text Give me a one-paragraph status of the shop site: uptime, last PageSpeed score, open vulnerabilities, last backup. ``` None of these are special features. They are ordinary tools, combined by the assistant, because you described what you wanted instead of where to click. How well a chain is carried out depends on the assistant you use; xCloud provides the tools and the guard rails, the assistant provides the judgement in between. ## What xCloud MCP is not It helps to be clear about the edges. - **It is not a replacement for the dashboard.** Everything the assistant does shows up in xCloud as if you had done it yourself, and there are things you will still prefer to do by hand, such as reading a long log, restoring a backup or comparing two screens of settings. - **It is not unrestricted server access.** MCP goes through xCloud's supported API and the same team permissions you have in the dashboard. A few account-level operations are excluded on purpose, and some workflows, such as WordPress staging and backup restores, remain dashboard-only today. - **It is not a background automation.** MCP runs while you are talking to your assistant. A long job started from chat finishes on xCloud either way, but nothing reports back after your session ends, and nothing runs on a schedule. For that, use the [xCloud API](/docs/how-to-access-the-xcloud-api/) directly. - **It is not a substitute for judgement.** The assistant will try to do what you ask. "Delete all sites older than a year" is a request it can carry out once you confirm it, which is why the confirmation step matters. ## Permissions: how to stay safe This is the section to read twice. There are two layers, and it helps to know which is which. **What xCloud controls.** When you connect, the browser asks what access to grant. **Read-only** lets the assistant look at servers, sites, billing and account details. **Full access, read and write** also lets it make changes. If you are trying it out, start with read-only; you can reconnect with wider access whenever you like. If your assistant uses an API token instead of the browser sign-in, the token's scopes do the same job. On top of that, every operation that changes or removes something is gated on xCloud's side: the server refuses it unless the assistant passes an explicit confirmation, and the assistant is told to get your approval before it does. Creating a billable site or server, deploying to a live site, rebooting, deleting, buying an addon: all of these stop and ask. Reads never do. The dry-run option on site creation exists for the same reason. You can see what would happen before you approve it. **What your assistant controls.** Most MCP clients add their own rules on top: allow a tool automatically, ask every time, or block it. Claude Desktop and Cursor both have this. Those settings live in the assistant, not in xCloud, so check your client's documentation for where they are. A sensible setup there is to auto-allow reads and ask for everything else. Two more habits worth keeping: - **Know which team you are talking to.** Since xCloud v2.8.8 one connection can be authorized for several teams, and the assistant passes the team on each call. Agencies should say the team name when it matters ("only for the Acme team") and ask the assistant to list its authorized teams if in doubt. - **Treat a pasted token like a password.** Most assistants sign in through the browser, so there is no token to look after. If yours needs a token instead, never put it in a shared document or a repository, and revoke it from your API keys page when you stop using it. ## Connecting it takes two minutes The full guide is [How to Connect xCloud MCP to Your AI Agent](/docs/how-to-connect-xcloud-mcp-to-ai-agent/). The short version: 1. Give your assistant the server address, `https://app.xcloud.host/mcp`. In Claude Code that is one command; in Claude Desktop and Cursor it is a settings field. 2. A browser tab opens. Sign in to xCloud, check which team or teams you are granting, choose read-only or full access, approve. 3. Ask "who am I on xCloud?" to confirm it worked. Then start small. "List my servers" and "which sites need updates?" are good first questions. Move on to changes once you have set the permissions the way you want them. If your assistant has a limit on how many tools it can load, xCloud offers a compact profile with five tools and toolsets that narrow it to one area, both covered in the guide. You lose nothing; the assistant just finds the right tool through a search instead of a long list. ## Frequently asked questions ### Do I need to be a developer to use xCloud MCP? No. You connect it once, in the browser, and then you type requests in plain English inside an AI assistant such as Claude or Cursor. There is nothing to install on your servers and no code to write. ### Can xCloud MCP delete my sites or servers? Only with your say-so. Every operation that changes or removes something is refused by xCloud unless the assistant passes an explicit confirmation, and the assistant is instructed to get your approval first. You can also authorize the connection as read-only, and most assistants let you set per-tool ask or allow rules on their side. ### Does xCloud MCP replace the xCloud dashboard? No. It is another way to run the same platform. Everything the assistant does goes through xCloud's supported API and the same team permissions you have in the dashboard. It does not give unrestricted server access, and a few account-level operations are deliberately excluded. ### Which AI assistants work with xCloud MCP? Claude Code, Claude Desktop, Cursor, and any client that supports the MCP Streamable HTTP transport. Clients that only support local servers can connect through the mcp-remote bridge. ### What do I need to use xCloud MCP? An xCloud account and an AI assistant that supports MCP. The connection is approved in your browser, nothing is installed on your servers, and your assistant may have its own plan. ## Hosting does not need another dashboard The dashboard is not going anywhere, and for some tasks it will always be the better tool. But a lot of hosting work is not really about the dashboard. It is about the outcome: the site backed up, the plugins current, the client logged in, the report on the table. xCloud MCP lets you ask for the outcome. Connect it, set your permissions, and see what you stop clicking on. If you want the assistant to also know how xCloud works, not only what it can call, add the [xCloud AI agent skills](/docs/install-and-use-xcloud-ai-agent-skills/) alongside it.