Empty object {} parameters fails InputValidator with "input is not of type object"

[Middelthon]

Description

When calling an ability via MCP Adapter with an empty object {} as parameters, the InputValidator incorrectly rejects it with the error message "input er ikke av typen object" (Norwegian: "input is not of type object").

This happens despite {} being a valid JSON object that should pass validation for abilities with optional properties.

Steps to Reproduce

1. Register an ability with optional properties in input_schema:

wp_register_ability( 'example/get-info', array(
    'input_schema' => array(
        'type'       => 'object',
        'properties' => array(
            'fields' => array(
                'type'  => 'array',
                'items' => array( 'type' => 'string' ),
            ),
        ),
    ),
    // ... other config
) );

2. Call the ability with empty parameters:

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

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

Workaround

Passing any property value (even empty) works:

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

Environment

• MCP Adapter version: 0.4.1
• WordPress version: 6.9
• PHP version: 8.x
• MCP Client: Claude Desktop (via claude.ai MCP integration)

Analysis

The issue appears to be in the InputValidator logic that checks if the input is of type "object". An empty object {} should be considered a valid object, but the validator seems to be treating it as invalid (possibly checking for non-empty or using empty() which returns true for {}).

Related Issues

• Abilities with empty input_schema behave weirdly on different applications. #35 - Abilities with empty input_schema behave weirdly on different applications
• Relax parameter validation to allow some falsy values as parameters. #43 - Relax parameter validation to allow some falsy values as parameters
• Fix parameter handling for abilities without input schemas on ExecuteAbilityAbility #76 - Fix parameter handling for abilities without input schemas

Suggested Fix

The InputValidator should accept empty objects {} as valid when:

1. The schema type is "object"
2. There are no required properties
3. The input is actually an object (even if empty)

[backinpack]

I am experiencing the same issue. All POST requests work e.g. Create a new post/page but all GET requests e.g. list posts fail with the invalid input error message.

I have debugged the outputs and It looks like Claude is calling the MCP adapter with valid json but the input validator is mishandling the json parameters and not passing to the wp-abilities core.

[sanjayvala]

Hi, I’ve fixed the issue in the following fork. Could you please review it and let me know if you have any questions?
devsanjayvala@86a651f

✅ Issue
MCP client sends {} → PHP decodes it as []
Validator expects type: object → fails with:
"input is not of type object"
✅ Root Cause
In PHP:
{} → [] (empty array)
Empty array is treated as list, not object
✅ Fix
Updated AbilityArgumentNormalizer::normalize():
If:
input_schema.type === 'object'
AND params = empty array []
Then:
Convert to (object) [] (stdClass)
✅ Tests
Updated AbilityArgumentNormalizerTest.php to verify:
Empty params → stdClass (with schema)
Non-empty params unchanged
No schema → existing behavior preserved
✅ Result
{} handled correctly as object
Validation passes
Backward compatible

[galatanovidiu]

Thanks both for digging into this.

@backinpack, your debugging was spot on. The root cause was exactly what you identified: PHP decodes {} as [] (empty array), and the validator was rejecting it because it expected an object.

@sanjayvala, appreciate the fix and the detailed writeup. You landed on the same problem we've been working on.

This is fixed in the upcoming v0.5.0 release (coming very soon) through the AbilityArgumentNormalizer utility, which handles the {} → [] PHP quirk across all execution paths (tools, prompts, and the execute-ability built-in). We also added type validation in the handlers so non-array arguments get a proper JSON-RPC error instead of failing silently.

I'll close this once v0.5.0 is out. In the meantime, you can test with the trunk branch if you want to verify the fix.

[sanjayvala]

Thanks for the clarification. Glad to see the issue is already addressed in the upcoming v0.5.0 release. Just to confirm — would this contribution be considered as part of core AI contributions, or more as an external/community contribution? Sanjay Vala ***@***.***

…

On Thu, 9 Apr 2026 at 6:02 PM, Ovidiu Galatan ***@***.***> wrote: *galatanovidiu* left a comment (WordPress/mcp-adapter#116) <#116 (comment)> Thanks both for digging into this. @backinpack <https://github.com/backinpack>, your debugging was spot on. The root cause was exactly what you identified: PHP decodes {} as [] (empty array), and the validator was rejecting it because it expected an object. @sanjayvala <https://github.com/sanjayvala>, appreciate the fix and the detailed writeup. You landed on the same problem we've been working on. This is fixed in the upcoming *v0.5.0* release (coming very soon) through the AbilityArgumentNormalizer utility, which handles the {} → [] PHP quirk across all execution paths (tools, prompts, and the execute-ability built-in). We also added type validation in the handlers so non-array arguments get a proper JSON-RPC error instead of failing silently. I'll close this once v0.5.0 is out. In the meantime, you can test with the trunk branch if you want to verify the fix. — Reply to this email directly, view it on GitHub <#116 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDJLNSFOPB7QKHGYYCFXVD4U6J37AVCNFSM6AAAAACQOEBAO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMJUGIYTGNRUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>