Migrating Custom Code That Assumed MCP Adapter Was Core

This lesson exists directly because of the same false claim this course corrected in Lesson 1: that the MCP Adapter shipped in WordPress core. If any of your own code, onboarding documentation, deployment scripts, or plugin activation logic was written on that assumption, the effect isn’t cosmetic, it’s a plugin that silently fails on sites where the MCP Adapter genuinely isn’t installed, because nothing ever checked.

Step 1: Recognize the mistake in code

The tell is code that calls into the MCP Adapter’s classes or functions with no guard at all, as though the adapter were guaranteed to be present the way a core function is:

// File: my-plugin.php (the mistake)
add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'my-plugin/example', array( /* ... */ ) );

	// Wrong: assumes the MCP Adapter is always present, like a core function would be.
	$adapter = WP\MCP\Core\McpAdapter::instance();
	$adapter->register_server( /* ... */ );
} );

If the MCP Adapter plugin isn’t installed and active on a given site, that second line is a fatal error: “Class WP\MCP\Core\McpAdapter not found.” Contrast that with a call to a genuinely core function like wp_register_ability(), which is safe on any 6.9+ site with zero additional installation.

Step 2: Fix the detection

The MCP Adapter’s own codebase doesn’t publish a dedicated function_exists() helper or constant for this, the standard, working approach is a class_exists() check against its actual namespace:

// File: my-plugin.php (corrected)
add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'my-plugin/example', array( /* ... */ ) );
} );

add_action( 'plugins_loaded', function () {
	if ( ! class_exists( 'WP\MCP\Core\McpAdapter' ) ) {
		add_action( 'admin_notices', function () {
			echo '<div class="notice notice-warning"><p>';
			esc_html_e( 'My Plugin registers WordPress abilities, but the MCP Adapter plugin is not active, so they will not be reachable by external AI agents. Install it separately to enable that.', 'my-plugin' );
			echo '</p></div>';
		} );
		return;
	}

	$adapter = WP\MCP\Core\McpAdapter::instance();
	$adapter->register_server( /* ... */ );
}, 20 );

Notice the ability registration itself moved out from behind this check entirely. Registering an ability is valuable on its own, your own code and other plugins can still call it via wp_get_ability(), regardless of whether the MCP Adapter is present. Only the code that actually talks to the adapter’s classes needs the guard.

Step 3: Audit deployment scripts and CI

If your deployment pipeline, wp-env config, or staging setup scripts don’t include an explicit MCP Adapter install step, and were written assuming “core AI features” covered it, add that step back explicitly:

# File: deploy.sh
wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

Or, if your project manages dependencies through Composer instead of plugin installs:

composer require wordpress/mcp-adapter

Check your CI test suite the same way, if integration tests exercise MCP-served abilities, confirm the test environment actually installs the adapter rather than relying on some other job having left it behind from a previous run.

Step 4: Audit your own documentation

Search your plugin’s readme, internal wiki, or onboarding docs for language that implies the adapter needs no separate install:

grep -rin "mcp adapter" --include="*.md" --include="*.txt" .

Test it: simulate the adapter being absent

Deactivate the MCP Adapter plugin temporarily on a test site and confirm your plugin degrades the way Step 2’s fix intends, rather than fatally erroring:

wp plugin deactivate mcp-adapter
wp eval 'var_dump( function_exists( "wp_register_ability" ) ); var_dump( wp_get_ability( "my-plugin/example" ) );'

Both calls should succeed even with the adapter deactivated, since ability registration itself never depended on it. Reactivate afterward:

wp plugin activate mcp-adapter

Recap

Code, deployment scripts, and documentation that assumed the MCP Adapter needed no separate install are a direct consequence of the same false premise this course opened by correcting. Guard every direct call into the adapter’s classes with class_exists( 'WP\MCP\Core\McpAdapter' ), keep ability registration itself outside that guard since it doesn’t need the adapter at all, make the plugin install step explicit again in deployment scripts, and grep your own docs for the same mistake before calling this migration finished.

Resources & further reading

• MCP Adapter repository, GitHub
• Abilities API reference, developer.wordpress.org
• Abilities API in WordPress 6.9, make.wordpress.org