Every WooCommerce integration project we take on now ends with the same question from the client: "can the AI just check the store for me?" What were last month's sales, which SKUs are out of stock, has order 48821 shipped. Reasonable questions. The tempting answer is to hand an agent full API access and let it figure things out. That is also how you end up with an LLM editing prices at 2am because it "helpfully" corrected what it thought was a typo.
So we built the boring version instead: woocommerce-mcp, a small Model Context Protocol server that gives Claude (or any MCP client) read access to a live WordPress + WooCommerce store, and nothing else. It is open source (MIT) and this post is about the design decisions, because the interesting part is not the code, it is what we deliberately left out.
Read-only is a feature, not a limitation
The single most important line in the whole project is that there are no write tools. Not "writes behind a confirmation," not "writes gated by a flag." None. The server exposes five tools and all five only read:
| Tool | What it answers |
|---|---|
list_products | search products by name/sku, with price, stock, permalink |
get_product | full detail for one product |
list_orders | recent orders, newest first, optional status filter |
sales_report | totals for a period (week / month / last_month / year) |
search_posts | published blog posts (public WP REST API, no keys) |
The reasoning is blast radius. An agent that can only read cannot oversell inventory, cannot mangle a price, cannot cancel an order because it misread a prompt. When something inevitably goes sideways in the model's reasoning, the worst outcome is a wrong answer, not a wrong database. For a store owner deciding whether to point an AI at their production shop, "it physically cannot change anything" is the sentence that closes the conversation. You can always add a separate, explicitly-scoped write path later, with human confirmation, as its own project. Bundling it into the read tool by default is how you lose trust on day one.
Scope the keys, not just the code
Read-only tools are only half the guarantee. The other half is the credential. WooCommerce REST keys come in Read, Write, and Read/Write. The README is blunt about it: create the key with Read permission only. The server sends it to your own store over HTTPS as query auth. Even if a future bug or a prompt-injected tool call tried to POST, the key itself would be refused by WooCommerce. Two independent layers (no write tools, no write key) both have to fail for anything to change. That is the level of paranoia a production store deserves.
search_posts needs no keys at all - it hits the public WP REST API - so you can demo the thing against any WordPress site before you ever generate a credential.
No plugin, no lock-in
There is nothing to install on the store. The server talks to the REST endpoints WooCommerce already ships. That matters for two reasons: you are not asking a client to add PHP to their production site just to try an AI experiment, and you are not on the hook for a plugin's update treadmill. The MCP server runs wherever the agent runs (locally over stdio, or in a container - there is a Dockerfile), and the store stays untouched.
The stack is deliberately thin
TypeScript, the official @modelcontextprotocol/sdk, zod for tool input schemas, and that is the dependency list. stdio transport, so it drops straight into Claude Desktop, Cursor, or any MCP client config without a hosted endpoint. The whole thing is a few hundred lines. MCP rewards small, single-purpose servers: one that does WooCommerce reads well composes better with other tools than a monolith that tries to own the entire store.
Where this goes next
The read-only server is the safe entry point. In real projects it is usually step one of a bigger picture: syncing that same catalog and stock data the other direction, into an ERP or a wholesaler feed, where the writes are careful, queued, and reconciled. That is a different risk profile and a different piece of software. Keeping the read layer separate and trivially auditable is what makes the rest of the integration safe to reason about.
If you run a WooCommerce store and want to try it, the repo has the two-minute setup:
git clone https://github.com/wppoland/woocommerce-mcp.git
cd woocommerce-mcp && npm install && npm run build
Then point your MCP client at dist/index.js with WP_URL and your Read-only WooCommerce keys.
Code, issues, and the full tool reference: https://github.com/wppoland/woocommerce-mcp. Feedback welcome, especially on which read-only tools you would want next - refunds summary, customer lookup, coupon status are the three we hear most.
Built by the team at WPPoland, where we spend most of our time on the less glamorous half of AI commerce: wiring WooCommerce into ERPs and wholesaler APIs so stock and prices stay honest.