BEAR - WooCommerce Bulk Editor and Products Manager Professional
MCP Server for WooCommerce: AI assistant for your shop
You need to raise prices twenty percent on everything red, but only the products that actually sell, and not the ones already discounted. In the admin that means a filter, a careful look at what it caught, a bulk operation, and a prayer that you didn't select the whole catalogue by mistake.
BEAR now ships an MCP server for WooCommerce. Connect an AI assistant to your shop once and that request becomes a sentence — with a preview before anything is written and a rollback if it wasn't what you meant. This is AI for WooCommerce in the practical sense: the assistant reads and edits products, checks stock and sales, creates orders and coupons — it runs the shop with you, not instead of you.
You don't have to open your site at all.
The MCP server is off until you switch it on. A new install carries no endpoint at all: open Products → BEAR Bulk Editor → Settings, set MCP server to Yes and save. Until then nothing answers at the address, with or without a key.
For extra safety there is MCP two-factor connection. With it on, the key alone is not enough: every assistant session also needs a token that you confirm yourself in the plugin settings, and the session closes on its own after an hour of silence. It is optional, off by default, and whether you use it is your call and your responsibility. How it works is described below.
Your shop managers can have their own connection too. The administrator picks the users, and each of them gets a personal key in their own BEAR settings. An assistant connected with that key works under that person's WordPress account and can do exactly what they can do by hand, nothing more. Two-factor connection is always on for personal keys, and every change they make shows up in History under their name. See MCP access for shop managers below.
Bulk edit, analyse and export — in one conversation
BEAR has always been a WooCommerce bulk editor, and that is still the point. The connection adds its neighbours: reports, export, and the everyday work around a catalogue - creating products, photos, variations, categories, orders and coupons.
Bulk edit WooCommerce products
Filter and change, in the same breath. Raise prices 20% on everything red.Set stock to 50 for the Accessories category.Put the Sale category 30% off from Friday to Sunday.Publish all the drafts with a price.Delete the products that stopped selling last season.
Every one of those is a filter plus a bulk operation, the same two steps you already do by hand. What changes is that you describe them instead of clicking them, and that BEAR checks your work before it writes.
Not everything is a bulk job. Set the Linen Summer Shirt to 45.Give the red medium hoodie 10 more in stock.Change the title of product 812. A single correction is one sentence and one change, and it lands in BEAR's History with its previous value, the same as an edit made by hand in the editor.
The filter is the whole of BEAR's filter, not a shortlist. Any product field, any attribute, any category or tag, custom taxonomies, your own meta fields, price and date ranges, stock status, product type, author — and combinations of them. Everything under 20 euros in Accessories that has no image.Drafts created before June with a price set.Variable products whose variations are out of stock. If you can describe it, it goes into the same filter engine the editor screen uses, so the result is exactly what you would have got by clicking.
Understand what your shop is doing
Questions the editor screen was never meant to answer. What sold best last season?Which month was the worst?Which variation moves fastest — and which one keeps coming back?How many days of stock do I have left at the current rate?Which promo code is eating my margin?
Export WooCommerce products to CSV
A CSV of whatever you just found, with the columns you want in the order you want them. A price list for a wholesale customer, an inventory sheet for the warehouse, a file for WooCommerce's own importer. Export the red products, just SKU, title and price.
Create WooCommerce products
All four types: simple, variable, external and grouped. A variable product comes with its attributes and every variation you ask for, each with its own price and stock. Categories, tags and brands are set in the same step. Make a hoodie in red, blue and green, sizes S to XL, 49 euros, 20 of each.
You see the plan first: the product, its attributes, the full table of variations and how many rows that is. Three colours and four sizes is twelve variations, and the preview says twelve before anything exists. The product is created as a draft, so it isn't in the shop until you publish it, which is one more sentence: Publish it.
Product photos, straight from your computer
A picture pasted into a chat can't reach your shop: the assistant sees an image, not a file. So BEAR gives you a page for it. Ask to add photos and the assistant hands you a link. Open it, drag the files in, and they land in the media library and on the product. The first becomes the main image, the rest go into the gallery. The link works for fifteen minutes and needs no login, so it opens on your phone just as well.
Photos that are already online, on a supplier's page or a CDN, are imported by link. The assistant can also browse your media library, tell you which products already use an image, and set or reorder the main image and gallery.
Here are the photos for the new hoodie.Use the second one as the main image.
Variations of products you already have
Add XL to the hoodie.Drop the green ones.Add a Material attribute, cotton for everything that exists now.Make red medium the default choice.
Before touching a variable product the assistant reads it back as a table: which combinations exist, which are missing, which are duplicated, and which are set to "any" and cover a whole attribute. People rarely remember what actually exists, and that table is where a missing size or two identical variations show up.
Removed variations go to the trash. Changing a price or stock across many variations isn't a structural change at all: it is an ordinary bulk edit with a preview and a rollback.
Categories, tags, brands and attributes
New categories, tags and brands, renamed or removed. New attributes together with their values. Names in any script work: Cyrillic, Chinese, Japanese.
When a product goes into a subcategory, its parent categories are ticked as well, on every way the connection writes. A product filed under Clothing → Men → Shirts shows up in Clothing and in Men too, which is where a customer browsing the shop expects to find it.
Orders, refunds and manual orders
Not only the figures, the orders themselves. A list filtered by status, date or customer. A full order card with the address and every line. Your best customers for a period. A status change for a whole batch at once: Mark everything I shipped today as completed. Private notes on an order.
Refunds, in full or for particular items, with the goods put back into stock if you ask. The preview says exactly which items will go back to stock and which won't, because a product that doesn't track stock has nothing to put back.
Manual orders for phone sales, wholesale or replacements, with a coupon if you want one and in another currency if your shop sells in several.
Coupons
Make a 15% code for newsletter subscribers, valid until Sunday, once per customer. The assistant shows the coupon the way the customer will experience it before creating it: the discount, the days it works, what it applies to. Editing shows what changes, and a trashed coupon can be restored.
Fill a test shop with products
For a development or staging shop: up to five thousand generated products with names, prices, stock, categories and variations, written in portions with a running count. Built for testing a theme, a filter or a migration on a catalogue that looks real, and never for a live shop.
What a WordPress MCP server is, briefly
Model Context Protocol is an open standard for connecting AI assistants to software they don't own. It belongs to no single vendor, and BEAR's implementation is tied to none.
What that means for you: you add one address and one key to your assistant's settings and it can work with your shop. Nothing is installed on their side, nothing is built, and your data doesn't travel through a third party — the assistant talks to your server directly.
Tell it once how you like things
Every shop owner has habits: prices always shown with tax, SKU as the first column, sizes listed from small to large, reports in the shop's currency and never converted. Say it once - From now on, always show the SKU first - and the assistant saves it with your shop. The next conversation, in the same assistant or another one connected with the same key, starts from it without being told again.
These notes describe how you want things shown and done. They never override a preview or a confirmation: an instruction saved last month can't make a bulk edit skip its preview today.
Which AI assistants can connect to WooCommerce
Claude — in the browser, in the desktop app, and in Claude Code
ChatGPT — its custom connectors currently expect a sign-in flow (OAuth) rather than a key in a header, so a direct connection may not be available yet. Some releases offer an API key field; if yours does, the key goes there.
Cursor, Windsurf, Zed and other coding assistants
Your own agent — anything that speaks MCP, including something you wrote yourself
Assistants that can render HTML will draw charts and tables in the conversation. The ones that can't give you the same numbers as text, which is a difference in presentation and nothing else.
How to connect an AI assistant to your WooCommerce shop
Two pieces of information, both on one screen, and one switch before them.
Switch the MCP server on
Open Products → BEAR Bulk Editor → Settings, set MCP server to Yes and save. It is off by default, so a shop that never connects an assistant has no endpoint at all.
Find your MCP key in BEAR
On the same screen, scroll to MCP secret key. A key is generated the first time you look at that page. Underneath it is the address of your shop's endpoint, something like https://yourshop.com/wp-json/woobe/v1/mcp.
This is the shop-wide key, and it belongs to the administrator. Don't hand it to your staff. Give them their own access instead, as described in MCP access for shop managers: then every change is signed with their name and you can cut one person off without touching anyone else.
Add the connector in Claude
In Claude: Settings → Customize -> Connectors → Add. Paste the address. Under Authentication choose None — the wording is unhelpful but the description is right: that option covers servers using an API key rather than a sign-in flow. Then add a request header:
Other clients word it differently but want the same two things: the address, and a header carrying the key.
A 403 error while adding the connector is expected
When you add the connector, Claude may show a 403 error before the header is in place. Don't worry about it: press Skip and carry on with the header as described above.
The 403 is deliberate. Without a valid key, BEAR answers every request with 403 and says nothing about itself, not even that it exists. A client adding a new connector first knocks on the door without a key, looking for a sign-in page, and gets exactly that answer. Earlier versions of BEAR answered that first knock. Current ones don't, so a stranger probing your shop learns nothing. Once the key is in the header, the same address answers normally.
Claude asks before using each tool for the first time
The first time the assistant reaches for a tool, Claude shows a small window asking whether to allow it: once, always, or not at all. It asks per tool, so a new question can appear in the middle of a conversation when the assistant needs something it hasn't used before. This is Claude's own safeguard, not BEAR's.
To stop the questions for tools that only read, and keep them for tools that change things, open Customize → Connectors → BEAR MCP. The tools are grouped into reading and writing, and each group can be set to Always allow, Needs approval or Blocked. A sensible start is reading on Always allow and writing on Needs approval. After an update that adds tools, the new ones start on the default again, so check the list once.
Why the key never goes in the address
Some integrations let you paste a URL with the key inside it. BEAR refuses those. Anything written into a URL ends up in your server's access log, in browser history, in the Referer header when someone follows a link out, and in every proxy along the way. A header appears in none of them.
Lost the key? Clear the field, press Save, and BEAR issues a new one. The old key stops working immediately.
MCP two-factor connection
The key lives in your assistant's settings, and settings leak: a screenshot shared with support, a config file copied between machines, a stolen laptop. Whoever has the key can do what your assistant can do.
MCP two-factor connection closes that gap. Switch it on under MCP two-factor connection in the same settings screen and the key only lets an assistant ask for a connection. To actually work, it needs a token that you confirm yourself:
You start a conversation. The assistant asks the shop for a token and shows it to you.
You paste it into Confirm assistant connection in the BEAR settings and press Confirm connection. For the shop-wide key only a logged-in administrator can do this; a shop manager with a personal key confirms his own token in his own settings.
You tell the assistant it's done, and it works as usual, sending the token with every request.
The connection closes by itself after an hour without a single request, and there is a Disconnect button next to it for when you're finished. Each key has one connection at a time: confirming a new session on the same key ends the previous one, so two agents never work under the same key at once. Personal keys are separate from the shop-wide key and from each other: a manager's session doesn't end yours, and a token confirmed for one key is refused with any other.
A leaked key on its own is then useless. The token can't be confirmed without logging into your admin, and the token of a running session lives only in your own conversation.
For the shop-wide key it is optional and off by default. With it off, every new session starts with one short line reminding you that it exists, and then gets on with what you asked. For personal keys it can't be switched off, see the next section.
MCP access for shop managers
A shop is rarely run by one person. Until now the only way to let a manager use an assistant was to give him your key, and then every change looked like yours and the only way to stop him was to change the key for everyone. Now each person gets his own.
Give a user access
Open Products → BEAR Bulk Editor → Settings as an administrator and find MCP access for users, under the shop-wide key. Start typing part of a name, login or e-mail, pick the people from the list and save the settings. Only users who can manage WooCommerce are offered: anyone else can't open the bulk editor anyway.
The list is empty by default, so on a shop that never uses it nothing changes: only the administrator has MCP.
Next to each person on the list is a status line: not connected, or connected with the time of the last activity, and a Disconnect button that ends that one person's session.
What the user sees
The next time a granted user opens the BEAR settings, a new block appears there: Your MCP access. It holds the address for the assistant, his personal key, a Regenerate key button, the field to confirm a connection and the status of his session. Users who are not on the list see nothing new.
The key looks like woobe_, forty letters and digits, a dash and the user's number, for example woobe_9f3a…c1-57. It is issued automatically and can't be typed in by hand. The number at the end only tells BEAR whose key it is; the key is always checked as a whole, so changing the number doesn't turn it into someone else's key.
The manager adds the connector the same way you did: the address, and a header Authorization with the value Bearer, a space and his personal key.
Two-factor connection is always on for personal keys
It doesn't matter how the shop-wide setting is set: a personal key always needs a confirmed session. The order of work is the same every time:
The manager starts a conversation. The assistant asks the shop for a token and shows it to him.
He pastes it into Confirm assistant connection in his own Your MCP access block and presses Confirm connection. He does this himself, logged into his own account: the administrator never has to relay tokens.
He tells the assistant it's done, and the work begins.
After an hour without a request the session closes and the next conversation starts with a new token. Disconnect ends it at once.
The assistant works as that person, never more
With a personal key every request runs under the user's own WordPress account. The assistant can do exactly what he can do by hand in the bulk editor: the same role, the same field visibility the administrator set for shop managers. A field hidden from shop managers can't be written through the connection either.
Taking access away
Remove the user from the list and save. His key and his session are deleted, and the very next request is refused, even if his assistant is in the middle of a job. A long bulk edit runs in portions, one request each: the portion already being written finishes, the next one is refused, and everything written so far is in History and can be rolled back.
Change his role so he can no longer manage WooCommerce, or delete the account. The key stops working at once, nothing has to be regenerated.
The key may have leaked? The user presses Regenerate key. The old key and the session that was using it stop working immediately; he puts the new key into his assistant.
Closing parts of the shop for a particular user
By default a granted user has the whole connection, within his own WordPress rights. A developer or the owner can narrow that per user with a short snippet in the theme's functions.php or in a small plugin. The shop is divided into sectors, and each sector gets one of three levels: full (read and change), read (look only) or none (closed).
The sectors are:
memory — the standing notes about how you like things done
The * key sets the level for every sector the map doesn't name. The number in the examples is the user's ID: open Users, click the user, and it's the user_id= number in the address bar.
Every sector written out
A starting template. Everything is open here; change the levels you need and delete the lines you don't.
'*' => 'none' turns the map into an allow-list. A content manager who fills in products and their photos, sees categories but can't change them, and nothing else:
A user the snippet doesn't mention keeps everything his role allows.
A closed tool isn't just refused: it disappears from the list the assistant sees, so it doesn't offer what it can't do. It can't be reached in a roundabout way either, through a ready-made question or a call by name.
The map can only narrow. full never gives a user more than his WordPress role allows: someone who can't see WooCommerce reports won't get them through the connection whatever the map says. The service part of the connection (connecting, the list of what the assistant can do, the shop description) can't be closed, otherwise an assistant couldn't even find out what it is allowed.
Who changed what
Every change made through a personal key is recorded in History under that user's name and marked as made through an AI agent, next to his changes made by hand. A shop manager sees only his own history and can roll back only his own changes. The administrator sees everyone's and can roll back anything. More on this in Every change lands in your history.
Examples: managing a WooCommerce shop by chat
These are real exchanges, not marketing copy. The numbers are from a small test shop.
Bulk edit prices: a seasonal price rise
Raise prices 20% on everything red.
The assistant finds seventeen matching items — eleven products and six red variations — and shows what would happen before writing anything. Products at 999 become 1198.80. Five variable parents are skipped automatically, because a parent holds no price of its own and a percentage of an empty field would write a zero, which is a price a customer can buy at.
Schedule a sale with a start and end date
Discount the red products 40% from the 15th to the 30th.
Sale price, start date and end date go on together — dates alone save cleanly and do nothing. The preview warns you when a product already carries a deeper discount, because forty percent off list would raise its sale price rather than lower it. That one catches people out every season.
Find the product variation that gets returned most
What gets returned most often?
Not "shirts return eleven percent of the time", which is true and useless. Per variation: one particular colour comes back sixty percent of the time while its siblings sit at eight. That's a photo problem or a sizing problem, and you now know exactly which product to open.
Know when to reorder: stock against selling rate
What's about to run out?
Stock on hand next to how fast each product actually sells, at three scales. Nobody plans a purchase order around 0.072 units a day; two a month is a sentence you can act on. Products that don't track stock and products that sold nothing are left out, because neither can run out.
Export a WooCommerce price list as CSV
Export the Clothing category — SKU, title and price only.
A CSV with three columns in that order, ready to send. Not the thirteen columns you happen to have visible in the editor.
WooCommerce sales by month
Show me sales by month.
Revenue as columns, a line, or shares, with order counts and average order value beside them. A shop whose best seller by units sits near the bottom by revenue is selling cheap volume — that shows up here rather than from your accountant.
Create a variable product with every variation
Make a linen shirt in white and navy, sizes S to L, 39 euros, 15 of each, in Tshirts.
The preview lists six variations with their prices and stock before anything is created. The product arrives as a draft in Tshirts, and in Clothing above it. Photos follow through the upload link, and Publish it puts it in the shop.
Refund one item and put it back on the shelf
Refund the second shirt from order 1042 and put it back in stock.
The preview names the amount, the item, and whether its stock will move. After you confirm, the refund is recorded on the order and the stock goes up by one. Whether money moved through the payment gateway is said separately, because "refunded" means two different things to a shop owner.
Close a batch of orders
Mark all processing orders from yesterday as completed.
The assistant names the orders and their current status before changing them, and leaves alone any order that is already completed, so no customer gets the same email twice.
Charts in the chat: asking for a picture, not just a number
If your assistant renders HTML — Claude in the browser and the desktop app do — you can describe the chart itself, not only the data behind it. It builds the thing in the conversation, and it stays interactive: you switch views without asking again, because the numbers are already there.
Say what you want to see and how:
Show sales by month as columns, and let me switch to a line.
Refunds over the year as a wave, and a second view with the percentage of revenue.
Top ten products by units and by revenue, side by side — I want to see where the order changes.
Split the shipping methods as shares, with the percentages on the legend.
The stock list as a table with search and paging, sorted by days of cover.
Same chart, but only the last quarter.
Two things are worth knowing before you ask.
The picture is drawn from data the assistant already fetched, so switching between columns, a line and shares costs nothing. Changing the period or the filter is a new question and goes back to your shop for fresh numbers.
Product images don't appear. The sandbox that renders these charts can't load files from your domain, so tables come out as text and columns. It's a limitation of where the drawing happens, not of the connection.
In ChatGPT and other clients that can't render HTML, the same request returns the same figures as a table in text. Nothing is missing except the drawing.
Twelve ready-made questions about your shop
A blank prompt is hard to start from, so BEAR ships twelve prepared ones. Ask your assistant what it can do and it offers the ones that fit whatever you've been discussing.
How the shop is doing — revenue by month with the products carrying it
Show me the numbers — one period from three angles, ready to switch between chart types
What is left in stock — stock against selling rate, sorted by days of cover
When to buy more — the reorder list, soonest first
What sells fastest — units per day, so cheap volume isn't hidden behind one big sale
What is not moving — products that sold nothing, with what's still on the shelf
What sold and what came back — best sellers next to refunds by rate
What comes back — refunds per variation
Where the money is — gross margin per product, worst first
What the discounts cost — every coupon, how often used, how much given away
How people pay and get it — share of orders per shipping method and gateway
Plan a sale with an end date — works out the prices and hands back the change for you to approve
They're a starting point, not a menu. Anything you can describe, the assistant can build.
How BEAR keeps you from breaking your shop
An assistant with write access to a live catalogue is a real risk. The safeguards are structural rather than advisory.
Nothing is written without a preview
Before any bulk change you see the old value and the new one for a sample of products, how many are affected, and what the operation cannot touch. Nothing has been written at that point.
Warnings you couldn't work out from the numbers
Products whose sale price WooCommerce will silently delete because the new regular price fell below it
Variable parents, where writing a price changes nothing a customer sees
Empty fields, where a percentage change computes to zero
Sale dates set without a sale price, which save cleanly and do nothing
Products already discounted more deeply than the sale you're planning
Replacing an attribute's values on a variable product, where the variations built on the old values would stay in the shop but could no longer be chosen
Orders and refunds for goods that don't track stock, where nothing will move on the shelf
Things that are refused rather than warned about
Writing an attribute straight onto a variation, in bulk or one at a time. It would wipe the variation's other attributes, so the assistant is sent to the variation tools instead.
Setting a stock quantity on a product that doesn't track stock. WooCommerce wouldn't store it, and a write that silently does nothing is worse than a clear "switch stock tracking on first".
Fields that are read only in every version, such as the product ID and the author. The assistant says they are changed in wp-admin rather than trying.
A count you have to confirm
A write operation never accepts a filter. It accepts a selection that has already been run, whose exact size you were told, and refuses to proceed unless that number is confirmed. A filter silently widening to the whole catalogue cannot happen.
Every change lands in your history
Every change appears in BEAR's History tab beside the manual edits, bulk and single alike. Each entry says who made it and how: the user's name, and whether it was done by hand or through an AI agent. Changes made with the shop-wide key are marked as the AI agent. One click puts a change back, and history stores the actual previous value of every field, so a rollback restores exactly what was there.
Who sees what:
The administrator sees every entry of every user and can roll back or delete any of them.
A shop manager sees only his own entries, made by hand or through his assistant, and can roll back only those. The same rule applies to his assistant: it can't see or undo anyone else's changes.
The History filter has a Who made the change field, so you can show only one person, and a choice between everything, changes made by hand and changes made through an AI agent.
A change that WooCommerce answers with more than one field is recorded and rolled back as a whole. Switch stock management off, and WooCommerce clears the stock quantity and may change the stock status on its own; the rollback puts back the switch, the quantity and the status together.
Worth knowing: undo a percentage change with the rollback, not with the opposite percentage. Twenty up then twenty down doesn't return you to where you started, because the second percentage is calculated from the new price. Deleting is the one exception to all of this — see below. On the free version only the last two operations of each author are kept — see below.
Bulk delete WooCommerce products
Ask to remove something and you get the same treatment as any other bulk operation, with one difference in how it comes back.
The preview names what would go, how many variations would go with each product, and — separately — which of them have sold in the last three months. That last list is the useful one: a filter that caught more than intended shows itself there, in the shape of a product you recognise, rather than as a number you read past.
Products go to the trash rather than being destroyed, the same as the delete button on the editor screen. Say so and they come straight back, to the status they had before — a published product returns published, not as a draft. You can also list what's in the trash and restore from there later.
Delete the discontinued items.Actually, put them back.Variations are the exception. WordPress has no trash for them, so removing a variation is permanent. BEAR says this before doing it and says it again afterwards, because everything else here is reversible and it would be reasonable to assume this is too.
Categories, tags, attributes and their values have no trash either. Deleting one is permanent, and the preview says how many products use it, including drafts and products in the trash that aren't in the usual count.
One thing worth knowing: deletion does not go through BEAR's History. History stores the previous value of a field before overwriting it, and a deleted product has no previous value to write down. The trash is the way back, not the rollback button.
Restoring deleted products from the trash
The trash is not somewhere you have to go and look. Ask what is in it and you get the list — what was deleted, how long ago, and the status each one will return to. Ask for something back and it returns to where it was.
What's in the trash?Undo what you just deleted.Restore the three scarves.
That last detail matters more than it sounds. WordPress restores a trashed item as a draft, which means a product you thought you had recovered is still missing from the shop. BEAR puts back the status the product had before it was deleted, so a published product comes back published and you do not have to notice the difference.
Deleted products sit in the trash for thirty days by default before WordPress clears it out.
Exporting WooCommerce products and price lists
The export tool builds its rows with the plugin's own export code, so a file produced from a conversation is identical to one produced from the Export tab — attributes expanded into four columns each, ready for WooCommerce's product importer.
What you can ask for:
Which products — any filter you can describe, or the whole catalogue
Which columns, and in what order — a price list starts with the SKU, an inventory sheet doesn't need descriptions
Which separator — a semicolon for European spreadsheets
With or without variations — on by default, since that's where price and stock live
You get a download link that works for fifteen minutes and needs no login, so you can forward it or open it on your phone. The file is UTF-8 with a byte order mark, which means it opens in Excel without turning into mojibake.
Columns are drawn from the ones switched on in the editor. An export can narrow that set, not add to it — if a column you want isn't there, switch it on in the plugin settings first.
Multi-currency shops: reports in your base currency
WooCommerce analytics stores every amount in whatever currency the order was placed in and keeps no record of which. On a shop selling in several, a plain total adds euros to yen and produces a number that means nothing.
BEAR converts every reported amount back to your base currency using the exchange rate stored on each order at the time of purchase, so a March order is valued at March rates. This works out of the box with FOX — WooCommerce Currency Switcher. With another currency plugin the reports say plainly that the figures mix currencies and can't be trusted, rather than presenting a wrong total as a right one.
With FOX the assistant can also create a manual order in any currency your shop sells in, with the prices converted at the current rate and the rate stored on the order, so it is reported correctly later.
Dates like "today" and "last week" are read in your shop's time zone, the same clock WooCommerce keeps its orders on.
Free and paid: what the free version allows
The MCP server is in both versions. Reading is unrestricted in both — every report, every ready-made question, every chart, and the CSV export all work the same whether you paid or not. So is the work that isn't product editing: orders, refunds, coupons, categories, attributes and photos.
The free version limits writing, in two ways.
Which fields can be bulk edited
Prices, stock, statuses and product categories can be bulk edited. Most other fields, every attribute after the first, and the remaining taxonomies cannot — not in bulk and not one product at a time. If you ask for one of those, the assistant says so plainly instead of pretending to work.
It also knows the difference between a field that opens with the paid version and a field nobody edits, like the product ID. For the first it tells you it's a paid feature or can be changed by hand in wp-admin. For the second it doesn't send you to buy anything.
How many products per half hour
Up to 100 products every 30 minutes.
It isn't a gate that slams shut and opens again on the half hour. The allowance trickles back: one more product every eighteen seconds, whether you're watching or not. Spend it all, walk away for five minutes and there are sixteen waiting. Ten minutes, thirty-three. Half an hour and you're back to a full hundred.
Which means a shop owner who needs to fix one price never waits more than eighteen seconds for it, and one changing forty products barely notices the limit exists.
The allowance belongs to the shop, not to a key. The shop-wide key and every personal key draw from the same hundred, so giving access to three managers doesn't triple it.
Undoing something is always free. A rollback never counts against the allowance, so you're never stuck with a change you regret and no room to reverse it.
What a long bulk edit looks like
Ask for more than the allowance holds and nothing is refused. The job simply runs in portions.
You see how many products were written, how many are left, and a countdown to the next batch — down to the second, because the allowance refills continuously and "in about half an hour" isn't something you can plan around. In an assistant that renders HTML you get a progress bar and a Play button that stays greyed out until enough has accumulated, then lights up on its own with the number it can write. Elsewhere you get the same figures as a sentence and type "continue" when you're ready.
Nothing is lost between portions. The job picks up exactly where it stopped, and your selection stays valid for 24 hours.
Where the line actually falls
Forty products is one batch and you're done. Four hundred is a couple of hours with a few clicks along the way. Five thousand is more than a day, and at that point the arithmetic makes its own argument — the paid version has no allowance and no field restrictions, and writes the same five thousand in one go.
BEAR tells you which of those three you're in before starting, with the real numbers rather than a nag.
How much history is kept
The free version keeps the last two bulk operations of each author, so one manager's work never pushes out another's. Anything older is removed as new ones arrive, and once a record is gone the change behind it can no longer be rolled back — the products keep their new values and there is nothing left to restore from.
For a shop making one edit a week this is invisible. It bites when you run several operations in a session and then decide, three edits later, that the first one was wrong. The paid version keeps the full history, so anything you did stays revertible.
The assistant will tell you when an operation you are asking about is no longer there, rather than looking for it and failing quietly.
Handing a long job to your own agent
An assistant in a chat window works only while you're there. It can't wait twenty minutes for an allowance to refill and then carry on — nothing wakes it up.
An agent that runs unattended can. It needs the same two things, the address and the key, and everything described here works identically for it. Describe the task in plain words and it works through the pauses on its own.
With MCP two-factor connection on, an unattended agent still needs you once: you confirm its token at the start, and the connection then stays open for as long as it keeps working. If it goes quiet for an hour, the connection closes and needs confirming again. For agents that run on a schedule with long pauses, two-factor connection and full automation don't go together - choose which matters more for that shop.
While an agent writes unattended, every other plugin on the site still reacts to each product save, and nobody is watching the screen if one of them slows the write down or breaks it. A must-use plugin can load only the plugins you choose during MCP requests and bulk edits: see isolating plugins during bulk edits.
Requirements
WooCommerce 6.0 or newer
HTTPS on your shop
The MCP server switched on in the BEAR settings
For personal access: a user who can manage WooCommerce (the Shop manager role or an equivalent) and is on the MCP access for users list
An AI client that supports MCP
For sales, refund and margin reports: WooCommerce Analytics enabled, with its historical import finished
Common problems and how to fix them
A 403 error appears while adding the connector
Expected. Press Skip and add the Authorization header. BEAR answers 403 to anything without a valid key, including the client's first check when a connector is added. See A 403 error while adding the connector is expected above.
The assistant offers a sign-in flow instead of a header field
Choose None under Authentication. The header fields appear once you do.
The connection is refused
First make sure MCP server is set to Yes in the BEAR settings: while it is off, the address doesn't exist. Then check the key matches the one in settings, that it's prefixed with Bearer and a space, and that the address has no ?key= on the end — keys in the address are rejected by design.
With a personal key, also check that the user is still on the MCP access for users list, still has a role that can manage WooCommerce, and hasn't pressed Regenerate key since the key was put into the assistant. Any of these stops the old key at once.
The assistant asks me to confirm a token
Two-factor connection is on: switched on for the shop-wide key, or always on for a personal key. Paste the token the assistant shows you into Confirm assistant connection and press Confirm: the administrator in the shop settings, a shop manager in his own Your MCP access block. If it asks again later, the connection closed after an hour of silence, or another session was confirmed on the same key since, and a new token is needed.
The assistant says a tool is not available to me
The administrator has closed that part of the shop for your account with the permission map, or your WordPress role doesn't allow it by hand either. Ask the administrator; it isn't something the assistant can work around.
A manager can't see changes in History
A shop manager sees only his own entries, by design. The administrator sees everyone's.
Claude keeps asking permission for tools
That's Claude's own approval for each tool, and it appears the first time each one is used. Set the reading tools to Always allow in Customize → Connectors → BEAR MCP, as described above.
New tools don't appear after an update
Most clients cache the tool list from the moment the connector was added. Ask your assistant what it can do and it reads the live list from the server, including anything your client hasn't picked up. To refresh the list itself, remove the connector and add it again.
The shop shows something that isn't there
A product type that stayed on the old value after an edit, a category count that disagrees with what's in it, sorting that ignores a price you just set, a filter listing products that shouldn't match. Almost always a cache rather than lost data.
Say what you're seeing and the assistant can clear it from the conversation — the same actions as the buttons under WooCommerce → Status → Tools, without going to look for them. It knows which one fits which symptom, starts with the harmless ones, and asks before anything that deletes.
If the symptom survives that, it isn't a cache and the assistant will say so rather than running more actions hoping one sticks.
A report is empty even though there are orders
Sales reports read WooCommerce Analytics tables. If Analytics was enabled recently its import may still be running — check WooCommerce → Status → Scheduled Actions, or trigger a recount from Analytics → Settings.
Why is my margin empty?
Margin needs a cost of goods recorded on the product. Where it's missing BEAR says how many products were left out rather than guessing — a margin computed over half the catalogue isn't your margin.
🌸
Documentation for BEAR - WooCommerce Bulk Editor and Products Manager Professional: tabs, tools and developer guides
Documentation — BEAR Bulk Editor
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
For extra safety there is MCP two-factor connection. With it on, the key alone is not enough: every assistant session also needs a token that you confirm yourself in the plugin settings, and the session closes on its own after an hour of silence. It is optional, off by default, and whether you use it is your call and your responsibility. How it works is described below.
Your shop managers can have their own connection too. The administrator picks the users, and each of them gets a personal key in their own BEAR settings. An assistant connected with that key works under that person's WordPress account and can do exactly what they can do by hand, nothing more. Two-factor connection is always on for personal keys, and every change they make shows up in History under their name. See MCP access for shop managers below.
In Claude Code it's one line:
Next to each person on the list is a status line: not connected, or connected with the time of the last activity, and a Disconnect button that ends that one person's session.
The key looks like 
In ChatGPT and other clients that can't render HTML, the same request returns the same figures as a table in text. Nothing is missing except the drawing.
Worth knowing: undo a percentage change with the rollback, not with the opposite percentage. Twenty up then twenty down doesn't return you to where you started, because the second percentage is calculated from the new price. Deleting is the one exception to all of this — see below. On the free version only the last two operations of each author are kept — see below.
Nothing is lost between portions. The job picks up exactly where it stopped, and your selection stays valid for 24 hours.