OAuth Endpoints Overlap with Existing Pages

Royal MCP’s admin self-check detected that your site has published pages at one or more of the slugs Royal MCP uses for OAuth endpoints (/authorize, /token, /register). The most common cause is a membership plugin (MemberPress, Paid Memberships Pro, Ultimate Member, BuddyBoss) creating a /register page. In most cases this is harmless — visitor GET requests to those URLs still fall through to your published pages correctly, and MCP POST requests still reach Royal MCP. But if the shadowing page also accepts POST form submissions, there can be a real collision. This page tells you when it matters and how to relocate the OAuth endpoint via a WordPress filter.

👉 Read this first — is it actually broken?

The plugin flags this collision proactively because it can cause POST-method collisions in some setups, but the notice does NOT mean your site is broken. Royal MCP applies a method filter to its rewrite rules: visitor GET requests to /register reach your published page as expected. Only POST requests to /register reach Royal MCP’s OAuth registration endpoint.

For the standard membership-plugin case (a login/registration page that renders forms and posts them back to WordPress via AJAX or a nonce’d POST to /register), there IS a real collision. Follow the fix below.

For simple cases where /register is a marketing page that never accepts POST, you can safely dismiss the notice.

Confirm Whether It’s Actually a Problem

The notice tells you which page slug overlaps — typically /register, less commonly /authorize or /token. Before deciding to relocate the OAuth endpoint, check whether the shadowing page actually accepts POST form submissions.

Test 1 — Does the page accept POST?

Load the page in a browser, right-click, View Source, and look for any of these:

Signs the page accepts POST

A <form method="post"> element (or method="POST")
A form with no explicit method (HTML defaults to GET, but many form-builder plugins actually submit via JavaScript POST)
An AJAX submission handler (search for admin-ajax.php, rest_url, or your membership plugin’s custom endpoint)
A membership plugin registration shortcode in the page’s post_content (any shortcode from MemberPress, Paid Memberships Pro, Ultimate Member, BuddyBoss, etc. that renders a signup form)

If the page contains any of those and the form action posts back to the same URL (the overlapping slug), you have a real collision. Proceed to the fix.

If the page is just informational (a marketing landing page, a static “Contact us” page with a link, etc.) and doesn’t submit any POST to itself, the collision is theoretical — you can safely dismiss the admin notice.

Test 2 — Does POST from a POST client actually collide?

From your local terminal:

curl -X POST -H "Content-Type: application/json" -d '{}' -i https://your-site.com/register

You’re seeing a collision if:

The response contains HTML (a membership plugin’s success page, error page, or CSRF-token error) instead of a JSON body
The status code is 200 or 302 with HTML body

You’re NOT hitting the collision (and the notice is safely dismissible) if:

The response is JSON with Content-Type: application/json
The error field mentions something OAuth-specific like invalid_request, invalid_redirect_uri, or server_error — that’s Royal MCP’s /register endpoint responding, just rejecting your empty payload

Why This Happens

Royal MCP registers rewrite rules for its OAuth endpoints at the domain root: /authorize, /token, /register. These are standard OAuth 2.0 paths.

Meanwhile, many membership and community plugins publish user-facing pages with the same slugs. MemberPress defaults /register as its signup page. Paid Memberships Pro can do the same. Ultimate Member creates /register as part of its default install. BuddyBoss too.

WordPress’s rewrite engine resolves published-page slugs BEFORE checking Royal MCP’s rewrite rules. To handle this, Royal MCP applies a method filter to its rewrite rules: only POST requests to /register reach Royal MCP; GET requests fall through to your published page. This works for the common case of a membership plugin whose registration form is on a different URL (e.g., /signup) and just links to /register as a display page.

But if your membership plugin’s registration form is on /register itself, its POST handler and Royal MCP’s POST handler both want the same URL. Whichever fires first wins. Nonce mismatches, CSRF errors, or silent form failures follow.

Relocate Royal MCP’s OAuth Endpoint via Filter

Royal MCP exposes a WordPress filter, royal_mcp_oauth_rewrite_paths, that lets you rename the OAuth endpoints to any path you choose. The admin notice includes a copy-paste snippet using the specific slug that’s overlapping on your site. Here’s the general form:

Step 1 — Create a must-use plugin file

Via SFTP or SSH, create a new file at:

/wp-content/mu-plugins/royal-mcp-oauth-relocate.php

The mu-plugins/ directory (must-use plugins) loads earlier than regular plugins and doesn’t need to be activated. If the directory doesn’t exist, create it.

Step 2 — Paste the filter snippet

Copy this into the new file:

<?php
/**
 * Relocate Royal MCP OAuth endpoints away from published page slugs.
 * Adjust the target paths below to any non-colliding URLs you prefer.
 */
add_filter( 'royal_mcp_oauth_rewrite_paths', function( $paths ) {
    $paths['register']  = 'royal-mcp-oauth/register';
    $paths['authorize'] = 'royal-mcp-oauth/authorize';
    $paths['token']     = 'royal-mcp-oauth/token';
    return $paths;
} );

You only need to relocate the slugs that actually collide. If only /register is a problem, keep authorize and token at their default paths (delete those two lines).

Path choice guidance

Any URL-safe string works. Nested paths like royal-mcp-oauth/register are common because they’re unlikely to collide with anything else and they self-document. You can also use rmcp-register, oauth/register, or any other convention. Just make sure the new paths don’t collide with any OTHER published pages on your site.

Step 3 — Re-save Permalinks to flush rewrite rules

Go to WP Admin → Settings → Permalinks and click Save Changes. This registers the new paths as active rewrite rules.

Step 4 — Confirm the new discovery document

Run:

curl -s https://your-site.com/.well-known/oauth-authorization-server

The response JSON should now show your relocated paths in authorization_endpoint, token_endpoint, and registration_endpoint. Claude.ai and other MCP clients read this metadata every time they connect, so they’ll automatically use the new paths — you don’t need to reconfigure anything on the client side.

Alternative: delete the shadowing page

If the overlapping page is a leftover from a plugin you’ve since removed, or one you created but never used, the simplest fix is to delete it. Trash the page in WP Admin → Pages, then re-save Permalinks to flush the rewrite. Royal MCP’s OAuth endpoints will then own the slugs cleanly with no filter needed.

Verify the Fix Worked

Confirm the discovery curl from Step 4 shows the relocated paths
In WordPress admin, go to WP Admin → Royal MCP → Settings and save the form (this invalidates the 12-hour self-check transient so the notice refreshes immediately)
Reload any Royal MCP admin page — the “OAuth endpoints overlap with existing pages” notice should no longer appear
Try loading your membership plugin’s /register page in an incognito window — the registration form should render and submit as before, with no interference from Royal MCP
Reconnect Claude.ai (or whichever MCP client was failing) — the OAuth handshake should now complete against the relocated endpoint

Still Stuck? Two Support Paths

If you’ve added the filter, flushed Permalinks, and the collision persists (or Claude.ai still fails to connect):

Community Support (free) — wp.org Plugin Forum

Post a new thread at wordpress.org/support/plugin/royal-mcp/. The Royal Plugins team monitors the forum regularly.

Premium Support (paid)

For direct one-on-one help with 24-hour SLA, see Premium Support ($149/year).

Information to include (either path)

The full curl -s output for /.well-known/oauth-authorization-server
Which page slugs the admin notice reported as shadowed
The membership or community plugin creating the shadowing page (MemberPress, PMP, Ultimate Member, BuddyBoss, etc.)
The contents of your mu-plugins/royal-mcp-oauth-relocate.php file (or note if you chose to delete the shadowing page instead)
Royal MCP version