When you connect an AI agent to your WordPress site, the interesting question is not how many tools it has. It is whether you can trust the ones it uses. Reliable MCP tools for WordPress come down to a simple promise: when the agent calls a tool, the call reaches the real library underneath, and when the tool reports success, something actually changed. A tool that misses either half of that promise is worse than no tool at all, because it fails quietly and you find out later. The 1.3.1 release is about closing both gaps.
Why an agent’s tools are only as trustworthy as the code they call
An MCP tool is a thin layer. It takes a request from the agent, translates it into a call against WooCommerce, Rank Math, AIOSEO, or ACF, and hands back a result. The agent has no way to know whether that translation is correct. It trusts the tool. So the reliability of the whole setup rests on one thing: does the plugin’s call match the function the real library exposes, in the shape the library expects. If that assumption drifts, the tool keeps looking healthy while returning nothing useful.
The failure this fixes: calls that do not match the real library
This is not a hypothetical worry. In earlier releases the plugin called a WooCommerce function that WooCommerce does not have, so customer listing returned zero on every real store. In another case it assumed a single schema for a WooCommerce product attribute that can take more than one form. Both are the same class of bug, an API-shape regression, where the plugin’s idea of the library and the real library quietly disagree. You can read what that clean up looked like in the 1.3.0 security release. The point of 1.3.1 is to stop that class of bug from reaching you in the first place.
Contract tests against real WooCommerce, Rank Math, AIOSEO, and ACF code
The 1.3.1 release adds a real-vendor contract test suite. A contract test here checks one thing: that the plugin’s calls match the shape the vendor library actually accepts. Instead of testing the plugin’s tools against a mock or a hand-written stand-in for how we think WooCommerce behaves, the suite runs against pinned copies of the actual WooCommerce, Rank Math, AIOSEO, and ACF plugin code. The test calls the tool the way the agent would, and the vendor code answers the way it really answers. If the plugin reaches for a function that does not exist, or passes an attribute in a shape the library rejects, the test fails. That is the whole idea: let real code, not our assumptions, be the judge. These are the same WooCommerce, Rank Math, AIOSEO, and ACF integrations the tools sit on top of, so the tests track exactly what ships.
Catching API-shape regressions before release, not after
Pinning the vendor code matters for a second reason. When a new WooCommerce version changes a function signature or an attribute schema, updating the pinned code surfaces that change on our side during development, before it reaches your site. A regression that used to be discovered on a live store, after the agent had already returned empty results to someone, now shows up as a red test during development. The failure moves from your production data back to our build, which is where it belongs.
A write you can trust is a write that actually took effect
Reading is only half of it. The harder half is writing, because a write can report success and still leave the value unchanged. WordPress will sometimes accept a call, decide the value is invalid, and silently revert it. If the tool assumes the write took effect, it tells the agent everything is fine, and the agent tells you. That is exactly the kind of confident, wrong answer that erodes trust in agent tools.
Write verification in practice
So 1.3.1 verifies each write by reading back what actually got stored and comparing it to what the tool tried to set. Saving a payment gateway is now checked against the value WooCommerce really holds afterward, rather than assuming the save worked. The update-site-settings tool reports failure when WordPress silently reverts a value it considers invalid, instead of reporting a change that never happened. AIOSEO verification was tuned in the other direction too: it no longer reports failure when AIOSEO applies its own benign normalization to a saved value, because a legitimate tidy-up is not a failed write. And rankmath-get-head now returns a clear error when Rank Math’s head renderer is not available, rather than an empty success that looks like a real answer. In each case the tool reports what actually happened.
Graceful degradation when WooCommerce is below 9.1
The WooCommerce tools now require WooCommerce 9.1 or newer. On an older store they simply do not register, and the Integrations screen shows a clear reason why. There is no fatal error and no half-working tool that fails in surprising ways. If the environment cannot support a reliable tool, the honest move is to not offer it, and say so.
How this ties back to a governed, audited server
None of this replaces the governance model, it reinforces it. The plugin already gives you a governed, audited MCP server where tools are off by default and least privilege, and where every call is logged. Contract tests and write verification make that audit trustworthy, because a log of tool calls only means something if each call did what it claims. You can read more about the boundaries in our security model. If you are running the plugin, updating to 1.3.1 is a quiet upgrade with no new surface to configure. It makes the tools you already rely on a little more worth relying on.