If an AI client can read a WooCommerce product but cannot see a field supplied by an extension, first check whether that extension exposes the field through the ability being called. Database storage alone does not establish an API contract. WooCommerce's announced 11.3 extensible-abilities feature is a new testing path, not a switch that automatically exposes every plugin's private metadata.
Know What Is Experimental
The October 22 call for testing describes an experimental feature that is off by default. With it disabled, the new hooks do not run. Registered read fields appear under extensions, grouped by namespace, and are added to the output schema. The announcement covers product, order and order-item reads, product create/update inputs, validators and extension query filters. Do not infer equivalent order-write support from product examples.
Use a staging build that actually contains the announced feature. Record its version and the extension build being tested. As of the October 25 release check, 11.2.1 remains the stable WooCommerce release. A feature missing from an older build is not proof that an installed extension is broken.
Locate the Missing Layer
Start with a synthetic product whose extension data you can inspect in its normal admin screen. Record the object ID and the intended business meaning of the field. For example, an optional packaging surcharge might distinguish unavailable, free and chargeable service. Those are not interchangeable states.
Ask the extension developer for its resource name, namespace, field name, supported operation and expected value type. Compare that contract with the actual discovered schema and returned object. Do not invent a namespace from the plugin folder name or send guessed metadata keys to a write operation.
| Observation |
Next question |
| Field absent from schema and output |
Did registration run for this resource and build? |
| Schema includes field, output omits it |
Does the getter return the expected state for this object? |
| Output includes field, client hides it |
Does the client retain the nested extension object? |
| Read succeeds, write rejected |
Is the operation supported and input valid? |
| Write reports success, value unchanged |
What does a fresh independent read show? |
Check the field in schema, output, input and persistence. A missing value is not automatically zero. Explanatory diagram, not a customer test.
This worksheet is a diagnostic sequence, not proof that the experimental API has a defect. Run the same request directly through the approved integration test harness and through the AI client. A difference between those outputs can identify client-side parsing or stale tool discovery.
Test Absent, Null and Zero Separately
Create three disposable fixtures: a product without the optional setting, a product with an explicit zero value and a product with a positive value. Only add a null case if the extension's published schema permits it. Document what each state means before testing.
Inspect the raw JSON value and the user-facing interpretation. An assistant must not turn an absent field into zero and tell a customer a service is free. Likewise, a string that looks numeric should not silently become a valid amount unless the contract supports that conversion.
For a query filter, compare the returned IDs with your small fixture list. Test both boolean directions where supported and a request without the filter. Avoid benchmarking correctness against a production catalog with thousands of uncontrolled values. A two-product counterexample is easier to debug than a large export with uncertain expectations.
Verify Rejection Without Partial Changes
The announced validator path can reject a product change before saving. Test that behavior with a developer-approved invalid combination on staging. Include a harmless ordinary product-field change in the same request, then inspect both the ordinary field and extension value afterward. Neither should change when the validator rejects the operation.
Record the response error and the fresh stored values. Also inspect any external effects your extension initiates, such as a remote inventory request. A single object save is not a promise that every external system participates in a database transaction. Keep tests isolated from real fulfillment, payments and notifications.
Then submit a valid combination and confirm the intended values persist after a fresh read. Repeat using the intended low-privilege user. Do not make an assistant an administrator simply to get a green result. The abilities extension audit helps assign ownership and data scope before connecting more tools.
Decide Whether to Enable It
Keep the experimental feature disabled in production until your extension, client and access tests pass for the version you plan to deploy. Retain the prior configuration and document how to turn off the integration if the contract changes. A future release may change experimental behavior, so keep the fixture matrix with the integration's tests.
For connection failures, begin with the MCP setup checklist; an absent field after a successful read is a different problem. HandL WP can help trace the field contract from the extension through the ability response and client display, using synthetic records instead of customer data.
References checked October 25, 2026. Diagnostic recipes are not claims of a test on your installation.