store/get-product reads a product in full: its type, its prices and sale window, stock, weight and dimensions, tax and shipping class, categories and tags, images, attributes, variations and the merchandising flags.
It also reports whether the product lookup table still agrees with the product, which is the part no other read gives you.
At a glance
| Ability | store/get-product |
| Toolset | WooCommerce — toolset/woocommerce |
| Group | WooCommerce › Products & Variations |
| 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
WooCommerce keeps a lookup table beside the product. SKU search, price sorting, the on-sale query and several report queries read that table rather than the product itself — so a product can look perfectly correct on its own page while the shop answers every query about it with older values. Writing product meta directly is how that happens.
So the read returns a lookup_state alongside the product. When it disagrees, you have an explanation for the class of bug that is otherwise impossible to reason about: a price that is right on the product page and wrong in the sorted listing, a SKU search that finds nothing, a sale that never shows in the on-sale widget.
A mismatch always means something wrote the product outside WooCommerce — a migration, a direct database edit, an import that bypassed the save path.
The rest is breadth. WooCommerce’s own product query returns a much flatter shape, which is the right choice for listing products and the wrong one when you need to understand a single product completely.
Variations come back with the product, so a variable product does not need a second call to see what it comes in.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
id | integer | Yes | Product or variation ID. |
What comes back
| Name | Type | What it is |
|---|---|---|
product | object | Type, name, SKU, prices and sale window, stock, dimensions, tax and shipping class, terms, images, attributes, variations and merchandising flags. |
lookup_state | object | Whether the product lookup table still agrees with the product after the write. A mismatch means the shop is answering SKU searches, price sorts and on-sale queries with stale values. |
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:
Show me everything about product 812.
It resolves to one call:
{
"ability": "store/get-product",
"parameters": {
"id": 812
}
}Worth knowing
- A
lookup_statemismatch explains price-sorting and SKU-search bugs that nothing else will. - Works on a variation ID as well as a product ID.
- Use WooCommerce’s own product query when you want many products cheaply; use this when you want one product properly.
Related abilities
- Get Stock — which record actually holds the number
- Get Store Status — the site-wide version of the lookup check
- Update Product Details — change what this reads
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category