MCP OAuth: Add a filter to disable the OAuth server entirely

[MathieuLamiot]

Context

WP Rocket now ships a full MCP OAuth 2.1 server (rewrite-routed endpoints for /oauth/authorize, /oauth/authorize-callback, /oauth/token, /oauth/consent, /oauth/revoke, plus the /.well-known discovery documents), wired up in WP_Rocket\Engine\MCP\Auth\Subscriber (inc/Engine/MCP/Auth/Subscriber.php) and WP_Rocket\Engine\MCP\Transport\Subscriber (inc/Engine/MCP/Transport/Subscriber.php).

There is currently no WordPress filter to disable the OAuth server entirely. Subscriber::register_oauth_rewrite_rules() and Subscriber::handle_oauth_request() always run unconditionally on init / template_redirect — confirmed by searching the codebase: there are zero apply_filters() calls anywhere under inc/Engine/MCP/.

Some site owners, agencies, or security-conscious environments may want to fully turn off the MCP OAuth surface (endpoints, rewrite rules, discovery documents) without needing a code release or manually unhooking the subscriber.

Goal

Add a single boolean filter that gates the entire MCP OAuth server, checked early enough to prevent rewrite-rule registration and request handling when disabled.

⚠️ Use the WP Media "apply_filter_typed" function with the correct type.

/**
 * Filters whether the MCP OAuth server is enabled.
 *
 * When `false`, WP Rocket does not register the OAuth rewrite rules or
 * respond to any /oauth/* endpoint or /.well-known discovery request.
 *
 * @param bool $enabled Whether the MCP OAuth server is enabled. Default true.
 */
$enabled = (bool) apply_filters( 'rocket_mcp_oauth_server_enabled', true );

• Default: true (no behaviour change out of the box).
• When false:
  • Subscriber::register_oauth_rewrite_rules() should no-op (no rewrite rules registered/flushed).
  • Subscriber::handle_oauth_request() should no-op (fall through to WordPress's normal 404 handling rather than dispatching to any endpoint handler).
  • The MCP discovery/well-known documents and the /wp-json/mcp/mcp-oauth-server transport (see WP_Rocket\Engine\MCP\Transport\Subscriber) should likewise be suppressed — needs investigation as part of this issue to confirm the exact gating points in inc/Engine/MCP/Transport/.
• This is distinct from the rocket_mcp_allow_untrusted_providers / rocket_mcp_trusted_publishers filters (see #8553 and #8554), which control who can connect once the server is enabled. This filter controls whether the server exists at all.

Acceptance criteria

• rocket_mcp_oauth_server_enabled filter is documented (inline docblock at the point it's applied).
• Default behaviour (filter not used) is unchanged: OAuth server fully functional.
• When filtered to false: no OAuth rewrite rules are registered, all /oauth/* requests fall through to normal WordPress 404 handling, and the MCP transport/discovery endpoints are also disabled.
• Existing activation/deactivation flows (on_activation() / on_deactivation() in inc/Engine/MCP/Auth/Subscriber.php) behave sanely when the filter is false (no dangling rewrite rules left registered).
• Unit/integration test coverage for both the enabled (default) and disabled (filtered) states.

Related

• #8553 — MCP OAuth: Make the trusted-publisher allowlist extensible via a filter
• #8554 — MCP OAuth: Two-tier consent — allow any verified-CIMD client, show warning for unverified