How to Connect WooCommerce to ChatGPT or Claude Using MCP

• Szabi Kisded
• September 11, 2026
• WooCommerce
• 22 min read

The first time I tried to explain a WooCommerce MCP connection, I drew one arrow from the store to the AI assistant. It looked tidy. It was also wrong.

WooCommerce has an MCP endpoint, but ChatGPT and Claude do not consume that endpoint in the same way. Claude Desktop and Claude Code can start a local process that signs requests with a WordPress Application Password. ChatGPT cannot run that local command or accept a username and Application Password in its connector screen. It needs a secure tunnel or a public MCP service with OAuth.

That difference accounts for most failed setups. The store owner enables the right WooCommerce feature, copies the right URL, and then pastes it into a client whose authentication model cannot use it. The resulting error looks like a WordPress problem even though WordPress never received a valid request.

This guide shows how to connect WooCommerce to ChatGPT or Claude using MCP without hiding that split. We will enable WooCommerce’s native developer-preview integration, create a separate WordPress identity for the connection, wire Claude through Automattic’s remote proxy, and use the same proxy behind OpenAI’s Secure MCP Tunnel for ChatGPT. We will also look at the OAuth gateway a production service needs when a local process is not appropriate.

The examples use the current shared WordPress MCP endpoint, not the deprecated WooCommerce-specific endpoint found in early tutorials. They were checked against the official documentation on September 11, 2026. WooCommerce still labels this integration a developer preview, so test against the version running on your store before treating any ability schema as permanent.

What the connection actually does

MCP, the Model Context Protocol, gives an AI client a standard way to discover tools and call them with structured arguments. It does not give a model direct database access, and it does not turn a WooCommerce store into a public product feed.

WooCommerce defines commerce-specific abilities through the WordPress Abilities API. Those abilities currently cover product queries and product creation, updates and deletion, along with order queries, status changes and notes. The WordPress MCP Adapter makes registered abilities available through an MCP server. The client can inspect the available operations, obtain their input schemas and invoke an operation that the authenticated WordPress user is allowed to run.

The current remote endpoint is:

https://example.com/wp-json/mcp/mcp-adapter-default-server

You may still see /wp-json/woocommerce/mcp in an old post or configuration. WooCommerce documents that route as deprecated. New integrations should use the shared MCP Adapter endpoint above.

There is one more component in a Claude Desktop connection. @automattic/mcp-wordpress-remote runs on the same computer as the AI client. Claude talks to that process over MCP’s local standard-input transport. The process then calls the WordPress endpoint over HTTPS and supplies the WordPress credentials. It is a bridge, not another WooCommerce plugin.

ChatGPT needs a different bridge because it does not run arbitrary npx commands from a connector definition. OpenAI can reach a public remote MCP server, or its Secure MCP Tunnel can reach a local MCP process through an outbound connection. For a private development setup, the tunnel can start the same Automattic proxy that Claude runs directly.

Here is the practical choice before we touch the store:

The last two rows require more engineering, but they solve a real security problem. A public AI service should not receive a permanent WordPress password in a connector form, and current ChatGPT authentication does not offer such a field anyway.

Prepare WordPress before configuring either client

Start on staging. The current WooCommerce abilities include write operations, and an apparently harmless test prompt can become a product edit if the model chooses the wrong tool. Staging also gives you somewhere to confirm that the installed WooCommerce and MCP Adapter versions match the documentation without involving live orders.

WooCommerce’s official MCP guide says the store needs HTTPS and a permalink structure other than Plain. The site must be able to receive authenticated REST requests at /wp-json/. A security plugin, web application firewall or hosting rule that strips the Authorization header can break Application Passwords even when ordinary WordPress REST routes work for anonymous visitors.

Enable the preview through a small must-use plugin or site plugin rather than adding code to a parent theme. The documented feature filter is:

<?php
/**
 * Plugin Name: Enable WooCommerce MCP
 */

add_filter( 'woocommerce_features', function ( array $features ): array {
    $features['mcp_integration'] = true;

    return $features;
} );

If you manage the site with WP-CLI, the same feature can be enabled without a code file:

wp option update woocommerce_feature_mcp_integration_enabled yes

Do not assume that seeing the endpoint in a browser proves it works. MCP uses structured requests and authentication; an unauthenticated browser visit may show an error, a REST response or nothing useful. The meaningful test happens through an MCP client after credentials are in place.

Create a dedicated WordPress account for the connection. An existing Administrator account is convenient but leaves the AI client holding far more authority than it needs. The account must have WordPress’s basic read capability to use the default MCP server, while each WooCommerce ability performs its own permission check. A catalog assistant and an order-support assistant should therefore use different accounts if their responsibilities differ.

