Empty {} / omitted parameters still fail in v0.5.0 for abilities WITH input schemas (follow-up to #116)

[pkhaninejad]

Description

#116 was closed as fixed in v0.5.0 via AbilityArgumentNormalizer, but the fix only covers abilities without an input schema. Abilities with an input schema (the exact case in #116's reproduction steps) still fail on v0.5.0 when called with empty {} parameters:

Ability "wds/get-posts" has invalid input. Reason: input is not of type object.

We reproduced this today in production on mcp-adapter v0.5.0 across two independent WordPress sites, for every registered ability that defines an input_schema (type object, all-optional or required properties alike).

Steps to Reproduce

1. Register an ability with an input_schema of type object (optional properties, no default key).
2. Call mcp-adapter-execute-ability with:

{
    "ability_name": "example/get-info",
    "parameters": {}
}

3. Expected: ability executes (no required properties).
4. Actual: Ability "example/get-info" has invalid input. Reason: input is not of type object.

Any non-empty parameters object (e.g. {"anything": true}) succeeds.

Evidence that the ability receives null, not []

AbilityArgumentNormalizer::normalize() only converts [] → null when the ability has no schema, and never converts null → [] when it has one. On v0.5.0 the inner ability demonstrably receives null:

We patched our plugin to add 'default' => array() to every ability's input_schema — and the failure disappeared on the same v0.5.0 install, with no other change. WP_Ability::normalize_input() only applies the schema default when input is null, and rest_validate_value_from_schema( array(), … ) passes — so the pre-patch failure must be rest_validate_value_from_schema( null, {type: object} ) → "input is not of type object".

So somewhere in the v0.5.0 execution chain, "parameters": {} (or an omitted parameters key — $input['parameters'] ?? null in ExecuteAbilityAbility::execute()) reaches WP_Ability::execute() as null for schema-defining abilities, and validation rejects it with the misleading type error.

Suggested fix

In AbilityArgumentNormalizer::normalize() (or ExecuteAbilityAbility::execute() / the tools handler), handle the inverse case as well: when the ability has an input schema and the arguments are null or an empty array, pass array() so it validates as an empty object. Roughly:

if ( ! empty( $input_schema ) && ( null === $parameters || array() === $parameters ) ) {
    return array();
}

This keeps strict rejection for abilities without schemas (current behavior) while letting zero-argument calls through for schema-defining abilities — which is what every MCP client sends for tools it believes take no arguments.

Workarounds

• Client side: always send a non-empty parameters object, e.g. {"refresh": true}.
• Ability side: add 'default' => array() to every registered input_schema (what we shipped).

Environment

• MCP Adapter: v0.5.0 (reproduced on two independent production sites)
• WordPress: 6.9 (core Abilities API — no standalone abilities-api plugin installed)
• Client: Claude (Desktop/Code) via MCP integration, calling the mcp-adapter-execute-ability tool

Related: #116 (same symptom, closed for v0.5.0), #75 (the no-schema half, fixed).

[galatanovidiu]

Thanks for the detailed writeup, the root-cause part helped a lot.

I tried hard to reproduce this and I can't get it to fail for an object schema.

What I tested:

• Your exact steps: mcp-adapter-execute-ability with parameters: {}.
• On the default server, over HTTP, through the MCP Inspector (same path as Claude Desktop).
• Also as the ability's own tool.
• On the v0.5.0 tag and on trunk.
• On WordPress 6.9 and 7.0.

All of them pass.

Why: {} becomes an empty array [] in PHP. WordPress treats [] as a valid empty object, so it passes. The ability gets [], not null.

The only case I can make fail is an ability whose schema type is not object (for example type: array). There, empty {} becomes null and gets
rejected with that same error. This fails on both v0.5.0 and trunk.

So maybe your failing abilities are not really type: object, or something on those two sites is different. Can you share:

1. The exact input_schema JSON of one failing ability (mainly the top-level "type").
2. If the client calls it as its own tool, or through mcp-adapter-execute-ability.
3. If you see it only on 0.5.0, or on trunk too.

With that I can match your setup and check the fix covers it.

[galatanovidiu]

Quick follow-up: I opened #230 with a fix.

It covers the non-object case I found, where empty {} reaches the ability as null and gets rejected. Now an empty call normalizes to an empty array, which validates fine. Object schemas keep working as before.

If you can, try that branch on one of your sites and see if it resolves what you're hitting. If it still fails, send me the exact input_schema array as you pass it to wp_register_ability() for one failing ability, and I'll match your setup.

[pkhaninejad]

Root cause found — it's not (only) the adapter, it's WooCommerce's bundled copy shadowing it.

We took #230's branch, built it with the v0.5.0 release vendor/ (schema DTOs bumped to v0.1.2 per the branch lockfile), and installed it on one of the affected production sites, replacing the existing plugin (verified active via the plugins API with a tagged version header). Empty {} still failed, while non-empty parameters succeeded.

Then we added a temporary diagnostic ability to dump ReflectionClass::getFileName() for the classes actually in use, and got the answer:

WP\MCP\Domain\Utils\AbilityArgumentNormalizer
  → wp-content/plugins/mcp-adapter/includes/Domain/Utils/AbilityArgumentNormalizer.php  (the PR branch ✓)

WP\MCP\Abilities\ExecuteAbilityAbility
  → wp-content/plugins/woocommerce/vendor/wordpress/mcp-adapter/includes/Abilities/ExecuteAbilityAbility.php  (!!)

WooCommerce (10.9.1) requires wordpress/mcp-adapter: ^0.3.0 and bundles it in its vendor/ dir. Both codebases autoload the WP\MCP\ namespace. On our sites, any class present in both resolves to WooCommerce's old copy; classes introduced later (like AbilityArgumentNormalizer, new in 0.5.0) fall through to the standalone plugin — a mixed-version load that made this miserable to trace.

The bundled old ExecuteAbilityAbility::execute() contains the actual bug we've been chasing:

$parameters = empty( $input['parameters'] ) ? null : $input['parameters'];

empty( array() ) is true, so {} becomes null, no normalizer is invoked (that call doesn't exist in the old version), and WP_Ability::execute( null ) fails validation with "input is not of type object". Current code fixed this with ?? null + the normalizer call — but that code never runs on a site where WooCommerce's copy wins.

Bonus mystery solved: the generic error we saw (An error occurred while executing the tool.) exists nowhere in this repo — it's in WooCommerce's bundled old Handlers/Tools/ToolsHandler.php. That's why you couldn't find our symptom in your codebase, and why you couldn't reproduce on stock installs.

Implications:

• fix: normalize empty input to empty array for schema-defining abilities #230 looks correct, but it can't fix WooCommerce sites by itself — the executing code is WooCommerce's vendored 0.3.x. Given how widely WooCommerce is deployed alongside this plugin, this collision is probably what a chunk of "works for me / fails for them" reports (incl. Empty object {} parameters fails InputValidator with "input is not of type object" #116?) reduce to.
• The adapter likely needs version-aware class loading (jetpack-autoloader style: register all copies, load the newest) and/or coordination with WooCommerce to bump or dedupe its bundle.
• Site-level workaround that survives even the WooCommerce path: 'default' => array() on every registered input_schema — core's WP_Ability::normalize_input() applies the schema default when input arrives as null. That's what we're keeping in production for now.

Environment: WP 6.9, WooCommerce 10.9.1, standalone mcp-adapter (v0.5.0 and #230's branch — both shadowed identically), PHP 8.x, reproduced on two independent production sites.

Happy to test any follow-up branch — we have a live reproduction harness ready.