ChatGPT can't connect to my WordPress MCP server: each error and its fix

Why does ChatGPT fail to connect when everything else works?

Because ChatGPT's sign-in takes a longer road than any other app: it registers itself with your site, signs in through a browser page on your domain, then calls the endpoint from OpenAI's servers — and each leg can be stopped by something on your server that the plugin's own checks cannot see. Four of the six support threads opened against Cowboy MCP in its first months were ChatGPT connection problems, and every one came down to one of the causes below. The ChatGPT connect guide has the setup; this page is for when the setup did not take.

Start with the Connection Doctor (Settings → Cowboy MCP → Connections → Run checks). If it passes and ChatGPT still fails, the problem is on the path between ChatGPT and WordPress, and the error text ChatGPT shows tells you which section applies.

"The server doesn't support RFC 7591 Dynamic Client Registration"

Almost always it means your site said no right now, not that it lacks the feature. ChatGPT registers itself with your site when you click Create, and Cowboy MCP accepts that registration only while New connections is on — a switch that turns itself off 30 minutes after you enable it. ChatGPT reports any refusal from that endpoint as "doesn't support RFC 7591", which is misleading.

Fix: on the Connections tab click Open ChatGPT (or Enable for 30 minutes), then click Create in ChatGPT straight away and approve the sign-in on your site. Once connected, ChatGPT keeps working after the window closes. The Connection Doctor passes in this case because the plugin is healthy; it was the window that was shut.

"This site has no record of this app"

Since 10 October 2026, ChatGPT identifies itself with a web address as its OAuth client ID, and some servers refuse any request whose query string contains an encoded address. Cowboy MCP 1.7.3 and newer accept the new client ID, but if a "bad query string" rule on your server blocks the sign-in request, the sign-in page never receives ChatGPT's identity and answers with this message. The Doctor does not exercise that step, so it passes.

The usual source is a rule in .htaccess added by a security plugin or your host, of the form RewriteCond %{QUERY_STRING} matching http, %3A, %2F or ://. Fix:

1. Exempt the sign-in path by adding RewriteCond %{REQUEST_URI} !^/cowboy-mcp-oauth/ above those rules. If the rules are not yours, ask your host to exempt /cowboy-mcp-oauth/authorize and /wp-json/cowboy-mcp/, and to clear any IP blocks that repeated failures may have placed on OpenAI's servers.
2. Test the authorize endpoint with curl from outside the site; a working site answers 302. A 400 or 403 means the rule is still in the way.
3. If you cannot find the rule, deactivate security and site-specific plugins one at a time and retest, then check wp-content/mu-plugins.
4. Once the test passes, remove the connector in ChatGPT, add it again and approve the sign-in. No reinstall is needed.

A related message, "the app's identity document on chatgpt.com is invalid", comes from Cowboy MCP 1.7.2 rejecting the new identity. Update to 1.7.3 or newer and connect again.

"auth_missing_header" in the Logs tab, and action discovery fails

A few auth_missing_header entries are normal — ChatGPT's first contact before it has a token — but a steady stream of them after you approved the sign-in means your server strips the Authorization header before WordPress sees it. Every request then arrives without the token ChatGPT sent, so the sign-in succeeds and the very next step, discovering your site's actions, fails. It happens on CGI/FastCGI hosts (check Tools → Site Health → Info → Server → Server API) and on some LiteSpeed setups.

Fix: add the standard rewrite rule that passes the header through at the top of your .htaccess — RewriteCond %{HTTP:Authorization} . followed by RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] — or CGIPassAuth On, then run the Connection Doctor again; its authenticated-handshake check confirms the header now arrives. If the host does not allow it, ask support to pass the Authorization header to PHP.

Tool results come back as an empty {}

On Cowboy MCP 1.7.3, results that carried a content field — file reads, posts, patterns and templates — arrived in ChatGPT as an empty {}, while the Logs tab showed the call succeeding. The cause was on ChatGPT's side of the protocol: it reads structured output, and those tools declared none. Version 1.7.4 adds structured output (an output schema) to the affected tools, and ChatGPT shows their contents again.

Fix: update the plugin to 1.7.4 or newer from your WordPress dashboard. Nothing changes in ChatGPT. If a result is still empty on 1.7.4, check the connection's scope on the Connections tab — a read-only connection can read files, but a custom scope that excludes the tool returns nothing to show.

"No tools are available"

A short list is normal. Cowboy MCP exposes two gateway tools, cowboy_discover and cowboy_run, instead of loading every schema into ChatGPT's context — ask it to "discover tools for WooCommerce" and it finds the rest. If even those two are missing, the connection's scope is probably empty: check it under Connected apps on the Connections tab, and reconnect with full access or a custom list that includes what you need.

Plan, workspace and WordPress.com questions

ChatGPT connects custom MCP servers from a Business, Enterprise or Edu workspace on the web; a Pro plan can connect one server for read-only use, and Developer mode is no longer involved. On Business only workspace admins and owners can add it; on Enterprise and Edu an admin grants that permission by role. If the option is missing, the plan or the role is the reason, not the site.

Cowboy MCP runs on self-hosted WordPress (version 6.2 or newer on PHP 8.0+), not on WordPress.com, which ships its own MCP server on its paid plans. And because ChatGPT connects from OpenAI's servers, the site must be on public HTTPS; a site on your laptop needs a tool that runs there instead — Claude Code, Cursor or VS Code.

Hosts that block the connection: Cloudflare, SiteGround, LiteSpeed, Basic Auth

The fix is always an exclusion for the MCP paths. Cloudflare: a WAF skip rule (or disable Bot Fight Mode) for /wp-json/cowboy-mcp/* and /.well-known/oauth-* — the Cloudflare guide walks through it with the event log. SiteGround and other ModSecurity-style firewalls: ask support to allowlist POST /wp-json/cowboy-mcp/v1/endpoint. LiteSpeed or any page cache: exclude /wp-json/cowboy-mcp/ and the root /.well-known/ paths from caching. Basic Auth: exclude /wp-json/cowboy-mcp/ and /.well-known/, because MCP clients cannot send two Authorization headers. A 401 with a password prompt, a 403 or 503 from Cloudflare, and a 403 or 406 mentioning ModSecurity each point at one of these.

Still stuck?

Run the Connection Doctor once more, copy its report, and paste it into the support forum (opens in new tab) with the exact text ChatGPT shows. Every thread so far has been answered within a day, and the fixes above came out of them. The security page explains what the Logs tab entries mean, and the undo guide covers what to do if a half-finished session changed something.

FAQ