5.3.27

Fixes /mcp rejecting every bearer token: the alias dispatched with the front-end's already-resolved anonymous user, so authenticated connector calls got 401 — surfaced as "This connector has no tools available". The alias now re-determines the user with the Authorization header present.

5.3.26

Fixes re-authentication for clients configured with the /wp-json address: the discovery document and challenge header now describe the address the client actually called, instead of naming the new /mcp address everywhere.

5.3.25

The MCP endpoint now answers at /mcp. claude.ai's connector backend drops the token for any endpoint path other than exactly /mcp (#878); the /wp-json address keeps working for everything already connected.

5.3.24

The 401 challenge header now advertises the discovery document at its path-preserving location — the shape a strict client compares against. Two servers with the "signs in, token never used" connector symptom traced it to this mismatch class (#690).

Troubleshoot gains a Discovery chain row that fetches the three discovery documents the way a client would and says where they disagree.

Reconnecting: remove and re-add the connector once, so a fresh registration binds to the corrected address.

5.3.23

Two audits were answering from the wrong place.

Schema audit read per-post meta and called the rest missing. Rank Math applies a default per post type, and a post carries that schema with no meta of its own — so a site that leaves the default alone read as 0% covered while every page in fact emitted its schema. On one site: 57,417 reported missing against three that were. The default is now the baseline, and the setting behind the number is reported alongside it.

GEO check treated every AI crawler as one kind, so a site that blocks model training while leaving the answer engines open was told it "cannot be cited" by seven of them. Blocking a training crawler is a licensing choice and changes nothing about citation — Google states Google-Extended affects neither Search inclusion nor ranking. Only an answer crawler being turned away is an issue now.

Troubleshoot warns when a public HTTPS site reports itself as local, which almost always means WP_ENVIRONMENT_TYPE was never defined — and three checks on that same screen quietly relax themselves when it reads local.

Fixed: the attribution link in the plugin bar turned admin-blue on hover.

Docs: reaching the site from a phone through Remote Control, and what to do about claude.ai custom connectors, which currently complete the OAuth flow and then never send the token.

5.3.22

Troubleshoot also lists the recent sign-in requests: which OAuth endpoint was reached, from where, what was asked for and what came back. Where the list stops is where the sign-in stopped.

5.3.21

The authorization endpoint has moved out of /wp-json and into wp-admin. A REST request does not accept a cookie as proof of anything without a nonce, so a browser arriving from a connector read as logged out however long its owner had been sitting in wp-admin — and was sent to log in again, every time.

5.3.20

Reverts 5.3.16. Making the issuer follow the path the document was found under reads correct and is not what works — the endpoints do not move, so a second identifier for the same server is a second name for one thing. One issuer again, whichever URL a client asks at.

5.3.19

Approving a connection asked you to log in when you already were: the authorize endpoint is a REST route, and a REST request does not accept a cookie without a nonce, so somebody already in wp-admin read as logged out. Also answers the discovery documents in both URL shapes a client may ask in.

5.3.18

A client reads Mcp-Session-Id off the initialize response and sends it back on every call after that. WordPress exposes three headers to a cross-origin caller and this was not one of them, so the header went out and could not be read — and the second request failed for want of it. From outside that looks like the server not being an MCP server at all.