Manage WooCommerce products

Catalogue changes are the highest-stakes writes MCP offers. A price is public the moment it saves, and a wrong one is a commercial problem rather than a cosmetic one.

Requirements

• WooCommerce active, or the tools are not registered.
• Allow WooCommerce catalog writes open — its own gate.
• woocommerce:catalog:read and woocommerce:catalog:write.
• A user with shop management capability.
• Staging for anything bulk. A backup for anything at all.

The tools

There is no product deletion tool. That is deliberate, and it is a boundary worth knowing: removing a product is a job for the WooCommerce admin.

Always read the product first

Read product 219 and show me its name, price, sale price, stock status and stock quantity.

wc_get_product returns the current state. For a catalogue change this is not just good practice — it is how you get the old values you will need if the change is wrong.

Keep them. There is no undo, and WooCommerce revisions do not cover product meta the way post revisions cover content.

Use the dry run

Both wc_create_product and wc_update_product support dry_run, and the update returns a genuine before-and-after comparison:

Use a dry run to set the price to 24.90 and show me the before and after.

For prices, do this every time. Reading the comparison takes seconds and catches the difference between changing the regular price and changing the sale price, which is easy to conflate and expensive to get wrong.

Bound the change tightly

Update only the regular price of product 219. Do not change the sale price, stock, description, categories or status.

Price, sale price, stock quantity and stock status are four separate fields that all sound like "the price and availability". Name the one you mean and exclude the rest.

Creating products

wc_create_product makes a simple or variable product. For a variable product, the variations are a separate job — see Manage product variations.

Create as a draft where you can, review it in the WooCommerce admin, and publish deliberately. A product created directly as published is live before anyone has looked at it.

Attributes before variations

For a variable product the order matters:

1. wc_get_product_attributes — see what exists globally.
2. wc_create_product_attribute if a genuinely new attribute is needed.
3. wc_set_product_attributes — attach them to the product.
4. Then create variations.

Attributes created carelessly accumulate: "Colour", "Color" and "colour" as three global attributes is a mess that shows up in filters and faceted search. Read the existing ones first and be explicit about whether creating new ones is permitted.

Bulk changes

Count first with wc_get_store_stats or a filtered listing, then pilot:

List the products in the "Outdoor" category with their IDs and current prices, then stop.

Apply the change to the first three only and show me the before and after for each.

Writes are capped at 20 per minute, so a catalogue-wide job is paced regardless. Use that pacing to check.

For a price rise across a range, the pilot is what tells you whether the assistant is applying the rule you meant — a 5% increase on the regular price is not the same as on the current effective price when a sale price exists.

After any catalogue change

1. Read the product back.
2. Open the product page on the storefront.
3. Check the price shown, including whether a sale price is displaying.
4. Check the category and shop listing pages, which cache aggressively.
5. Purge the cache. See Clear the POM Cache.
6. Purge the CDN if you have one.

Prices are exactly the kind of thing a page cache holds and a customer screenshots.

Common problems

Related

• Product tools
• Manage product variations
• Recover from a failed write