Kiro + xCloud

Speed up a slow site with Kiro on xCloud

Speeding up a slow site with Kiro means asking the agent in AWS's IDE to diagnose a slow site through xCloud, with each measurement read as a tool call you can approve one by one or let through.

  • Skill: xcloud:performance
  • Toolsets: pagespeed, sites, servers, broken-links
  • Free with every xCloud account

YouUse xCloud to find out why shop.example.com is slow.

servers_monitoringHistoryread-only

sites_cacheSettingsread-only

AgentThe server's CPU has been high since the 2nd while the site's own samples are modest, and page cache is off, so uncached requests are saturating php-fpm. Enable page cache under Site, WordPress, Caching, then check the CPU again. Want me to look at the PHP version too?

YouYes.

. 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 Kiro to Speed up a slow site on xCloud?

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

  1. Add xCloud to your Kiro MCP config

    Open the Command Palette (Cmd+Shift+P on Mac, Ctrl+Shift+P on Windows and Linux), search for MCP and choose Kiro: Open workspace MCP config (JSON) for .kiro/settings/mcp.json, or Kiro: Open user MCP config (JSON) for ~/.kiro/settings/mcp.json. Paste this, save, and Kiro reconnects on its own. The first connection opens the xCloud approval screen in your browser, where you tick the teams and choose Read-only or Full access.

    JSON
    {
      "mcpServers": {
        "xcloud": {
          "url": "https://app.xcloud.host/mcp"
        }
      }
    }
  2. Choose which xCloud tools Kiro may run

    Optional. autoApprove lists tools Kiro runs without asking, and disabledTools hides tools from the agent altogether. The two names here are real xCloud tools; swap in your own. Avoid the "*" wildcard in autoApprove, so Kiro's own prompt stays as a second check beside xCloud's confirmation.

    JSON
    {
      "mcpServers": {
        "xcloud": {
          "url": "https://app.xcloud.host/mcp",
          "autoApprove": ["xcloud_docs_search", "xcloud_agent_search"],
          "disabledTools": ["sites_destroy"]
        }
      }
    }
  3. 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_API_TOKEN, and pass it in headers. Kiro only expands environment variables you have approved, so add XCLOUD_API_TOKEN under the Mcp Approved Env Vars setting. Never paste the token into the file or into chat.

    JSON
    {
      "mcpServers": {
        "xcloud": {
          "url": "https://app.xcloud.host/mcp",
          "headers": {
            "Authorization": "Bearer ${XCLOUD_API_TOKEN}"
          }
        }
      }
    }
  4. Check it worked

    Then ask Kiro for the job itself, for example:

    Prompt
    Use xCloud to find out why shop.example.com is slow: server load, cache layers, PageSpeed and traffic.

In practice

How Does Performance Work from Kiro?

You are in the Kiro chat panel with a project open, and the slow site is one you host on xCloud. Kiro's agent plans before it acts, so a request such as use xCloud to find out why shop.example.com is slow, covering server load, cache layers, PageSpeed and traffic, plays out as a short plan and then a series of tool calls. It resolves the site and server, reads the status, the monitoring history, the cache settings through sites_cacheSettings, the latest PageSpeed result, the services and the PHP version, and writes up the cause with its numbers. The cause, not the whole dump, is what you read.

Kiro's mcp.json gives you a control that suits this job. A diagnosis is made of reads, so list the read tools in autoApprove and the agent does not stop at every one: sites_monitoring_history, servers_monitoringHistory, sites_cacheSettings, sites_pagespeed_latest, sites_access-logs, servers_services and sites_wordpress_status. Leave the two with side effects out. sites_pagespeed_scan spends a PageSpeed run and sites_cache_purge-all throws away a warm cache, so they should still ask. Copy the tool names exactly as Kiro lists them in its MCP panel, because a name that does not match is simply not approved.

Put that file at the right level. In .kiro/settings/mcp.json it applies to one workspace, which suits a performance check tied to a single project. In ~/.kiro/settings/mcp.json it applies everywhere, and a workspace entry wins if both exist. The agent still cannot enable page cache or Redis for you, since that is a dashboard step under Site, WordPress, Caching, and it will name the path and the site's link. The portable xCloud Agent Plugins package adds the same performance workflow as a skill if you want the judgement as well as the tools.

Kiro specific: MCP support has to be switched on in Kiro's settings before mcp.json does anything. If you put read tools in autoApprove, keep sites_pagespeed_scan and sites_cache_purge-all out of the list and never use the * wildcard, so Kiro's own prompt stays as a second check before a purge or a scan. A read tool that is not in autoApprove still runs, but Kiro asks each time.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 Kiro works within when it speeds up a slow site. Where a row names the dashboard, that step stays yours to take there.

Setting or limitWhat applies
Monitoring historySite 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 stateRead 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 layerDashboard-only: Site, WordPress, Caching. The API reads the layers and purges them, and cannot switch one on for an existing site
Page cache detailsCache duration, URL and cookie exclusions and ignored query parameters are dashboard-only and are not returned by the cache settings read
PageSpeedThe latest mobile and desktop results and the history are read for free. One scan runs both strategies
Scan conflictsA 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 purgePurging 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
TrafficThe access log shows spikes and bots. It is read over SSH, so the agent asks for a bounded window
PHP versionRead from the site's status. Changing one site's PHP version is a dashboard step: Site, Site Settings
Server PHP defaultChanging the server default PHP changes only the command-line php and the version new sites get. It does not move any existing site
Broken linksA broken-link scan on a WordPress site returns findings grouped by source page, and a truncated scan is reported as partial

Rules Kiro 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 Kiro 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.

Prompt
Use xCloud to find out why shop.example.com is slow: server load, cache layers, PageSpeed and traffic.
Prompt
Read the 7-day CPU, RAM and disk history for the server behind shop.example.com and say when the slowdown began.
Prompt
Check whether the shop site's PHP version is old and list its pending updates. Do not change anything.
Prompt
Why is shop.example.com slow? Check the cache, the server load and the latest PageSpeed result.
Prompt
Is Redis object cache on for the shop site? If it is off, tell me where to switch it on.
Prompt
Show CPU, RAM and disk for the shop site over the last 24 hours and tell me whether the slowdown is new.
Prompt
Run a PageSpeed scan on the shop site and compare the score with the previous scans.
Prompt
Look at the access log of the shop site for a traffic spike or a bot hammering one path.
Prompt
Which PHP version is the blog site running, and are there pending updates I should apply?
Prompt
Purge all caches on the shop site.
Prompt
Scan the shop site for broken links and list the pages with the most.

Kiro and Performance: Frequently Asked Questions

What people ask before they let Kiro speed up a slow site through xCloud.

Which xCloud tools should I put in Kiro's autoApprove for a slow-site check?

Only the reads: the site and server monitoring history, the cache settings, the latest PageSpeed result, the access log, the services and the WordPress status. Leave the PageSpeed scan and the cache purge off the list so Kiro still asks before it spends a scan or empties a cache.

Does Kiro use my workspace config or my user config for xCloud?

Both are read. The workspace file .kiro/settings/mcp.json applies to one project, and ~/.kiro/settings/mcp.json applies to every project. If the same server appears in both, the workspace entry wins.

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.

Run Your Hosting from Kiro

xCloud MCP, the Agent Skills and the Public API are free with every account. Connect once and ask.