Open the profile for that account in WordPress, find Application Passwords, give the credential a recognizable name such as Claude Desktop - staging, and generate it. WordPress shows the value once. Save it in an appropriate password manager before leaving the page.

This is a WordPress Application Password, not the user’s normal login password and not a WooCommerce REST API consumer key. Those credentials are not interchangeable. A separate Application Password for every client makes incident response much easier: revoking Claude’s credential should not disconnect a monitoring service or another developer.

Connect Claude Desktop to WooCommerce

Claude Desktop is the shortest route because it can run a local MCP server. Install a current Node.js release first. Automattic’s proxy currently requires Node.js 22 or newer, which is easy to miss on computers managed through nvm; the desktop app may find a different npx binary from the one your terminal uses.

Open Claude Desktop’s developer settings and edit its MCP configuration. Add the following server, replacing the example domain, username and password. The OAUTH_ENABLED value matters: Automattic’s current proxy prefers OAuth by default, while this configuration deliberately uses a WordPress Application Password.

{
  "mcpServers": {
    "woocommerce_store": {
      "command": "npx",
      "args": [
        "-y",
        "@automattic/mcp-wordpress-remote@latest"
      ],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "mcp-catalog-operator",
        "WP_API_PASSWORD": "replace-with-wordpress-application-password",
        "OAUTH_ENABLED": "false"
      }
    }
  }
}

Preserve any existing mcpServers entries rather than replacing the whole object. JSON does not allow trailing commas or comments. Once the file is saved, quit Claude Desktop completely and reopen it so the process is started with the new environment.

The Application Password sits in a local configuration file in this arrangement. Protect that user account, restrict access to the computer, and do not commit the config to a dotfiles repository. If several employees need the connection, a hosted OAuth gateway is safer than distributing copies of one WordPress credential.

Begin with a request that cannot alter the store. For example:

Use the WooCommerce store connection to find up to five published products whose stock status is out of stock. Return the product ID, name and current status. Do not change anything.

The client should show that it intends to use the WooCommerce connection and ask for approval if tool approvals are enabled. Compare the result with the Products screen in WordPress. A fluent answer is not enough; the IDs and status values need to match the store.

When read access is dependable, try one controlled write on a disposable staging product:

Find the staging product with SKU MCP-TEST-001. Before making a change, show its product ID and current catalog visibility. Ask me to approve the exact new value, then update only that field.

The instruction to ask first is useful, but it is not a security boundary. WordPress capabilities remain the real boundary. If an account must never delete products, its role should be unable to delete them even when a prompt or tool call requests it.

Connect Claude Code from the terminal

Claude Code uses the same proxy and credentials, but its CLI removes the need to edit JSON manually. WooCommerce documents this command form:

claude mcp add \
  --env WP_API_URL=https://example.com/wp-json/mcp/mcp-adapter-default-server \
  --env WP_API_USERNAME=mcp-catalog-operator \
  --env WP_API_PASSWORD='replace-with-wordpress-application-password' \
  --env OAUTH_ENABLED=false \
  woocommerce_store \
  -- npx -y @automattic/mcp-wordpress-remote@latest

Use a project-scoped connection when only one codebase should see the store, or the appropriate user scope when this is an intentionally shared local tool. Be cautious with shell history and terminal recordings: putting a secret on a command line can leave a copy behind. On a long-lived development machine, supply the values through the secret-management method used by your team rather than repeatedly pasting the password.

Claude Code is particularly useful while developing a WooCommerce extension because the client can inspect local code and query a staging store in the same session. Keep those permissions separate. The ability to edit files in a repository does not imply permission to edit products, and the store credential should not be written into the repository’s .env.example, documentation or test fixtures.

If the store is itself local and WP-CLI can reach it, WooCommerce also documents a direct WP-CLI MCP server. That avoids remote HTTP and the Application Password altogether:

{
  "mcpServers": {
    "woocommerce_local": {
      "command": "wp",
      "args": [
        "--path=/absolute/path/to/wordpress",
        "mcp-adapter",
        "serve",
        "--server=mcp-adapter-default-server",
        "--user=admin"
      ]
    }
  }
}

This form is for a WordPress installation available on the same machine. The --user value controls the WordPress permissions used by the server, so it deserves the same least-privilege treatment as a remote account.

Why ChatGPT cannot use the Claude configuration

ChatGPT’s custom MCP connections are remote services. They do not accept a Claude-style mcpServers block and do not start npx on your laptop. Its authenticated connection flow expects OAuth 2.1 and presents a bearer token to the MCP service. OpenAI’s current authentication documentation explicitly does not support a customer-supplied API key as a substitute.

