paddyv

I would love to accept the header trick but thats way beyond my technical ability – that was all Claude 😂

Heres some more details and how I fixed it should anyone find this thread and have the same issue.

Root cause (confirmed with the host): on SiteGround, /.well-known/ is
served from NGINX globally — file exists -> 200, file missing -> 404 —
and the request never falls through to WordPress’s index.php. AI Engine’s
OAuth handler does correctly register the RFC 8414 host-inserted path,
but the PHP hook can’t fire because the request doesn’t reach PHP.
SiteGround support confirmed this is a fleet-wide config that can’t be
altered per-site.

This will hit any AI Engine MCP user whose host serves /.well-known/
from a layer above PHP. SiteGround is one example; other managed
WordPress hosts that special-case /.well-known/ (typically for Let’s
Encrypt acme-challenge) will likely behave the same way.

No plugin changes are needed — AI Engine already serves both URL forms
correctly when the request reaches PHP. The fix is at the network/CDN
layer.

Workaround — Cloudflare URL Rewrite Transform Rule

If your site is fronted by Cloudflare (free plan is fine), add a
Transform Rule that rewrites the failing path to the working one at
the edge before it hits the origin:

Rule type: Transform Rules -> Rewrite URL
Rule name: OAuth AS metadata – RFC 8414 path

If incoming requests match (Custom filter expression):
Hostname equals http://www.example.com
AND
URI Path equals /.well-known/oauth-authorization-server/wp-json/mcp/v1

Then… Set Rewrite parameters:
Path: Rewrite to… -> Static
wp-json/mcp/v1/.well-known/oauth-authorization-server
Query: Preserve

Two important notes:

1. The Path “Static” textbox must NOT have a leading slash. Cloudflare’s
   UI shows a fixed “/” before the textbox and prepends it. If you
   include a leading slash you’ll get “//wp-json/…” (double slash)
   and the rewrite fails.
2. The URI Path match is exact, so it only catches that one path. Other
   /.well-known/ traffic (acme-challenge, security.txt, etc.) is
   unaffected.

After deploying, verify with:

curl -i https://www.example.com/.well-known/oauth-authorization-server/wp-json/mcp/v1

You should see HTTP/2 200, content-type: application/json, and the
full AS metadata body. Once that returns, the claude.ai custom-connector
“Couldn’t reach the MCP server” error goes away and OAuth completes
normally — browser opens to WordPress login, approval screen, connector
authorized.

Thanks Jordy — claude web connector and Cowork now working end to end 💪🏻

Update below from Claude after checking siteground logs

Root cause identified (RFC 8414 well-known path)

I traced this with server access logs. OAuth discovery fails at a
specific, reproducible step:

1. The client fetches the protected-resource metadata successfully:
   GET /wp-json/mcp/v1/.well-known/oauth-protected-resource -> 200
   It correctly lists the authorization server as
   https://example.com/wp-json/mcp/v1
2. The client then requests the Authorization Server Metadata. Per
   RFC 8414, for an issuer with a path component, the URL is built by
   inserting the well-known segment between host and path:
   GET /.well-known/oauth-authorization-server/wp-json/mcp/v1 -> 404
3. AI Engine only serves that document at a path-suffixed location:
   GET /wp-json/mcp/v1/.well-known/oauth-authorization-server -> 200

Discovery dies at step 2, and the client shows a generic
“couldn’t reach the server” error.

Root cause: AI Engine serves the oauth-authorization-server metadata
using OpenID-Connect-style path placement (issuer + /.well-known/…),
but RFC 8414 requires host-inserted placement
(/.well-known/oauth-authorization-server + issuer-path). The
protected-resource document works only because the client is handed its
exact URL via the WWW-Authenticate “resource_metadata” hint; the
authorization-server URL must be constructed by the client, and a
compliant MCP client constructs the RFC 8414 path.

Request: could AI Engine also register/serve the authorization-server
metadata at the RFC 8414 host-inserted path:
/.well-known/oauth-authorization-server/wp-json/mcp/v1
(in addition to the current path-suffixed route)? That one change should
let strict MCP clients — including the Claude custom connector — complete
discovery.

Environment: AI Engine 3.5.2, WordPress 7.0, endpoint
/wp-json/mcp/v1/http, client = Claude custom connector (claude.ai web).

Thanks!

The form on the bottom of the page

RTFM………!

Edit wp-config.php
It should be possible to fix the site URL using a new feature –

Add these two lines to your wp-config.php, where “example.com” is the NEW location of your site.

define(‘WP_HOME’,’http://example.com’);
define(‘WP_SITEURL’,’http://example.com’);
This is not necessarily the best fix, it’s just hardcoding the values into the site itself. You won’t be able to edit them on the General settings page anymore when using this method.