Why shipping an MCP server in your WordPress plugin is the AI move that survives

#Why shipping an MCP server in your WordPress plugin is the AI move that survives

Two data points from one week, May 2026.

Metorik founder Bryce Adams on WP Product Talk: the company’s new MCP integration drew 500 users within days of a quiet preview launch, faster adoption than any feature he has shipped in ten years. Same conversation, same Adams: customers who churn out of Metorik have an average MRR 40 percent lower than customers who stay. He read this as AI taking the commodity use cases (basic reports, simple dashboards) and leaving the core analytical work alone.

GravityKit open-sourced Block MCP this week. It is a WordPress MCP server that operates at the block level rather than treating post content as a single HTML string. The team built it because existing REST-API-based MCP servers strip the block delimiters that WordPress uses to identify blocks, collapsing structured content into a Classic block. They had hit the bug enough times on their own site to commit to a fix.

These are not two stories. They are one story. In 2026, the WordPress plugin that ships an MCP server is the plugin that compounds. The plugin that bolts a chat box into its admin is the plugin that gets cannibalised.

This piece is the continuation of our AI implementation pillar and connects directly to our work on MCP server development and the WordPress 7.0 Abilities API integration story. The argument here is commercial, not just technical.

#TL;DR

• Two May 2026 data points say the same thing. Metorik MCP: 500 users in days, fastest adoption in ten years. Adams: churning customers’ MRR is 40 percent lower than retained, suggesting AI takes commodity use cases. GravityKit Block MCP: open source, fixes the REST-API block-delimiter-stripping bug.
• An MCP server exposes the plugin’s domain operations as agent-callable tools that compose into the user’s agent of choice. A chat box trapped in the plugin admin composes only with itself.
• The plugin’s commodity layer (reports, dashboards, chart variants) gets cannibalised by generic AI tools that can answer the same questions from raw data. The plugin’s deep domain layer (custom attribution, cohort math, integration plumbing) survives because the AI does not have the domain context unless the plugin gives it via MCP.
• The MCP server’s contract lives in the plugin repository. That contract is stable across model releases. A chat box trained against a specific model provider’s behaviour shifts under the maintainer every six weeks.
• Action: ship an MCP server, expose three to seven domain operations as tools, document the contract in the repo, version the MCP surface separately from the plugin UI version.

#The natural experiment Adams ran

Adams said on WP Product Talk that he was nervous about AI for the same reason every plugin author is nervous about AI in 2026: the bottom of the value pyramid (basic reports, simple aggregations) is exactly where AI is fastest at copying. He could imagine a world where Claude or ChatGPT, pointed at the same Shopify or WooCommerce raw data, produces the same charts Metorik produces, for free.

What he found instead, after a year of watching, was that the customers leaving Metorik were systematically the low-MRR ones. Average MRR of churners 40 percent below retained. His interpretation: the AI did exactly what he feared at the bottom of the pyramid, and exactly nothing at the top.

This is a natural experiment because Adams did not design it. It happened to him while the market shifted. The data tells you which functions Metorik provides are commodity (gone to AI) and which are durable (Metorik retains the customer). Adams listed retained-customer use cases as: ad spend attribution, cohort math, custom segmentation, integration with stock and fulfilment APIs, multi-store aggregation. These are not chart functions. They are domain operations that require Metorik’s specific implementation, against the specific data shape it has earned over a decade.

Then the MCP integration shipped, and 500 retained customers reached for it inside the first week.

The MCP integration is not a new product feature. It is a way for the customer’s agent (Claude Desktop, Claude Code, ChatGPT Enterprise, a custom internal stack) to call those same retained-customer domain operations as tools. The customer now does in their agent what they used to do by logging into Metorik. Metorik did not lose them, it became invisible plumbing under their agent workflow.

That is the moat.

#Why Block MCP matters more than its plugin shape suggests

GravityKit’s Block MCP is technically a small plugin. A WordPress MCP server, exposing block-level editing as tools. The reason it matters is that it identifies the failure mode of every previous WordPress MCP attempt.

