List WooCommerce coupon discounts with AI

Every WooCommerce store ends up with a coupon list nobody trusts. A launch code from two years ago. Three test coupons a developer forgot to remove. Last year’s Black Friday code that technically still works. If you want an AI agent to list your WooCommerce coupon discounts, read them for real detail, and retire the stale ones, here is the actual mechanism, not just a prompt template: reads first, your approval before anything changes, and every write locked behind its own second gate.

Quick answer: how do you list WooCommerce coupon discounts with an AI agent?

Connect the agent as a scoped WordPress user with the WooCommerce coupon abilities turned on, then ask it to list every coupon with its code, discount, expiry, and usage count. That call is read-only. It changes nothing on the store and gets logged like any other call. Deciding what to do with the list, including disabling anything, is a separate step you approve.

Takeaways

• Listing and reading coupons (wc-list-coupons, wc-get-coupon) are read abilities. They report the coupon catalog and change nothing.
• Retiring a coupon means disabling it through wc-update-coupon, not deleting it. The coupon and its usage history stay intact.
• Both coupon-write abilities, create and update, sit among the nine WooCommerce abilities locked behind a separate high-risk switch in Settings, on top of their own per-ability toggle.
• Nothing gets disabled until you approve a specific list. The agent proposes candidates against a rule you set; it does not decide on its own what counts as stale.
• Every call, read or write, lands in the plugin’s Activity Log with the coupon it touched, not the coupon’s own contents.

Why a coupon list turns into a junk drawer

WooCommerce’s own documentation on coupon management covers how to create a coupon and set its expiry date, but says nothing about disabling or cleaning up ones that are already live (WooCommerce, “Managing Coupons in WooCommerce Documentation”). That gap is not an accident. Creating a coupon is a five-minute task with a form. Retiring one means going back through a list nobody has looked at in months, exactly the kind of repetitive lookup an AI agent is good at and a person keeps putting off.

Agent Abilities for MCP is a free WordPress plugin that lets an AI agent do that lookup, and the write that follows it, without treating a coupon list like an admin-equivalent free-for-all. The coupon abilities sit inside its wider WooCommerce integration, gated the same way as the rest of the store. WooCommerce coupons connect to Model Context Protocol (MCP), the open standard that lets AI applications like Claude or ChatGPT call tools on external systems in a structured way instead of guessing at a UI (Model Context Protocol, “What is the Model Context Protocol (MCP)?”). What the agent can actually call is governed underneath that by WordPress’s own Abilities API, which pairs every callable action with a permission check (WordPress Developer Resources, “Abilities API”), the same mechanism that makes this a governed WordPress MCP server rather than a raw bridge to your site.

The four coupon abilities, and what each one actually does

Four abilities cover WooCommerce coupons. Two are reads, two are writes, and the writes carry a second gate the reads do not.

All four require the manage-WooCommerce capability on the connected WordPress user, and all four stay off until an administrator enables them. There is no coupon ability that ships switched on. There is also no wc-delete-coupon ability at all, which is why retiring a coupon means wc-update-coupon, and “disable, do not delete” is the actual mechanism here rather than a caution added for effect.

Step 1: list every coupon before touching anything

The whole first pass is a read. Ask the agent to list every coupon with its code, discount type, amount, expiry, and usage count, and it calls wc-list-coupons, which does exactly that plus a running total. Nothing on the store changes. This is the same category of call as reading a page, logged the same way, and it costs you nothing to run as often as you want.

This is also where you see the drawer for the first time. A store running for a couple of years commonly turns up dozens of codes nobody remembers issuing, sitting next to the two or three that still matter for an active campaign.

Step 2: read the candidates for the detail a list can’t show

The list gives you code, amount, expiry, and usage count, but not product restrictions, spend minimums, or email limits. For anything you are seriously considering retiring, have the agent read it individually with wc-get-coupon, which returns the full coupon shape. That is still a read: it reports the coupon and cannot edit or delete it.

This second pass matters because “expired” and “unused” are not the only signals worth checking. A coupon that looks dead by expiry date might still be referenced in an active email sequence or a product page nobody updated, and that only shows up once you read the coupon in full instead of trusting the summary line.

Step 3: approve a specific list, not a general instruction

Set the rule you want the agent to apply, something concrete like “expired more than 30 days ago, or created over a year ago and never used,” and have it build a table of candidates against that rule with the code, why it qualifies, and its usage count. This step changes nothing either. The agent proposes, you decide, and those stay two separate steps on purpose.

The agent reads first and proposes; you decide what actually gets disabled. Neither wc-list-coupons nor wc-get-coupon can change a coupon, and the update ability will not run until you name the specific codes you approved.

Here is the prompt, drawn directly from the plugin’s own coupon-housekeeping recipe, if you want to paste it as is:

Help me tidy up coupons. Read first, then let me approve before you disable
anything.

List every coupon with its code, discount, expiry, and how many times it has
been used. Then read the ones that look stale by this rule: [expired more than
30 days ago, or created over a year ago and never used]. Build me a table of
the ones you would disable, with the code, why it qualifies, and its usage
count. Do not change anything yet.

I will tell you which ones to disable. Only those. Disable them (do not delete
them) in batches of [10], and show me each batch after you do it. At the end,
list every coupon you disabled so I can double-check.

Approve specific codes, not the whole proposed table by default. A rule like “expired more than 30 days” is a starting filter, not a verdict, and the table exists so you can pull out the one code you recognize as still legitimate before anything is touched.

