WooCommerce MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WOO_URL | Yes | The URL of your WooCommerce store, e.g. https://shop.example.com | |
| MCP_HTTP_TOKEN | No | Bearer token used by the agent in HTTP server mode. Must differ from MCP_ADMIN_TOKEN. | |
| WOO_REDACT_PII | No | Set to false to disable PII masking (emails, phones, names, street lines and IPs are masked by default). | true |
| MCP_ADMIN_TOKEN | No | Bearer token required for approvals in HTTP server mode. Must differ from MCP_HTTP_TOKEN. | |
| WOO_ALLOW_WRITES | No | Set to true to allow approved proposals to be applied to the store. When false, the server is read-only and proposals are still recorded. | false |
| WOO_CONSUMER_KEY | Yes | WooCommerce REST API consumer key (ck_…). A key with Read permission is enough for read-only use. | |
| WOO_PROPOSALS_FILE | No | Path to the JSON file where proposals are stored, so the approver can be a separate process. | |
| WOO_CONSUMER_SECRET | Yes | WooCommerce REST API consumer secret (cs_…) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
You are connected to a WooCommerce store through a read-mostly MCP server. Read tools return live data; customer PII is masked unless the operator disabled redaction. You cannot change the store directly. To change something, create a proposal with a clear reason; a human reviews it out of band and only an approved proposal can be applied with apply_proposal. Never ask the user for their store credentials; the operator configured them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| store_infoB | Store name, URL, currency, WooCommerce/WordPress versions and active payment gateways. |
| list_productsA | Search the catalogue by text, SKU, status, category or stock status. Returns a page of products with price and stock. |
| get_productB | Full product by id or SKU, including variations summary for variable products. |
| low_stock_productsB | Products with managed stock at or below a threshold (the product's own low-stock amount, or |
| list_ordersC | Orders filtered by status, date range, customer or search term (order number, name, email). |
| get_orderB | One order with line items, shipping, payment and notes. |
| search_customersC | Registered customers by email or name. PII is masked by default. |
| sales_summaryB | Totals (sales, orders, items, refunds, average) for a period: week, month, last_month, year, or a custom date range. |
| list_couponsB | Coupons with type, amount, usage and expiry. Use it to answer "is code X still valid?" before proposing anything. |
| propose_order_noteA | Propose adding a note to an order (private by default, or visible to the customer). Requires human approval. |
| propose_order_statusB | Propose a new status for an order (e.g. on-hold → processing). Requires human approval. |
| propose_stock_updateB | Propose a new stock quantity for a product or variation. Requires human approval. |
| propose_price_updateA | Propose a new regular and/or sale price (as strings in store currency, e.g. "19.90"). Requires human approval. |
| propose_refundA | Propose a (partial) refund on an order. Money moves only after a human approves and apply_proposal runs. |
| list_proposalsC | Proposals and their status (pending, approved, rejected, applied, failed). |
| apply_proposalA | Executes a proposal that a human has approved. Fails for pending or rejected proposals and on read-only servers. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Each tool targets a clearly distinct resource and action: read tools split cleanly by entity (products, orders, customers, coupons, reports, store info), and the propose_* tools each name a specific mutation target. The only near-overlap, list_products vs low_stock_products, is resolved by the latter being an explicit threshold report rather than a general search.
The dominant pattern is verb_noun (list_products, get_order, search_customers, list_coupons, apply_proposal) with propose_* used consistently for the approval-gated mutations. Three noun-only names (low_stock_products, store_info, sales_summary) deviate, but they read as report/info endpoints and remain predictable.
Sixteen tools is slightly above the ideal band but justified by the breadth of a WooCommerce store (catalogue, orders, customers, coupons, reporting) plus a coherent read/propose/apply workflow. Each tool covers a genuine capability rather than a redundant permutation.
The surface covers the full safe lifecycle: read entities, propose mutations (note, status, stock, price, refund), list and apply proposals, with sensible guards for pending/rejected/read-only states. Gaps remain for creating new records (coupons, products, orders) and fetching a single customer, which limits some administrative workflows.