store/get-store-status reports where the store keeps its data and whether the copies it derives from that data are current.
Run it first when a price, a sale or an order change appears not to have taken effect.
At a glance
| Ability | store/get-store-status |
| Toolset | WooCommerce — toolset/woocommerce |
| Group | WooCommerce › Diagnostics |
| Requires | WooCommerce, active on the site |
| Capability | manage_options |
| Safety | Read-only — changes nothing |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
Order storage comes first: whether orders live in WooCommerce’s dedicated tables or in the posts table, and whether synchronisation between the two is running. A store mid-migration has orders in both, and a tool reading the wrong one sees a different shop.
The product lookup table is the second. SKU search, price sorting and the on-sale query read it rather than the products, so when it disagrees with the catalogue the shop answers those queries with old values while every product page looks correct.
The cached on-sale and featured lists are the third, and they are held for thirty days. A sale that was written outside WooCommerce’s save path can be invisible for a month.
Payment gateways are the fourth thing reported, and only by name and enabled state. Their settings and keys are not readable here, from this ability or any other in the suite.
The common thread is that all four are derived copies. They go stale when something writes the underlying records directly — a migration, an import, a direct database edit — and nothing in WooCommerce reports it.
Input
This ability takes no input.
What comes back
| Name | Type | What it is |
|---|---|---|
woocommerce_version | string | The installed version. |
hpos_enabled | boolean | Whether orders use the dedicated order tables. |
order_sync_enabled | boolean | Whether the two order stores are being kept in step. |
order_placeholder_rows | integer | Leftover placeholder rows from a migration. |
product_lookup | object | How the lookup table compares with the catalogue. |
catalogue_transients | object | The state of the cached on-sale and featured lists. |
payment_gateways | array | Gateway names and whether each is enabled. No settings. |
notes | array | Plain-language findings. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
A sale I set up is not showing on the shop — what is wrong?
It resolves to one call:
{
"ability": "store/get-store-status",
"parameters": {}
}Worth knowing
- The first call when a change appears not to have taken effect.
- A stale lookup table explains SKU search and price-sorting problems.
- The on-sale cache is held for thirty days.
- Gateway settings and keys are never readable here.
Related abilities
- Get Product — the per-product version of the lookup check
- Schedule a Sale — the write path that keeps the cache correct
- Get Store Settings — the configuration side
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category