The native WooCommerce endpoint in this guide expects WordPress authentication. With the simple remote setup, that means Basic authentication using a WordPress username and Application Password. Pasting the endpoint into ChatGPT therefore leaves an authentication gap: ChatGPT cannot present the credential format that WordPress expects.

Disabling authentication to make the connection fit would be reckless. The endpoint exposes store operations, not a static public document. Query parameters containing credentials are no better; they leak through logs, browser history and intermediaries.

There are two defensible answers. For private development, OpenAI’s Secure MCP Tunnel can make a local process available to ChatGPT without publishing it on the internet. For a production or multi-user service, a public OAuth-enabled MCP gateway should sit between the AI client and WordPress.

Use OpenAI’s Secure MCP Tunnel for private testing

The Secure MCP Tunnel maintains an outbound HTTPS connection to OpenAI and forwards MCP traffic to a local HTTP or standard-input server. Because the connection begins from your machine, you do not need to expose the Automattic proxy on a public port.

Access to tunnels depends on the OpenAI organization, workspace and permissions attached to your account. Create a tunnel in the OpenAI Platform first and associate it with the ChatGPT workspace that will use it. The machine running the tunnel needs the official tunnel-client, an API key with permission to use that tunnel, and Node.js 22 or newer for the WordPress proxy.

The following pattern combines two separately documented components: OpenAI’s tunnel starts a local MCP command, and Automattic’s command forwards that traffic to WordPress. WooCommerce and OpenAI do not currently publish this as a one-click joint recipe, so treat it as an integration pattern and test it against your own versions.

export CONTROL_PLANE_API_KEY='sk-replace-me'
export WP_API_URL='https://example.com/wp-json/mcp/mcp-adapter-default-server'
export WP_API_USERNAME='mcp-catalog-operator'
export WP_API_PASSWORD='replace-with-wordpress-application-password'
export OAUTH_ENABLED='false'

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile woocommerce-staging \
  --tunnel-id tunnel_replace_me \
  --mcp-command "npx -y @automattic/mcp-wordpress-remote@latest"

tunnel-client doctor --profile woocommerce-staging --explain
tunnel-client run --profile woocommerce-staging

The exported values are inherited by the proxy process. For anything beyond a short-lived test, load them through the host’s secret store or service manager instead of keeping them in a shell profile. The control-plane key belongs on the tunnel host and must never be sent to WordPress.

After the tunnel reports healthy, enable Developer mode in ChatGPT under Settings and Security and login. Open ChatGPT Plugins, create a connection, choose Tunnel as the connection type and select the tunnel you associated with the workspace. The exact controls shown can depend on workspace policy and account access. OpenAI’s ChatGPT MCP connection guide is the right place to check if the menu labels change.

Test with the same read-only product request used for Claude. Stop the local tunnel-client process when testing is finished and revoke any credential that was exposed during setup. A stopped tunnel removes reachability, but it does not revoke the WordPress Application Password or the OpenAI API key; those have separate lifecycles.

Build an OAuth gateway for a durable remote connection

A tunnel is useful for a developer workstation. It is awkward if a team expects the connection to be available all day or if customers will authorize access to their own stores. That is where a hosted MCP gateway belongs.

The gateway presents the remote, streamable HTTP interface and OAuth 2.1 metadata expected by ChatGPT. It validates the bearer token, resolves the tenant and user, checks the requested scope, then forwards an authorized call to the correct WooCommerce store. The WordPress Application Password or WordPress-side OAuth credential stays in the gateway’s encrypted secret store. It is never returned to the AI client.

Claude’s cloud-hosted custom connectors have a similar requirement. A connector used from claude.ai or Cowork runs from Anthropic’s cloud, not from the local copy of Claude Desktop. It therefore needs a publicly reachable remote MCP service and generally an OAuth flow. Anthropic’s remote connector guide explains the organization and user authorization flow. If you need both ChatGPT and Claude web access, one standards-compliant gateway can serve both clients after their discovery and OAuth behavior has been tested independently.

Avoid writing an authorization server from scratch merely to complete this integration. OpenAI recommends using an established identity provider. The gateway still has work to do after login: it must map each identity to one or more stores, enforce scopes, isolate credentials, record administrative events, handle revocation and prevent one tenant from naming another tenant’s store in a tool call.

The gateway should also narrow the tool surface. A merchandising team may receive product-search and product-update abilities but no order access. A support team may query orders and add internal notes without changing product prices. A public customer assistant should not inherit back-office abilities just because they already exist in WooCommerce MCP.