Step 4: retire coupons behind the high-risk lock

This is where WooCommerce coupon writes differ from most other writes in the plugin. Nine WooCommerce abilities move money or grant authority: refunds, order status changes, order updates, customer updates, payment gateway settings, tax rate creation and updates, and coupon creation and updates. wc-create-coupon and wc-update-coupon are both on that list. Switching on the coupon-write ability by itself is not enough. It stays locked until an administrator also switches on a separate high-risk control in Settings, and flipping that control is itself written to the audit log, same as any other setting change.

That second gate exists because a capability alone does not distinguish a coupon update from a refund from a payment gateway change; all nine sit in the same risk tier. Restricting access to the minimum necessary for a given task is the same idea NIST’s own security glossary defines as least privilege (NIST CSRC, “least privilege”; see also OWASP Foundation, “Least Privilege Principle”). The plugin applies that idea twice here rather than once: the ability toggle answers “is this switched on,” and the high-risk lock answers “is this specific class of write allowed at all.”

With both gates open and a specific approved list in hand, disable in small batches, ten or so at a time, and have the agent show you each batch as it runs rather than the whole set at once. wc-update-coupon changes only the fields you send and returns the full coupon shape after the change, and an empty request body is a no-op success, so a malformed call fails safely instead of touching the wrong field by accident. Disabling stays reversible: the coupon and its usage history stay in place, and you can turn one back on if it turns out you disabled something still in use.

Step 5: check the log instead of your memory

Every call the agent makes, list, get, or update, lands in the plugin’s Activity Log, and denied attempts are logged too. Each entry carries the principal, the ability called, and the argument keys, plus a short note of what it touched by identifier only: ids, codes, statuses, never the coupon’s own free-text content. Since 1.5.0 the log also records governance events, so the moment someone switches the high-risk lock on or off is its own logged row rather than something you have to infer from what changed around it.

After a retirement pass, the log gives you an answer sourced from the store’s own record instead of a chat transcript you have to scroll back through: which coupons were disabled, when, and by which connected user.

Mistakes that turn a cleanup into an incident

• Enabling the coupon-write ability for a run you are not watching. The plugin’s own coupon-housekeeping guidance is direct about this: turn the write ability on only for a supervised run, not as a standing setting.
• Treating “disable” and “delete” as the same instruction. There is no delete-coupon ability, and asking the agent to “get rid of” old coupons is ambiguous in a way that “disable” is not.
• Approving the whole proposed table instead of specific codes. A stale-coupon rule is a filter, not a verdict, and the table is there so you can pull one code out before anything runs.
• Skipping the read pass and acting on the list alone. wc-list-coupons does not surface product restrictions or email limits, and a coupon that looks dead in the summary can still be tied to something active.
• Assuming the ability toggle is the only gate. Coupon writes need both the per-ability toggle and the high-risk lock; a coupon-write ability switched on with the high-risk lock still off simply will not execute the write.

Beyond retiring: the same pattern creates and rewards too

Retiring is one direction this pattern runs in. The other two are creating and rewarding, and both use the same reads-first, approve-then-write shape. Creating and scheduling a coupon turns a plain-language promotion into exact terms, code, discount, expiry, limits, reads them back to you, and only calls wc-create-coupon once you confirm. Rewarding your best customers with targeted coupons pulls customers by spend and the best-selling products first, proposes a coupon plan as a table, and creates the approved coupons in batches; it cannot email anyone, so the codes land in your hands to send yourself.

If you want the exact prompt for the retirement workflow above rather than the one already pasted here, the recipe is coupon housekeeping: find and disable stale coupons. The wider governance model, the same off-by-default posture and audited writes applied to the rest of WooCommerce (orders, customers, products), is covered in running WooCommerce with an agent without handing over the store, and the full mechanics of the high-risk lock and the audit log live on the security page.

FAQ

Does listing coupons change anything on my store? No. wc-list-coupons and wc-get-coupon are both read abilities; they report the coupon catalog and cannot create, edit, or delete a coupon.

Will the agent disable coupons on its own judgment? No. It proposes candidates against the rule you set and builds a table with the code, why it qualifies, and its usage count, then waits for you to approve specific codes before it disables anything.

Does retiring a coupon delete it? No. Retiring means disabling it through wc-update-coupon, which turns the code off while the coupon and its usage history stay in place. There is no delete-coupon ability, and a disabled coupon can be re-enabled later.

Why do coupon writes need a second toggle beyond the ability switch? Coupon creation and updates are two of nine WooCommerce abilities the plugin treats as high-risk because they move money or grant authority. Turning on the ability alone is not enough; a separate high-risk control in Settings has to be switched on too, and that switch is itself logged.

Where does the audit trail live? In the plugin’s own Activity Log, in your WordPress database. Every call, including denied ones, is recorded with the principal, the ability, and the argument keys, plus identifiers only, never the coupon’s free-text content.

The honest bottom line

Listing WooCommerce coupon discounts with an AI agent is a read, and it stays a read all the way through the audit pass. The agent lists, reads the candidates in full, and proposes a table, and none of that touches the store. Retiring the stale ones is the one step that writes, and it is the step with two gates instead of one, the coupon-write ability plus the high-risk lock, both logged, running in the small approved batches you watched go by. That is what “governed” means here in practice: not a warning label, but a specific mechanism that makes the write harder to trigger by accident than the read.