Existing WordPress MCP servers (and there are several) write through the WordPress REST API. The REST API treats content as a single HTML string. WordPress internally uses HTML comments as block delimiters (<!-- wp:paragraph -->, <!-- wp:image {...} -->). When the agent edits the content string and writes it back, the block delimiter comments survive only if the agent knows about them. Most agents do not. The HTML round-trip strips the delimiters. The post that was a structured stack of twenty blocks becomes a single Classic block on save.

This is not a hypothetical. GravityKit’s strategic ops manager Casey Burridge said the team hit the bug repeatedly on their own site. Anyone who has tried to build a content-editing agent against the WordPress REST API has hit it.

Block MCP fixes the failure mode by exposing block-level operations as MCP tools. add_block, update_block, move_block, delete_block, instead of get_content plus set_content. The agent sees the post as a tree, not a string. The contract is stable across the WordPress block updates because the contract is defined in the MCP server, not in whatever HTML serialiser the WordPress core happens to ship today.

The deeper point: the difference between “MCP wrapped around REST” and “MCP designed around the domain” is the difference between commodity tooling and a durable surface. Block MCP is the first WordPress MCP server to operate at the domain layer (blocks are the domain primitive of WordPress content) rather than the API transport layer.

This is the pattern. Every plugin author should ask: what is the domain primitive of my plugin, and is my MCP server exposing it, or is it exposing a wrapped REST endpoint?

#What an MCP server is, in two paragraphs

The Model Context Protocol is an open standard from Anthropic for how AI agents discover and call tools. An MCP server exposes a list of tools (each with a name, a description, a JSON schema for inputs, and an implementation), and any MCP-capable agent (Claude Desktop, Claude Code, ChatGPT Enterprise, custom stacks) can connect to it, discover the tools, and call them. The server can be local (stdio), or remote (SSE / HTTP). For a WordPress plugin, the local case is the right shape: the server runs alongside the plugin, the agent connects from the user’s machine.

The plugin author defines the tools. This is the entire point. The tools are the plugin’s domain operations, named in the plugin’s vocabulary, with input schemas that reflect the plugin’s data model. The agent now operates with the plugin’s level of domain knowledge. The customer does in chat what they used to do by clicking through five admin screens.

On our tech radar the Anthropic Model Context Protocol sits in the Adopt ring, WordPress Abilities API in Trial (the canonical integration surface in WordPress 7.0 and later), and we recently added wp-agentic-admin (CloudFest Hackathon 2026) in Assess as a reference implementation of the pattern.

#The two-by-two

The 2026 WordPress plugin lives in a two-by-two:

The shallow-domain quadrant (top row) is where most “WordPress AI plugin” launches sit. They wrap a thin layer of basic functionality (CSV export, simple charts, content rewrite suggestions) and either add a chat box or no MCP at all. Both columns are dead ends. The chat box trains user habits against the plugin’s commodity surface, and the MCP server has nothing differentiated to expose.

The deep-domain quadrant (bottom row) is where the durable plugins live. Metorik, Crocoblock’s JetEngine, GravityForms, GravityKit’s GravityView, are each examples. Without MCP, these plugins retain customers but become invisible to agent workflows. With MCP, they compose into agent workflows and become the indispensable plumbing.

The interesting question for a plugin author in this quadrant is not “should we ship MCP” (yes), it is “which three to seven operations are the right ones to expose.”

#Choosing the operations to expose

Plugin authors often want to expose every CRUD endpoint as MCP tools. This is wrong. The point of MCP is not API access, it is domain-level operations. A long list of trivial tools confuses the agent and produces low-quality calls. A short list of meaningful operations is what makes the agent useful.

The heuristic we use:

1. List the actions a customer takes in your plugin in a typical week. Order by frequency.
2. Group them into clusters of related actions. For Metorik, one cluster might be “ad attribution queries”, another “cohort segmentation”.
3. For each cluster, define a single MCP tool that takes the cluster’s parameters and returns the cluster’s result. The tool is the domain operation, not the API endpoint.
4. Cap the list at seven. If you have more than seven, you have not finished the clustering.
5. Each tool gets a one-paragraph description in the MCP server. The description is what the agent reads to decide when to use it. Optimise for the agent’s reading, not for human documentation completeness.

