Fourteen years of watching WordPress grow from a blogging tool into an application framework has left me suspicious of the word “AI” in this ecosystem. It usually means a bloated plugin with a subscription attached. The latest batch of WordPress AI Experiments from the Core AI team reads differently. Text generation is the least of it. The work is about how WordPress talks to an LLM in the first place.
The team put out a Call for Testing covering several new concepts in the AI Experiments plugin, including Model Context Protocol (MCP) support and native AI request logging. If you build on WordPress and care about performance or about standardizing how these tools get used, it is worth a look.
Why these WordPress AI Experiments matter
The user-facing pieces, type-ahead suggestions and the like, are pleasant but shallow. The developer tooling is where the interesting work sits: the Model Context Protocol (MCP) integration and the standardized AI Building Blocks.
The Markdown Feeds experiment is the one I keep thinking about. Request a post as text/markdown and WordPress starts cooperating with external AI agents and static site generators without a REST API handshake every single time.
MCP and request logging
Debugging a race condition inside an AI-powered block is miserable work, which is why the AI Request Logging experiment matters more than its name suggests. It records provider data, token counts and cost estimates. Shipping an AI feature to production without that visibility is guesswork.
The MCP integration turns WordPress into a server for assistants like Claude Desktop or Cursor, so your editor gets direct, secure access to the site’s abilities. That is the Abilities API doing its job, and it replaces hand-rolled prompts with structured tool calls.
How to test the extended providers
Another experiment widens the provider list to include Groq, DeepSeek and others through the WP AI Client SDK, which I covered in an earlier post on standardizing generative AI. The point is to make the model swappable through a filter instead of locking a site to one vendor.
<?php
/**
* Conceptual example: Filtering AI Provider Options
* This reflects the logic being explored in the Extended Providers experiment.
*/
function bbioon_customize_ai_providers( $providers ) {
// Add a local Ollama instance for testing privacy-focused workflows
$providers['local-ollama'] = [
'label' => 'Local Ollama',
'endpoint' => 'http://localhost:11434/v1',
'type' => 'openai-compatible',
];
return $providers;
}
add_filter( 'wp_ai_providers', 'bbioon_customize_ai_providers' );
A $400 lesson in unlogged AI requests
A client of mine once added a basic “AI content improver” with no request logging and no transients. A bot crawled the site, fired the AI hook on every page load, and left a $400 API bill after four hours. That is why the Request Logging and Purge Logs work in these WordPress AI Experiments is a requirement rather than a convenience once you build at any real scale.
If this kind of AI plumbing is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days and I know where the bottlenecks hide.
How to get involved
You can try all of this today in WordPress Playground, with no local staging site and nothing pointed at your production database. Grab the plugin from the WordPress AI GitHub repository and leave feedback on the PRs. The core team does read it, and they read it most closely when it comes from people cleaning up real client sites.
