How Kiro handles this
You are working in Kiro on a WordPress site, perhaps with a spec for the change open beside the code. When the task is done, you ask the agent in chat to clear the stale cache for it: purge the cache on shop for this change. It calls list_sites to match the name, then purge_cache with a type that fits, and shows each call in the chat.
What comes back is the plugin's report: type, site, entries cleared, and for a purge of type all the object cache and a connected Cloudflare edge. Since the agent has the spec and the diff in front of it, it can say why it chose assets over page. Ask for start_preloader as the last step and it queues the warm-up so the first visitors do not rebuild the pages.
Kiro prompts before it runs an MCP tool unless a rule allows it. Rules live in the server's autoApprove list and in mcp rules in permissions.yaml, such as a match of xspeedhub/get_* with effect allow. That is the main check on a purge, because xSpeed Hub runs a write as soon as the connection allows it. Put your read tools, such as get_cache_status and list_sites, on those lists so they stop prompting while purge_cache keeps asking. For a purge across every site, the Hub also tells Kiro to say that it will touch all the sites and wait for your yes.
Set up Kiro once
Already connected? Skip to the prompts. Alternatives and troubleshooting are on the Kiro guide.
1Put your sites in xSpeed Hub
Sign in at app.xspeedcache.com with Google or email; the Hub is free and has no site cap. Then connect each WordPress site from its own dashboard: click Connect Hub in the xSpeed Cache top bar, then Connect via xSpeed Hub. Each site needs the free xSpeed Cache plugin.
2Add xSpeed Hub to mcp.json
Open the command palette and run Kiro: Open user MCP config (JSON), then add this entry. The user file applies in every workspace. A project can carry its own .kiro/settings/mcp.json instead, but Kiro does not load a workspace's MCP config until you trust that workspace. Kiro reconnects servers when you save the file.
{
"mcpServers": {
"xspeedhub": {
"url": "https://app.xspeedcache.com/xspeed/mcp"
}
}
} 3Approve access in the browser
After you save, Kiro opens the xSpeed Hub authorization page. It registers itself through dynamic client registration, so there is no client ID to create. Sign in to the Hub, approve, and check the MCP servers tab in the Kiro panel for a connected xspeedhub. There is no token to paste; Kiro keeps the credentials it receives.
Full Kiro setup, sign-in options and FAQ
Before you send a prompt that changes something
Reads change nothing on your sites, though contact_support emails xSpeed support. Writes run once your connection allows them, so your client's approval prompt and a read-only connection (the token's Read-only everywhere switch, or a Viewer sign-in) are the gates that matter. Kiro prompts before it runs an MCP tool unless a rule allows it. Rules live in two places: autoApprove in the server's mcp.json entry, which lists tool names, and mcp rules in permissions.yaml, such as a match of xspeedhub/get_* with effect allow. Allow the reads and keep purge_cache, update_settings, toggle_cache and the other write tools off both lists, because the Hub itself runs a write as soon as your connection allows it. Putting "*" in autoApprove skips the prompt for every Hub tool, writes included. In a workspace you have not trusted, Kiro asks before every MCP call even when autoApprove lists the tool.
What do I ask?
Three prompts written for Kiro. More for this job are below.
Based on the spec for this change, pick the right purge type for shop and run it with xSpeed Hub.
Use xSpeed Hub to purge the assets cache on blog and tell me how many files were cleared.
With xSpeed Hub, purge every site in my workspace and list any that failed.
What happens, step by step
A purge throws away stored copies so the next visitor gets a fresh page. Through xSpeed Hub an agent can purge everything, only pages, only CSS and JavaScript assets, the object cache or the REST cache, on one site or across every site in a workspace. A full purge also clears the Cloudflare edge when the site has Cloudflare connected.
01
Find the site
The agent calls list_sites when you have more than one site, then matches the name you used to a site handle. If the name could mean two sites, the Hub tells it to ask you rather than guess.
02
Pick the purge type
purge_cache takes a type: all, page, assets, object or rest. all clears the page cache, the object cache and, when they are connected, the Cloudflare edge and CDN. After a theme or CSS change, assets is enough; after a content edit, page; after a deploy, all.
03
Purge
The call runs straight away on that site once your connection allows writes. For every site at once the agent passes site: "all", and the Hub runs the sites one after another with a one-second pause.
04
Clear only the edge if that is all you need
purge_cloudflare empties the Cloudflare edge cache on its own, without touching the copies on your server. A page or assets purge does not reach Cloudflare; a purge of type all does when Cloudflare is connected.
05
Warm it again
start_preloader rebuilds the cache in the background so the first visitors after the purge are not the ones paying for it.
Reference
| Tool | purge_cache (write) |
|---|---|
| Purge types | all, page, assets, object, rest |
| What all covers | Page cache, object cache, plus the Cloudflare edge and CDN when connected |
| Every site at once | site: "all" or a list of handles, one result per site |
| Fan-out pacing | Sites run one after another with a 1 second pause |
| Edge only | purge_cloudflare, a separate write tool |
| Re-warm | start_preloader after the purge |
| Read-only access | purge_cache is refused on a connection token with Read-only everywhere on, and for a Viewer sign-in |
| Confirmation | None on the Hub; your client's prompt is the gate |
Rules worth keeping
- Name the site. With several sites, an unclear name should make the agent ask, and the Hub tells it to.
- A purge of every site is one call with site: "all". The Hub tells the agent to confirm it with you once before it runs.
- Purge the narrowest type that fixes the problem, then warm the cache, so visitors do not all hit uncached pages at once.
- A fan-out result is reported per site. Treat some sites failing as a partial result, not a failure of the whole call.
Good to know with Kiro
The autoApprove list is per tool, so an entry that names purge_cache removes its prompt. Keep only list_sites and the get_ tools on it, and re-read the list after you copy a config from another project, because an autoApprove carried over from a different setup is an easy way to end up with unprompted writes. Putting an asterisk in autoApprove skips the prompt for every Hub tool, writes included. In a workspace you have not trusted, Kiro asks before every MCP call even when autoApprove lists the tool. A connection token with Read-only everywhere on, or a Viewer sign-in, is the stronger gate if Kiro should only inspect a site, since it refuses every write whatever the list says.
More prompts for this job
They work in any client connected to xSpeed Hub.
Use xSpeed Hub to purge the page cache on blog.
I just changed the theme CSS on shop. Use xSpeed Hub to purge only the assets cache there.
With xSpeed Hub, purge every site in my workspace and tell me which ones failed.
Use xSpeed Hub to purge shop, then purge its Cloudflare edge cache too.
With xSpeed Hub, purge the docs site and start the preloader so it is warm again.
Using xSpeed Hub, what purge type should I use after updating a plugin that changes the checkout page?
Frequently asked questions
Keep going
Purge the cache with other agents
More with Kiro
Documentation
- How to enable Page Cache
- How to warm your cache ahead of visitors
- Managing your fleet with xSpeed Hub
- How to write prompts for xSpeed Hub
- Kiro + xSpeed
- Every AI agent that works with xSpeed
From the blog