This layer is more than an authentication adapter. It is where a business decides which store operations an AI client is allowed to perform, under whose identity, and with what audit trail.

Permissions matter more than the prompt

It is tempting to write “never delete a product” in the system prompt and call the integration read-only. That instruction can improve normal behavior, but it cannot defend against a misunderstood request, prompt injection or a client bug.

Use WordPress permissions to make prohibited calls fail. The default MCP server requires an authenticated user with read, and individual abilities run their own permission callbacks. Give the connection only the capabilities its job requires. If the available WordPress roles are too broad, create a reviewed custom role rather than handing a general Administrator account to the model.

Product descriptions, order notes and customer-supplied fields must be treated as untrusted data. A malicious string inside a product description may tell the model to ignore its instructions or call another tool. The client should not treat tool output as policy, and sensitive writes should remain behind human approval. Permission checks still need to deny calls that no human should be able to approve from that connection.

Order data deserves tighter handling than public catalog data. Customer names, addresses, email addresses and notes may contain personal information. Do not expose order-query abilities to a connection built only to write product copy. Keep logs useful enough for incident review without copying authorization headers, Application Passwords or entire customer records into a third-party logging service.

Application Passwords are revocable and individually named, which makes them suitable for a controlled server-to-server connection. They are still credentials. Rotate them when staff or devices change, remove unused entries from the WordPress user profile, and use a new value for production rather than promoting the staging password.

Test the result as a tool connection, not a chatbot demo

A convincing paragraph from Claude or ChatGPT does not prove the MCP connection is correct. The model may answer from context or invent a plausible product. Verification begins with a record whose ID, SKU and status you already know.

Ask for one narrow read, inspect the client’s tool-call panel, and compare every returned field with WooCommerce. Then request a deliberately invalid product ID. A good integration should return a structured error or an empty result rather than fabricate a replacement. Only after those tests should you allow a write to one staging product.

For write testing, record the product before the call, approve one changed field, refresh the WordPress admin and inspect the database-backed value. Repeat the same tool request or simulate a client retry. An update should remain predictable; a create operation needs special care because a retry can produce duplicate products if the ability and calling workflow do not use a stable external identifier.

Order testing needs fake orders and a non-production payment environment. Confirm what happens when an order is in a state that should not be changed, when the authenticated role lacks the capability, and when the order disappears between a query and an update. The MCP client must not be able to bypass WooCommerce’s business rules simply because the request arrived through an AI tool.

WooCommerce writes integration messages to its logging system. Open WooCommerce, Status and Logs, then inspect the woocommerce-mcp source while reproducing a failure. Keep the local proxy’s output visible as well. The two sides answer different questions: the proxy shows whether it could reach and authenticate to WordPress, while WooCommerce shows what the store did with the request.

Fix the failures that appear most often

When no WooCommerce tools appear in Claude, check the process before changing WordPress. Claude Desktop must have been restarted after its config changed. The JSON must parse, npx must be visible to the desktop process, and that npx must run Node.js 22 or newer. Running which npx in a terminal can expose an nvm path that the desktop app does not inherit.

A 404 response usually points to the wrong endpoint, disabled feature, missing MCP Adapter route or Plain permalinks. Confirm that the URL ends in /wp-json/mcp/mcp-adapter-default-server, not the deprecated WooCommerce route. Flush WordPress rewrite rules by visiting the Permalinks screen and saving only if the environment’s deployment process permits that change.

A 401 means the request did not arrive with valid authentication. Recheck the WordPress username and Application Password, not the account’s browser-login password. Some hosts and reverse proxies remove the HTTP Authorization header; the host must pass it through to PHP. A 403 after successful authentication more often means the user lacks a capability required by the selected ability, or a security layer has blocked the route.

Local and corporate TLS certificates can cause another misleading failure. A site may open in the browser and work with curl while Node.js rejects its certificate chain. Automattic recommends adding the trusted CA through NODE_EXTRA_CA_CERTS, or using Node’s system-CA support on a compatible release. Do not “fix” a real store by setting NODE_TLS_REJECT_UNAUTHORIZED=0; that disables certificate verification for the process and makes credential interception possible.

Long catalog queries can outlive the proxy’s defaults on slow staging sites. The current proxy exposes WP_API_INIT_TIMEOUT_MS for initialization and WP_API_TIMEOUT_MS for ordinary requests. Raising a timeout may help diagnose a slow request, but it should not hide an unbounded product query, a failing database or an upstream firewall that never returns a response.

