OAuth Tables Missing — “Couldn’t Register with Sign-In Service” or “Session Not Found”

Method 1 — Claude.ai native connector (OAuth)

“Couldn’t register with your site’s sign-in service. You can try again, or add an OAuth Client ID in the connector settings.”

Or the connector appears to add successfully but no tools show up in the connector list. The Claude.ai authorization step itself often never completes — the broker POSTs to /register first, gets back a 500, and surfaces the error to the user immediately.

Method 2 — API key with mcp-remote (Claude Desktop)

“Session not found or expired. Please re-initialize.” (HTTP 404)

The connection initializes successfully, then the very next request fails with a 404. Some clients then fall back to SSE-only transport, which itself fails with SseError: Non-200 status code (405). API-key auth doesn’t touch the OAuth tables, but the moment initialize tries to persist your session, the missing wp_royal_mcp_sessions table causes the same class of failure.

Server-side error message (any client)

If you can capture the raw response body from a failed POST /register, you’ll see:

{
  "error": "server_error",
  "error_description": "Failed to persist client registration. The OAuth tables may be missing — deactivate and reactivate Royal MCP to recreate them."
}

That message is the unmistakable confirmation. If you can’t capture the body, the diagnostic in the next section confirms it from the database side.

1. Runtime healer now verifies tables exist before short-circuiting

Pre-1.4.29, the maybe_upgrade_db() function trusted the royal_mcp_db_version option as a proxy for “tables are current.” If anything caused the tables to disappear while the option stayed at the current version (uninstall that left the option behind, a manual table drop, a partial restore), the healer kept short-circuiting and never tried to recreate them. 1.4.29 adds an explicit SHOW TABLES LIKE probe to the short-circuit condition — if either canary table (oauth_clients, sessions) is missing, the function falls through and recreates everything on the next pageload. No deactivate / reactivate required.

2. uninstall.php now clears the version option too

Pre-1.4.29, deleting Royal MCP dropped the tables and cleared royal_mcp_settings but left royal_mcp_db_version behind. If you then reinstalled Royal MCP on the same WP install, the option still matched the new plugin version and the old healer (which trusted the version string) skipped table re-creation — latching the install into a permanently stuck state. 1.4.29’s uninstall clears royal_mcp_db_version so any future reinstall starts from a fully clean slate.

1. The 1.4.27 migration race (fixed in 1.4.29)

1.4.27 introduced a new wp_royal_mcp_sessions table to move MCP session state off the object cache. The runtime migration that creates that table relies on the WordPress autoloader to find the Session_Store class. On LiteSpeed-fronted installs with opcache, plus any environment where the autoloader transiently failed during the wp.org file-swap, the autoloader could miss the class and the migration would silently mark the schema as “up to date” without actually creating the new table. 1.4.29 added success-tracking to the migration — royal_mcp_db_version only advances when every required create_tables() call actually ran — plus a file-existence force-load fallback so a transient autoloader miss can’t latch the install.

2. The uninstall → reinstall cycle (fixed in 1.4.29)

Pre-1.4.29 uninstall.php dropped all five tables and cleared royal_mcp_settings — but left royal_mcp_db_version in place. If you reinstalled Royal MCP on the same WP install (same DB), the activation hook ran but the runtime healer immediately saw the option still matching the new plugin version and skipped table re-creation. Result: plugin active, no tables, every OAuth call fails. 1.4.29’s uninstall now clears the version option, AND the new healer verifies tables exist regardless of what the option says.

3. External table loss (always — 1.4.29 makes it recoverable)

Tables can also disappear from causes outside Royal MCP’s control: a partial database restore that skipped the royal_mcp_* tables, a hosting-side database swap, a manual DROP TABLE, or a backup-plugin restore that missed the plugin’s custom tables. Pre-1.4.29, these scenarios produced the same stuck state because the healer trusted the option. 1.4.29’s table-existence probe makes any external table-loss self-recoverable on the next pageload, without any user action.

Information to include in your post or ticket

• Your hosting provider (SiteGround, o2switch, Hostinger, etc.) so we can check whether we’ve seen this on that host before
• Royal MCP version from WP Admin → Plugins (must be 1.4.13 or newer for the bypass headers)
• Output of the curl headers test from the Verify section above — full response headers, not just the body
• Active caching plugins — output of wp plugin list --status=active if you have WP-CLI access, or a screenshot of the Plugins admin page filtered by “cache”
• WAF / security plugins that might filter REST requests (Wordfence, iThemes Security, GuardPress, etc.)
• Whether you have Cloudflare in front of the domain, and if so whether APO is enabled