Imunify360 Blocks Royal MCP OAuth Discovery

Symptoms

You’re hitting this specific issue if all of the following are true:

How to Confirm It’s Imunify360

A 30-second curl test will leave no doubt. Run from any terminal — replace example.com with your actual domain:

curl -i https://example.com/wp-json/royal-mcp/v1/mcp

{"message":"Access denied by Imunify360 bot-protection. IPs used for automation should be whitelisted"}

curl -i https://example.com/.well-known/oauth-authorization-server

curl -I https://example.com/

The Fix — Ask Your Host to Whitelist Royal MCP Paths

Imunify360 lives at the hosting provider’s layer, not inside WordPress. The fix is a support ticket to your host asking them to add specific paths to the Imunify360 allowlist for your domain. Most hosts complete this in under 24 hours — it’s a routine change on their end.

Ready-to-paste hosting-provider request

Copy the text below into a support ticket with your hosting provider. Substitute example.com with your actual domain:

Subject: Please whitelist OAuth paths from Imunify360 for example.com

Hi,

We’re running the Royal MCP WordPress plugin on example.com,
which lets AI assistants like Claude connect to our site via
the Model Context Protocol (MCP). The connection requires OAuth
2.0 discovery and token endpoints to be accessible without
bot-protection interference.

Right now Imunify360 is intercepting every request to /wp-json/*
and /.well-known/* with HTTP 200 and a JSON body:
"Access denied by Imunify360 bot-protection. IPs used for
automation should be whitelisted"

Please add the following URL paths for example.com to the
Imunify360 allowlist for our domain (or, equivalently, disable
Imunify360 bot-protection for these specific paths):

  /wp-json/*
  /.well-known/*
  /authorize
  /token
  /register

These are standard WordPress REST API + OAuth 2.0 (RFC 8414)
endpoints. Whitelisting them will not reduce security — they
are the plugin’s own authenticated endpoints and are subject
to WordPress’s standard capability checks.

Thanks in advance.

Alternative: cPanel Imunify360 UI (if your host gives you access)

Some cPanel hosts expose an Imunify360 admin UI directly to customers. If you have this, you can add the allowlist entries yourself:

1. Log into cPanel
2. Look for “Imunify360” or “ImunifyAV” in the Security section — typical labels are “Imunify360 Security Dashboard” or just “Imunify360”
3. Navigate to Settings → General → “Ignore List” or “Whitelist URLs” (exact wording varies by cPanel version)
4. Add each path pattern one at a time: /wp-json/*, /.well-known/*, /authorize, /token, /register
5. Save. Changes typically take effect within 60 seconds — no server restart needed.

Not every host exposes this UI to customers — many keep Imunify360 admin-only. If you can’t find it, go straight to the support-ticket approach above.

Retry Claude connection

Once your host confirms the allowlist is in place (or you’ve added it yourself via cPanel), the fix is immediate:

1. Re-run the curl test from the “How to Confirm” section above. You should now see the normal Royal MCP JSON-RPC response (or a proper OAuth metadata JSON for the /.well-known/ URL), not the Imunify360 denial.
2. In Claude, delete the existing Royal MCP connector if present, wait 30 seconds, then re-add it fresh. This forces the full OAuth flow from scratch rather than reusing cached failure state.
3. Complete the authorize consent screen. Royal MCP’s Activity Log should now show entries the moment you click “Authorize.”

What NOT to Try (WordPress-Side Fixes Won’t Help)

Imunify360 runs at the web-server layer, ahead of PHP. That means the following common troubleshooting steps will NOT resolve this issue — don’t waste time on them:

• Changing plugin settings. No Royal MCP setting can affect requests that never reach PHP. Same for other security or cache plugins.
• Deactivating other plugins. If Imunify360 is the block, no combination of active/inactive WordPress plugins will change the outcome.
• Adding .htaccess rewrite rules. Apache/LiteSpeed process .htaccess AFTER Imunify360 has already denied the request. Rules won’t fire.
• Switching to a default theme. Themes only render pages that WordPress successfully processes — irrelevant here.
• Whitelisting IPs in WordPress security plugins. Those plugins don’t see the request either. Only Imunify360’s allowlist matters.
• Uninstalling & reinstalling Royal MCP. The plugin is fine — the problem is upstream of WordPress.

What Royal MCP 1.4.36 Already Does for You

Royal MCP 1.4.36 detects this exact failure mode automatically. When the plugin’s well-known-endpoint self-check sees an HTTP 200 + JSON body containing “Imunify360,” it surfaces a dismissible admin notice on the Plugins screen and Royal MCP settings linking back to this page.

So future customers on Imunify360 hosts will land here from inside their own WordPress admin instead of having to search for “Royal MCP can’t connect” and stumble across the diagnosis. The plugin can’t auto-fix the block for you — Imunify360 is upstream of WordPress and the customer’s hosting-provider allowlist is the only mechanism — but the notice makes the diagnosis fast.

Related Issues You Might Also Be Hitting

Imunify360 is often deployed alongside other hosting-layer configurations that can independently block MCP. If your host is on shared cPanel + CloudLinux, check for these too:

Still Stuck? Two Support Paths

If your host completed the allowlist and Claude still can’t connect:

Community Support (free) — wp.org Plugin Forum

Post a new thread at wordpress.org/support/plugin/royal-mcp/. Include the diagnostic info listed below in your post.

Premium Support (paid) — direct one-on-one help

For priority response (24-hour SLA) and hands-on diagnostic help, our Premium Support tier is $149/year.