WordPress.com MCP: DCR fails on official connector, then "Authorization with WordPress failed" on custom connector (ofid_ffb5e7cc3c531aef, ofid_b6a5991aeddcca97)

### MCP server URL or name

https://public-api.wordpress.com/wpcom/v2/mcp/v1

### How are you connecting to this server?

From browsing the MCP server directory

### Where does the issue occur?

When pressing the Connect button

### When did you last reproduce this?

2026-09-04, ~15:00 CEST (Europe/Berlin)

### Browser and OS

Chrome on macOS; also reproduced in the Claude desktop app

### Describe the issue

I am trying to connect the WordPress.com MCP server to Claude. I am a user of that server, not its maintainer.

Two different failures, depending on how I add it:

1. Official WordPress.com connector from the connector directory ("Browse connectors" -> WordPress.com):
Connecting fails immediately with "Couldn't register with WordPress.com's sign-in service. You can try again, or add an OAuth Client ID in the connector settings."
Reference: ofid_ffb5e7cc3c531aef
This looks like Dynamic Client Registration failing. WordPress.com does support DCR at https://public-api.wordpress.com/oauth2-1/register and does not hand out a client ID to paste in manually, so there is nothing I can enter in the advanced settings.

2. Same server URL added manually as a custom connector:
Registration succeeds and the WordPress.com OAuth authorization screen appears, but after authorizing I get "Authorization with WordPress failed. You can check your credentials and permissions."
Reference: ofid_b6a5991aeddcca97

Everything on the WordPress.com side is configured correctly (verified at wordpress.com/me/mcp):
- "Enable MCP access" is ON
- 24 of 38 read tools and 75 of 90 write tools enabled
- Site exceptions: none
- Paid plan active (WordPress.com Personal), so MCP is included
- WordPress.com's own setup page tells users to simply install the official connector from Claude's directory, which is exactly the path that fails in (1)

Steps already tried:
- Removed the connector in Claude and re-added it from scratch
- Removed the authorized app under wordpress.com/me/security/connected-applications
- Tried claude.ai in the browser and the Claude desktop app
- Tried both the directory connector and the manual custom connector URL

Since the token exchange clearly succeeds in case (2) and the failure only appears afterwards, this looks like it fails on Claude's authenticated callback to the MCP endpoint rather than in the OAuth flow itself. The error message doesn't distinguish those cases, which makes it impossible to tell from the user side.

### Error details

```shell
Official directory connector: "Couldn't register with WordPress.com's sign-in service. You can try again, or add an OAuth Client ID in the connector settings. If this persists, share this reference with support: ofid_ffb5e7cc3c531aef" | Custom connector: "Authorization with WordPress failed. You can check your credentials and permissions. If this persists, share this reference with support: ofid_b6a5991aeddcca97"
```

### Expected behavior

The WordPress.com connector should complete the OAuth flow and connect, so that the MCP tools enabled in my WordPress.com account are available in Claude.

### Additional context

MCP server URL (as provided by WordPress.com's own manual setup panel):

```json
{
"mcpServers": {
"wpcom-mcp": {
"url": "https://public-api.wordpress.com/wpcom/v2/mcp/v1"
}
}
}
```

Related reports with the same "Authorization ... failed" pattern and ofid references: #327, #435, #503. In #327 the root cause turned out to be Claude's post-token callback being blocked before it reached the MCP server, while the error message pointed at credentials/permissions. It would help a lot if the error distinguished (a) DCR failure, (b) token exchange failure, and (c) post-token callback failure.

Start by reproducing the official directory connection and the manually added server URL, comparing the DCR, token exchange, and post-token callback stages described in the report; use references ofid_ffb5e7cc3c531aef and ofid_b6a5991aeddcca97 and read related issue #327. Done means the WordPress.com connector completes authorization, or the user-facing error identifies the failing stage accurately.

Vom Indexierungsmodell aus dem Issue-Text verfasst.