A plugin author who follows this gets an MCP surface with five to seven tools, each meaningful, each retained-customer-relevant. The agent reads the descriptions and chooses correctly. The customer’s daily workflow now includes the plugin’s domain operations as natural language requests.

#The contract lives in the repository

This is the part of the argument most plugin authors miss when they reach for “let us add Claude to our admin” first.

A chat box bolted into the plugin admin has a contract that lives in the chat box’s prompt, system message, and tool-calling layer. When the underlying model provider changes the function-calling format (this has happened three times in the past 18 months across Anthropic, OpenAI, and Google), the chat box breaks until the maintainer updates the wrapper. The chat box’s contract is not durable. Its lifecycle is the model provider’s API.

An MCP server’s contract lives in the plugin repository as a JSON schema per tool. The contract is stable across model releases. When Anthropic updates Claude’s tool-calling, the agent updates, not the MCP server. When OpenAI ships a new function-calling shape, the same MCP server still works because MCP is the standard the model provider adapts to. The plugin author writes the tools once and ships them.

This is the durable engineering shape. The chat box is the disposable one.

The customer notices this on a multi-year horizon. The chat box that worked in 2025 broke twice in 2026. The MCP server that shipped in 2025 still works in 2026 with the customer’s current agent of choice. The customer trusts the plugin that ships the durable surface.

#Counter-position: what about wp-agentic-admin?

A reader looking at the CloudFest Hackathon 2026 wp-agentic-admin project will see a different model: an in-browser WebLLM (Qwen 1.7B or 7B via WebGPU) running entirely on the user’s device, calling the WordPress Abilities API through a ReAct loop. Local-first, no API cost, no remote model.

That model has a place. It is a great fit for the single-tenant, hobbyist, or privacy-paranoid WordPress admin who wants to triage their own site with no external dependency. It is not the durable answer for plugins serving B2B teams who already run Claude Enterprise, ChatGPT Enterprise, or self-hosted agent stacks across all their internal workflows.

For those teams, the agent they want to talk to the WordPress plugin from is the same agent they use for their CRM, their data warehouse, their issue tracker, and their docs. The MCP server is what makes the plugin available to that agent. The in-browser WebLLM is a parallel universe with no compositional reach.

Both models are valid. The MCP server pattern is the one that aligns with how B2B customer teams already work.

#What this means for the wppoland reader

If you ship a WordPress or WooCommerce plugin: build the MCP server. Three to seven domain operations, exposed as tools, contract in the repository, versioned separately from the plugin UI. Do this before adding a chat box. If you can only do one, do the MCP server.

If you operate a WordPress site at scale (multi-site, agency, enterprise): when evaluating plugins for adoption, ask “does it ship an MCP server” the way you used to ask “does it have a REST API.” The MCP question is the 2026 equivalent.

If you are a wppoland customer evaluating where to invest engineering effort in 2026: this is where we suggest investing. We build custom Claude skills and MCP servers for B2B teams running agent-first workflows on WordPress. The deliverable is the MCP server, the domain tools, the contract, and the team’s onboarding. The deliverable is not a chat box.

#Closing argument

The May 2026 Metorik data point and the Block MCP open-source release are the same signal at different scales. The plugin that exposes its domain operations as MCP tools compounds with whichever agent its customer adopts. The plugin that does not gets cannibalised at the commodity layer and stays invisible at the domain layer.

There is a small operational window in 2026 to ship MCP before the market expects every plugin to have it. Plugin authors who reach for the MCP surface this year are the ones who will be on the agent integrator’s allow-list when the market catches up.

#Sources

• Bryce Adams on WP Product Talk (transcript via WP Product Talk)
• Metorik MCP integration documentation
• GravityKit Block MCP open-source release
• Anthropic Model Context Protocol
• Crocoblock JetEngine 8-year retrospective and MCP Command Center

#Related on this site

• Pillar: AI implementation consultancy
• MCP server development
• WordPress 7.0 features: AI infrastructure and Abilities API summary
• Tech Radar: Anthropic MCP (Adopt)
• Tech Radar: WordPress Abilities API (Trial)
• Tech Radar: wp-agentic-admin (Assess)

Last updated: 2026-05-23