jayson35

Hey @shiv11

Great to hear we eliminated the SSL as culprit, I dug deeper into this and found the issue.

Sep 2 timing lines up but the trigger isn’t WP 7.1 itself, it’s the site icon URL your site is serving.
Your icon goes through Jetpack Photon (i0.wp.com) with a resize query string appended:

https://i0.wp.com/marketplace.prernaa.in/wp-content/uploads/2024/08/cropped-cropped-Untitled-removebg-preview.png?fit=512%2C512&ssl=1

WordPress’s own wp_check_filetype() detects image type by matching the extension at the END of the
filename, but here the extension is followed by ?fit=…, so wp_check_filetype returns false instead
of “image/png”. Royal MCP 1.5.0’s null-coalescing fallback (?? ‘image/png’) doesn’t catch that — ??
only fires on null, not false so the server identity response ends up with mimeType: false instead of
a string.

Claude’s strict MCP handshake validator rejects that response because mimeType must be a string per
spec. Exact match for your symptom is token’s valid, but the first /mcp initialize call fails on schema
and Claude bails before tool discovery. Same failure class hits other strict MCP validators too.

Fixed in Royal MCP 1.5.1 — released yesterday, on wp.org now. wp-admin → Plugins → Royal MCP → Update. 1.5.1 strips the query string before doing the extension lookup with an explicit ext→mime map, so the response is always a valid string regardless of what CDN transformations run on the URL.

WP 7.1 core update on Sep 2 didn’t change our code path directly, most likely it triggered a Jetpack
cache regen that switched your icon URL to the Photon-transformed one, which is when the pre-existing
bug started firing. Either way the fix on our side is the same and rolled out.

Jayson