If a WP Rocket MCP connection stopped working after the 3.24 update, first check whether the standalone WordPress MCP Adapter is installed and active. A missing adapter is different from a broken cache, an OAuth discovery conflict or a denied tool operation. Fix the connection stage that fails, not every stage at once.
What changed in this release?
The WP Rocket changelog records the move to the standalone MCP Adapter. The migration implementation removes the bundled adapter dependency and conditions MCP OAuth startup on an adapter being loaded. Existing users may see an administrative installation notice, but not every connection history produces that notice.
Do not assume that dismissing a message repairs the dependency. Do not downgrade a security-updated plugin just to restore a bundled component. Start with the vendor-supported setup and check the site identity before connecting an external client.
Inventory the connection without exposing credentials
Record the WordPress and WP Rocket versions, adapter plugin version and activation status, intended client, intended account and transport. Distinguish staging from production in your notes. Confirm whether the client previously used OAuth or a local command-line connection; a successful local tool does not prove a remote flow works.
Use the plugin list or the hosting administrator's approved tooling. Inspect the official MCP Adapter plugin listing before installing or updating the dependency. Avoid packages with similar names from an unrelated download site. Adding an adapter should follow the site's normal change process, with a backup and a staging check.
Do not include client secrets, refresh tokens, application passwords or authorization headers in screenshots. A support request normally needs the error stage and redacted response, not a reusable credential.
The client, authorization, standalone adapter and WP Rocket abilities are separate connection checkpoints. Explanatory example, not a customer test.
Work through four checkpoints
- Adapter loading: confirm the intended adapter is active and no load-time PHP error appears. A plugin folder on disk is not proof that it loaded.
- Discovery: inspect the exact public discovery URL shown by setup. Check status, content type and redirects. A homepage returned with status 200 is not the expected discovery document.
- Authorization: use the existing supported account and authorization flow. A denial is not permission to give the client an administrator account.
- Tool execution: confirm that the expected WP Rocket abilities are visible, then start with a read-only status operation if the client exposes one.
Stop at the first failing checkpoint. If the adapter is absent, rewriting .well-known rules is premature. If discovery succeeds but a specific tool is denied, replacing the discovery document will not address that authorization boundary.
Keep cache actions bounded
An AI client that can connect may still target the wrong site. Verify the hostname returned or shown by the client before any write operation. If a cache purge is part of the approved test, use one disposable staging page instead of clearing the whole production cache.
Keep an explicit record of the requested tool, its input and the observed result. A full cache clear can generate substantial origin work during warm-up. Do not use it as a harmless handshake. Confirm that the client cannot perform unapproved changes simply because one permitted operation succeeded.
What if there is no notice?
The notice is not a complete inventory of every MCP user. The migration discussion specifically distinguishes local command-line connections from connection metadata used to display notices. Check dependency state directly rather than manufacturing session records or changing user metadata to force the message to appear.
If the adapter is active and discovery still fails, continue with the existing WP Rocket .well-known troubleshooting guide. Keep unrelated certificate and authentication routes intact. There is no reason to delete the entire .well-known directory.
Close the migration with evidence
Confirm normal page caching separately from MCP. Retest the intended connection after a fresh client session, save the tested versions, and remove temporary diagnostics. HandL WP support can review the dependency and routing chain without treating broader permissions as the default solution.
Sources reviewed October 31, 2026. The suggested checks and diagrams are diagnostic aids, not claims of tests performed on your site.