If ChatGPT reports unsupported authentication immediately after you add the raw WooCommerce URL, the failure is probably architectural rather than a typo. The WordPress endpoint and ChatGPT connection are speaking different authentication schemes. Use the secure tunnel for a private test or put an OAuth gateway in front of WordPress.

What becomes useful once the connection is trustworthy

The best early uses are bounded back-office tasks with results that a person can inspect. A merchandiser can ask which published products are out of stock but still featured, compare short descriptions across a category, or find products missing an SKU. The model saves navigation and filtering time; WooCommerce remains the source of truth.

Product writing can work well when the tool separates research from publication. Let the assistant query the existing product, draft a revised description in the conversation, and wait. A human reviews the claims and then approves one product update. Letting a model both invent specifications and publish them in the same unattended step is how a convenience feature becomes a catalog-liability problem.

Order operations should begin even more conservatively. Summarizing a known test order or preparing the text of an internal note is easier to review than changing fulfillment state. If an assistant will change statuses, make sure the permitted transitions match the store’s workflow and that another system is not using the status change to trigger email, stock or shipping automation.

MCP is also useful while building a WooCommerce extension. Claude Code can inspect an ability schema, call a staging instance, compare the response with local PHP types and help reproduce a permission failure. That shortens the debugging loop without granting the model direct SQL access or production credentials.

None of these connections makes the store discoverable in public ChatGPT shopping results. Private MCP access, product-feed distribution and agentic checkout are different systems. If public AI product discovery is the goal, work on the catalog feed and structured commerce data described in our guide to agentic commerce for WooCommerce alongside the private MCP connection.

Frequently asked questions

Is WooCommerce MCP included in WooCommerce?

WooCommerce provides the commerce abilities and integration documented in its current MCP developer preview. It uses the WordPress Abilities API and WordPress MCP Adapter. The feature still has to be enabled, and remote desktop connections use a bridge such as Automattic’s mcp-wordpress-remote package.

Can I paste the WooCommerce MCP URL directly into ChatGPT?

Not with the simple Application Password setup shown here. ChatGPT’s authenticated remote MCP connection expects OAuth 2.1 and cannot accept a custom WordPress username and Application Password. Use OpenAI’s Secure MCP Tunnel for a private development connection or deploy an OAuth-enabled MCP gateway.

Can I paste it directly into Claude’s web connector?

Claude’s remote connectors run from Anthropic’s cloud and normally use a public remote MCP service with OAuth. The local proxy configuration works with Claude Desktop and Claude Code, not automatically with claude.ai or Cowork. A hosted OAuth gateway is the appropriate route for cloud access.

Does the AI receive my WordPress administrator password?

It should not. Use a separately generated WordPress Application Password attached to a dedicated low-privilege account. The local proxy supplies that credential to WordPress. In a hosted design, the gateway stores the WordPress credential and the AI client authenticates to the gateway through OAuth.

Can ChatGPT or Claude create and edit WooCommerce products?

Yes, if the current WooCommerce abilities expose the operation and the connected WordPress user has the required permission. That is why the account design matters. A read-only role should be used when the assistant only needs to inspect catalog data.

Does this replace the WooCommerce REST API?

No. The REST API remains useful for conventional integrations with known endpoints. MCP adds discovery and structured tool calling for AI clients. Underneath, both approaches still need authentication, permissions, stable business logic and careful error handling.

Is the current integration ready for unattended production automation?

WooCommerce still describes MCP support as a developer preview. A narrowly scoped production experiment may be reasonable after staging tests and a security review, but an unattended connection with broad product and order permissions would be difficult to justify. Keep the adapter replaceable and watch WooCommerce release notes for schema or endpoint changes.

Can one setup connect several stores?

Yes, but give every store a distinct server name, endpoint and credential. In a hosted gateway, tenant isolation must prevent a user or tool argument from switching to another merchant’s store. A separate Application Password per store also makes revocation and audit work clearer.

A good connection is deliberately boring

The useful result is not an AI assistant with unrestricted control of WooCommerce. It is a small, dependable tool surface that returns the right product, refuses an unauthorized action and leaves enough evidence to understand what happened.

For one operator, Claude Desktop or Claude Code plus Automattic’s local proxy is the most direct route. For ChatGPT development, the Secure MCP Tunnel can carry that same local proxy without exposing a public port. For a team or customer-facing product, build a proper OAuth gateway and keep the WordPress credentials behind it.

Once that plumbing is correct, the conversational part becomes almost ordinary. The hard work sits where it should: WordPress permissions, authenticated transport, predictable WooCommerce operations and human approval when a request can affect a real customer or order.