AI Access

WordPress 7.0 ships the Abilities API, a register of the things a site can do, described well enough that software can pick the right one. MilliCache Pro registers its operations there, so the cache can be inspected and steered from a REST client, a script, or an AI assistant.

Everything on this page is also available from the WP-CLI commands and the command palette. Abilities are a third door to the same rooms, not a separate set of powers.

Two doors, and they are not the same#Copied!

Every ability is reachable over REST at /wp-json/wp-abilities/v1/, guarded by the same capability as the settings screen. Nothing is exposed to a visitor.

A subset is additionally offered to AI assistants over MCP, which needs the MCP Adapter plugin. That subset is deliberately smaller: REST exposure means you can call it, MCP means a model may decide to call it on your behalf. Those are different questions, so they have different answers.

What you can do#Copied!

Ability	What it does	Assistant
cache-status	Cache state, entry count, size	✅
cache-clear	Clear the whole cache, or by URL or flag	✅
cache-entries-list	List cached pages as metadata	✅
cache-entry-get	One page in detail, including why it has several copies	✅
rules-list	Every caching rule in full	✅
rules-schema	The building blocks a rule may use	✅
rules-create	Add a rule, always switched off	✅
rules-update	Change part of a rule	✅
rules-toggle	Switch a rule on or off	✅
rules-delete	Remove a rule that is switched off	✅
preload-status	What the preload queue is doing	✅
preload	Queue the sitemap URLs for preloading	✅
edge-status	Provider, zone, credentials, active state	✅
edge-test	Verify the stored credentials against the provider	✅
edge-purge	Empty the whole zone at your CDN	❌
object-cache-status	Drop-in state and connection	✅
object-cache-flush	Empty the object cache	❌
settings-export	Settings without any secrets	✅
settings-backup	Snapshot the current settings	❌
settings-reset	Back to defaults	❌
settings-restore	Return to the snapshot	❌

cache-status, cache-clear and the settings abilities come from MilliCache and are there without a license. The rest arrive with their module, so an ability exists only while its module is switched on and your license is active.

Why some are closed to assistants#Copied!

The pattern is not "read is safe, write is dangerous". cache-clear is a write and is open, because a cleared cache costs a little server time and rebuilds itself. What stays closed is what a person should be choosing:

• edge-purge and object-cache-flush empty everything at once, on every site of a network, and the cost lands at your CDN or your storage server rather than here.
• settings-reset and settings-restore replace your configuration. settings-backup is closed too, because there is no import ability to pair it with: on its own it would guard against a risk that does not exist over this route.

settings-export never returns your storage password or API keys, whichever route it is called from. Anything an ability returns can end up in a conversation with a third party, so secrets are decided per field, not per caller.

Writing rules safely#Copied!

Caching rules are the one place where an assistant could quietly break a site. A rule that switches caching off matches silently: no error appears, the pages simply stop being cached. Three guarantees hold that in check.

A new rule always arrives switched off. There is no way to ask for anything else, so nothing an assistant adds takes effect until you turn it on. Read what it proposes, then decide.

Only a switched-off rule can be removed. That closes the loop: a rule just added can always be taken back, while one you deliberately turned on cannot vanish without a separate, visible step.

A rule cannot be renamed or switched on through an update. Changing what a rule does and changing whether it runs stay separate acts.

Two more things get refused before anything is stored:

• A condition type nothing answers to. Both is_frontpage (a near miss for is_front_page) and an invented name are rejected, rather than becoming a rule that quietly never matches.
• A placeholder that will never resolve, such as {request.param.utm_source} where {param.utm_source} was meant. An unresolved placeholder stays in the value as literal text, which would put every visitor into the same bucket. See below.

When a change leaves a rule with no conditions at all, the answer says so in a warning, because such a rule applies to every request on the site. That is occasionally what you want, which is why it is a warning and not an error.

Placeholders#Copied!

A rule value can carry a placeholder, written {category.key}, which is filled in per request:

Category	Example
param	{param.utm_source}
cookie	{cookie.geo_country}
header	{header.accept}
request	{request.host}, {request.headers.accept}
post	{post.id}, {post.type}
term, user, query	{term.slug}, {user.roles}, {query.paged}

rules-schema lists them with the keys each one accepts, and a plugin that registers its own category appears there too. Categories such as param and cookie take any key, since you choose the name. Others accept a fixed set, and a key outside it is refused: {post.idd} does not get stored.

Reading why a page has several copies#Copied!

cache-entry-get answers the question the counters cannot. When one URL holds four entries, the cache split it along one of five dimensions, and split_by names the one that actually differs: url (a query string), cookies, unique, buckets, method or https. Each copy then carries a variant object with all its values.

The cached HTML itself is never returned. An entry for a signed-in visitor holds personalised markup, which has no business in a chat transcript.

Note that cache-entries-list counts URLs while cache-status counts stored entries, so the two disagree whenever any page has more than one copy. That is normal.

Multisite#Copied!

Abilities for network-wide settings carry a network- prefix, for example millicache/network-rules-list, and sit alongside their per-site counterparts. Modules owned by the network (Edge Cache, Object Cache) appear only in the network form.

One difference is worth knowing: cache-clear is open to an assistant for a single site but network-cache-clear is not, because clearing every site of a network at once is a decision that should be yours.

Related#Copied!

• WP-CLI Commands: the same operations for scripts and deploys
• Command Palette: the same operations by keyboard
• Rules Builder: writing the same rules by hand
• Cache Entries: the browser behind the entry abilities