Platform implementation guide

WooCommerce: build a controlled agentic-commerce path

Validate WooCommerce's developer-preview MCP integration against a test store, using its canonical product and order abilities with a dedicated least-privilege WordPress user.

Official sources reviewed 2026-08-27. This date records the documentation review, not a test of a specific merchant store.

Capabilities confirmed in official documentation

• The documented canonical set covers product query, create, update and delete, plus order query, status update and note creation.
• Each canonical ability has input and output schemas, permission callbacks and metadata describing how it can be exposed.
• Query abilities are marked read-only and idempotent. Write abilities declare destructive and idempotency behavior individually.
• Remote HTTP access uses a WordPress username and revocable Application Password over HTTPS. The documentation says not to use the account password or a WooCommerce REST API key for this path.
• The default shared endpoint is /wp-json/mcp/mcp-adapter-default-server. It exposes adapter tools that discover, describe and execute abilities rather than one top-level MCP tool per WooCommerce ability.
• The feature flag initializes the bundled MCP adapter endpoints; canonical ability registration and the Abilities REST API have separate behavior.

Implementation sequence

1. Confirm the installed WooCommerce version and read the current release notes before relying on preview behavior.
2. Enable mcp_integration only in a controlled environment, and connect to the shared WordPress MCP adapter endpoint rather than starting a new integration on the deprecated endpoint.
3. Create a dedicated WordPress user with only the capabilities needed by the selected abilities, then issue a separate Application Password for the MCP client.
4. Start with product and order query abilities. Add each write ability only after its permission callback, schema validation and retry behavior have been observed.
5. For custom abilities, define narrow schemas and omit MCP exposure metadata until the operation has an explicit permission model and test coverage.

Scenarios to test before claiming support

• A read-only agent attempts an order-status update.
• A repeated mutation request arrives after a network retry.
• An MCP client requests customer fields that are not necessary for the task.
• An unknown input field or unsupported enum reaches an ability and is rejected before execution.
• A client calls the deprecated /wp-json/woocommerce/mcp endpoint while the supported shared adapter endpoint is available.
• A product deletion is requested without force and must move the product to trash rather than silently hard-delete it.

Evidence to retain from the test

• Record the WooCommerce and WordPress versions, feature-flag state, endpoint, authenticated user role and discovered ability names.
• For each ability, retain the schema, annotations, permission result, HTTP method and redacted response from the test store.
• For writes, compare the expected object and version with the obtained store state, then replay the same request to observe documented idempotency behavior.

What the documentation does not establish

• Developer preview is not a production-stability commitment. WooCommerce warns that APIs and integration patterns may change.
• An ability being discoverable does not prove that the authenticated user is permitted to execute it.
• The MCP feature flag does not by itself prove that canonical abilities are available through every client or transport.
• This guide does not establish ACP, UCP, AP2 or checkout-payment support for WooCommerce.

Evidence boundary

Validate the installed release, shared adapter endpoint and every permission boundary. Do not promote the preview integration to a production dependency on documentation evidence alone.

Use the public signal scanner for a limited external check, then run the test cases above in a controlled environment. Review common failure modes before extending credentials or payment access.