Windsurf + xCloud
Speed up a slow site with Windsurf on xCloud
Speeding up a slow site with Windsurf means asking the Devin Local agent in your editor why a site is slow, and letting xCloud answer from CPU, RAM and disk samples, cache settings, PageSpeed results and the access log.
- Skill: xcloud:performance
- Toolsets: pagespeed, sites, servers, broken-links
- Free with every xCloud account
YouWhy is shop.example.com slow? Use xCloud.
sites_statusread-only
sites_cacheSettingsread-only
sites_pagespeed_latestread-only
AgentThe site is not mid-deploy. All three cache layers are off and the mobile run shows a slow server response. Turn on page cache under Site, WordPress, Caching; the link is in the panel. I cannot enable it from here.
. 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 Windsurf to Speed up a slow site on xCloud?
Connect Windsurf once; every job on this account uses the same connection. Then ask in plain words.
Add xCloud to the Devin Local agent
New tabs in Devin Desktop use the Devin Local agent, which reads MCP servers from the Devin CLI config files. Run this in a terminal: the URL is treated as Streamable HTTP, and the second command opens the browser for the xCloud sign-in (the agent also prompts on first use). By default the entry lands in .devin/mcp_config.local.json for the current project; add -s user to the first command to share it across projects in ~/.config/devin/mcp_config.json, where the entry reads url plus transport http.
devin mcp add xcloud https://app.xcloud.host/mcp devin mcp login xcloudOr edit the legacy Cascade config
If your tab runs the legacy Cascade agent, click the three-dot menu in the Cascade panel, then the Open MCP config file icon in the MCPs section, and add this under mcpServers. Cascade allows 100 tools in total and the full xCloud server offers 188 operations plus two search tools, so point serverUrl at the compact profile, five tools that reach every operation through search and call; a single toolset such as ?toolsets=sites (60 tools) also fits, but sites and servers together are 121 tools. Windsurf's file has been at ~/.codeium/windsurf/mcp_config.json, and the current documentation lists ~/.config/devin/mcp_config.json on macOS and Linux and %APPDATA%\devin\mcp_config.json on Windows; the icon opens the one your version reads.
{ "mcpServers": { "xcloud": { "serverUrl": "https://app.xcloud.host/mcp?profile=compact" } } }No browser sign-in? Use an API key
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, export it as XCLOUD_TOKEN and add a headers field to the xcloud entry. Both agents fill in the ${env:XCLOUD_TOKEN} reference from your environment, so the token itself stays out of the file. The Devin Local entry is shown; for Cascade the same headers field sits beside serverUrl.
"xcloud": { "url": "https://app.xcloud.host/mcp", "transport": "http", "headers": { "Authorization": "Bearer ${env:XCLOUD_TOKEN}" } }Check it worked
Then ask Windsurf for the job itself, for example:
Why is shop.example.com slow? Use xCloud to read the cache settings, monitoring history and latest PageSpeed result.
In practice
How Does Performance Work from Windsurf?
You are in Windsurf with the site's code open, the agent chat docked beside it, and a slow page you cannot explain from the source alone. That is where this job helps. You type the question, why is shop.example.com slow, and add that the agent should use xCloud. It resolves the site and its server, checks that the site is not mid-deploy, reads the CPU, RAM and disk history, calls sites_cacheSettings, reads the latest PageSpeed run, looks at the access log, checks php-fpm, the web server and Redis, and reads the PHP version. Each call appears in the chat as a tool call, so you can see what was measured before you read the conclusion. These are reads, so xCloud adds no prompt of its own, though Devin Local asks before an MCP tool runs by default. If those prompts get in the way, its permissions allow list takes patterns such as mcp__xcloud__* or mcp__xcloud__sites_status.
The editor adds one thing a chat app does not: the code is right there. xCloud's data names the likely cause, such as an uncached site, a nearly full disk or one client hitting a path, and then you can decide what to do about it in the project you have open. The agent does not guess at application bugs from the measurements. If the numbers are all normal it says so, and it does not pretend the cause is in your theme. When the fix is a dashboard switch, like page cache under Site, WordPress, Caching, the agent names the path and gives the dashboard link, because the API reads cache layers and purges them but cannot enable one.
The connection shapes this job on only one agent. Connect the full URL, https://app.xcloud.host/mcp, with devin mcp add xcloud and devin mcp login xcloud, and Devin Local has what it needs, since no tool cap is documented for it. If your tab runs the legacy Cascade agent, it can use at most 100 tools across all servers, and the full xCloud server offers 188 operations plus two search tools, so connect the compact profile. Narrowing Cascade by toolset does not rescue this job: the diagnosis reads from both sites and servers, which count 60 and 61 operations, so the two together already pass the cap before PageSpeed is added.
Windsurf specific: New Windsurf tabs use the Devin Local agent, and Cognition documents the Cascade MCP page as applying to legacy Cascade only, so if xCloud tools do not appear in a performance chat, check which agent your tab runs first. Devin Local reads ~/.config/devin/mcp_config.json, .devin/mcp_config.json or .devin/mcp_config.local.json, and on versions before 3.6 it reads the main config.json and migrates entries on its own. A Cascade tab opens its file from Open MCP config file in the Cascade panel menu and is held to 100 tools. For Cascade the cause is usually the tool cap, and for either agent it can be the wrong config file, not the xCloud connection.
What xCloud does for performance
xCloud reads the site's and the server's CPU, RAM and disk samples, which cache layers are on, the latest PageSpeed result, traffic in the access log, service health and the site's PHP version. The agent names the cause from that data, then hands you the switches that only the dashboard can flip.
- Resolve the site and its server. The agent looks up the site and the server it runs on, because the answer often comes from both. A slow site is frequently slow because a neighbour on the same server is.
- Check status and monitoring history. A site that is mid-deploy or failed explains slowness without any measurement. Otherwise the agent reads the site's and the server's samples, and a 24-hour or 7-day series to tell whether the slowdown is new. Disk comes early: a nearly full disk slows everything, the database first.
- Read the cache layers. The agent reads the cache settings before saying anything about caching: whether page cache, Redis or Object Cache Pro object cache and Cloudflare edge cache are on, and which server stack the site runs. It never reports that no cache configuration is readable without calling it.
- Read PageSpeed and traffic. The latest completed PageSpeed run is free to read. A new scan is worth starting only when there is no result or the site changed since, and the agent tells you it is spending a scan. The access log shows spikes, a crawl or one client hammering a path.
- Check services and PHP. The agent checks that PHP, the web server, Redis and the database are running, and reads the site's PHP version and pending updates. A stopped Redis next to an object cache that reads as on is a found answer.
- Name the cause and hand off. You get the most likely cause with its numbers. The fix is either something the agent can do, such as a purge after you agree, or a dashboard switch it names with the path and the site's dashboard link. If every number looks normal, it says so instead of inventing a cause.
Reference
Performance Settings and Limits on xCloud
The facts Windsurf works within when it speeds up a slow site. Where a row names the dashboard, that step stays yours to take there.
| Setting or limit | What applies |
|---|---|
| Monitoring history | Site and server CPU, RAM and disk samples as a 24-hour or 7-day series. History is not available on the free plan, and the agent says that is a plan limit rather than reporting no data |
| Cache state | Read through sites.cacheSettings: page cache, object cache (Redis, Object Cache Pro) and Cloudflare edge cache. It returns settings only, never cache contents |
| Enabling a cache layer | Dashboard-only: Site, WordPress, Caching. The API reads the layers and purges them, and cannot switch one on for an existing site |
| Page cache details | Cache duration, URL and cookie exclusions and ignored query parameters are dashboard-only and are not returned by the cache settings read |
| PageSpeed | The latest mobile and desktop results and the history are read for free. One scan runs both strategies |
| Scan conflicts | A 409 while a scan is running means it is still pending or scanning. The agent polls it instead of starting another, and it is not a cooldown |
| Cache purge | Purging runs without a confirmation stop but throws away a warm cache, so the agent asks first on a live site and reports each layer as queued or skipped |
| Traffic | The access log shows spikes and bots. It is read over SSH, so the agent asks for a bounded window |
| PHP version | Read from the site's status. Changing one site's PHP version is a dashboard step: Site, Site Settings |
| Server PHP default | Changing the server default PHP changes only the command-line php and the version new sites get. It does not move any existing site |
| Broken links | A broken-link scan on a WordPress site returns findings grouped by source page, and a truncated scan is reported as partial |
Rules Windsurf has to follow
- The agent diagnoses from measurements, not guesses, and it calls the cache settings read before it says anything about caching.
- It never offers to turn on Redis or any other cache layer itself. Enabling a layer is a dashboard step, and the agent gives you the path and the dashboard link.
- It never presents a change of server PHP default as a substitute for changing one site's PHP version.
- A cache purge on a live site, a new PageSpeed scan and any server-level PHP change are announced first. Server-level changes also need your explicit yes.
- A site that errors rather than loads slowly goes to troubleshooting, and a failed deploy goes to deploy.
Example prompts
What Can You Ask Windsurf to Do for Performance?
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.
Why is shop.example.com slow? Use xCloud to read the cache settings, monitoring history and latest PageSpeed result.Which PHP version does the blog site run, and are there pending updates that could be part of the slowdown?Read the last 200 nginx access log lines for shop.example.com and tell me if one client or path stands out.Why is shop.example.com slow? Check the cache, the server load and the latest PageSpeed result.Is Redis object cache on for the shop site? If it is off, tell me where to switch it on.Show CPU, RAM and disk for the shop site over the last 24 hours and tell me whether the slowdown is new.Run a PageSpeed scan on the shop site and compare the score with the previous scans.Look at the access log of the shop site for a traffic spike or a bot hammering one path.Which PHP version is the blog site running, and are there pending updates I should apply?Purge all caches on the shop site.Scan the shop site for broken links and list the pages with the most.Windsurf and Performance: Frequently Asked Questions
What people ask before they let Windsurf speed up a slow site through xCloud.
Why would Windsurf need the compact profile for a slow-site check?
Only the legacy Cascade agent does. A slow-site check reads from both the sites and servers toolsets, which have 60 and 61 operations, and Cascade can use at most 100 tools across all servers. Point its serverUrl at https://app.xcloud.host/mcp?profile=compact, which exposes five tools, and it still reaches the same operations. Devin Local has no documented tool cap and can take the full URL.
Can Windsurf's agent fix my slow site from the editor?
It can find the likely cause from xCloud's measurements and purge caches after you agree. It cannot switch on a cache layer or change one site's PHP version, which are dashboard steps, so it names the path and links the site's dashboard.
Can the agent turn on caching for my slow site?
No. It can read which cache layers are on and purge them, but switching page cache, Redis object cache or Cloudflare edge cache on for an existing site is a dashboard step under Site, WordPress, Caching. The agent tells you the path and gives you the site's dashboard link.
What does a 409 mean when the agent starts a PageSpeed scan?
It means a scan for that site is still pending or running. The agent polls the existing scan instead of starting another, and it is not a cooldown period. A new scan is only worth starting when there is no recent result or the site has changed.
Will changing the server's PHP default speed up my site?
No. The server default changes only the command-line php and the version new sites get, and it does not move any existing site. The PHP version of one site is changed in the dashboard under Site, Site Settings.
Why does the agent say monitoring history is unavailable?
Monitoring history is a paid-plan feature, so on the free plan the request is refused as a plan limit. The agent reports it that way rather than saying there is no data, and it falls back to the samples and measurements the plan does include.
Does purging the cache ask for my confirmation?
xCloud itself runs a purge without a confirmation stop, because it is a routine action. The agent still asks you first on a live site, since a purge throws away a warm cache and the next visitors wait while it rebuilds.
Other agents
Performance with Other Agents
The same job, the same xCloud tools, a guide for each client.
- Speed up a slow site with Claude CodeAnthropic's terminal coding agent. One claude mcp add command, plus the xCloud skills plugin with nine skills on top.
- Speed up a slow site with ClaudeAnthropic's chat assistant on the web and desktop. Add xCloud as a custom connector, no terminal needed.
- Speed up a slow site with Claude CoworkAnthropic's desktop agent for delegated work. Add the xCloud connector, then hand off hosting jobs.
- Speed up a slow site with CursorThe AI code editor. One mcp.json entry with the compact URL, because Cursor stops at 40 tools.
- Speed up a slow site with CodexOpenAI's coding agent for the terminal. A codex mcp add command or a config.toml entry, then codex mcp login.
- Speed up a slow site with OpenCodeThe open-source terminal coding agent. One remote MCP entry, then opencode mcp auth xcloud.
- Speed up a slow site with Hermes AgentNous Research's agent with memory and a built-in scheduler. An mcp_servers entry in config.yaml and one login.
- Speed up a slow site with OpenClawThe open-source agent runtime with chat apps and automations. ClawHub skill plus the MCP client.
- Speed up a slow site with GitHub CopilotCopilot agent mode in VS Code. One .vscode/mcp.json entry, or the Agent Plugins package.
- Speed up a slow site with Gemini CLIGoogle's terminal agent. One gemini mcp add command, OAuth found automatically.
- Speed up a slow site with ChatGPTOpenAI's chat assistant. A developer-mode app with the xCloud MCP URL and OAuth.
- Speed up a slow site with ChatGPT dotsOpenAI's always-on agent in ChatGPT. Uses the xCloud MCP plugin you add in ChatGPT, with custom rules and scheduled tasks.
- Speed up a slow site with GrokxAI's terminal agent, Grok Build. One grok mcp add command or a config.toml entry.
- Speed up a slow site with Grok BotxAI's always-on Bots on a cloud computer. One Remote HTTPS MCP plugin, OAuth sign-in, routines on a schedule.
- Speed up a slow site with KiroAWS's agentic IDE. One url entry in .kiro/settings/mcp.json, plus the portable xCloud Agent Plugins package.
- Speed up a slow site with AntigravityGoogle's agentic IDE. One serverUrl entry in mcp_config.json and a browser sign-in.
- Speed up a slow site with ZedThe Zed editor's Agent Panel. One context_servers entry in settings.json and a browser sign-in.
More Windsurf guides
- Windsurf and xCloud overview
- Deploy from Git with Windsurf
- Run Docker apps with Windsurf
- Install one-click apps with Windsurf
- Manage WordPress with Windsurf
- Back up and stage sites with Windsurf
- Manage SSL and domains with Windsurf
- Manage servers with Windsurf
- Troubleshoot a broken site with Windsurf
- Secure sites and servers with Windsurf
Run Your Hosting from Windsurf
xCloud MCP, the Agent Skills and the Public API are free with every account. Connect once and ask.