Think I found a bug.

[prophet404]

Abilities with type: object schemas silently fail when called with arguments: {} on sites running WooCommerce

[prophet404]

AbilityArgumentNormalizer fails to coerce empty array to stdClass — silent rejection between permission_callback and execute_callback

Summary

When an MCP client sends arguments: {} (empty object) to tools/call for an ability whose input_schema declares type: "object", the call fails with the generic client-facing message "An error occurred while executing the tool." No PHP error, no entry in wp-content/debug.log, no exception caught in the mcp_adapter_pre_tool_call or mcp_adapter_tool_call_result filter chain — the request is silently rejected somewhere between permission_callback and execute_callback.

The Adapter's own AbilityArgumentNormalizer::normalize() docblock describes this exact failure mode and claims to fix it by coercing [] → stdClass. On the affected stack the coercion does not actually prevent the rejection.

Environment

• MCP Adapter: 0.5.0
• WordPress: 6.9.4
• PHP: 8.3.30 (also reproduced on 8.6.0)
• MySQL: 8.4.6
• Web server: Apache (SiteGround managed hosting)
• Active plugins: WooCommerce 10.7.0, custom abilities plugin (registers ~128 abilities under the claude/* namespace)
• HPOS: enabled, compatibility mode off
• WP_DEBUG: true, WP_DEBUG_LOG: true, WP_DEBUG_DISPLAY: false

Reproduction

Register an ability with this schema:

'input_schema' => [
    'type' => 'object',
    'properties' => [
        '_unused' => ['type' => 'string', 'default' => '']
    ]
],

Call it via the MCP transport:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "mcp-adapter-execute-ability",
    "arguments": {
      "ability_name": "claude/get-site-info",
      "parameters": {}
    }
  }
}

Expected: The ability executes. The normalizer coerces the empty parameters array to stdClass so JSON Schema type: object validation passes.

Actual: Response is HTTP 200 with:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{"type": "text", "text": "An error occurred while executing the tool."}],
    "isError": true
  }
}

No mcp_adapter_pre_tool_call or mcp_adapter_tool_call_result filters fire. No debug log entry. No exception caught by set_exception_handler or register_shutdown_function.

Workaround that confirms the diagnosis

Calling the same ability with any non-empty parameters succeeds:

"parameters": {"_unused": ""}

Returns the expected payload. This identifies the empty-args path as the trigger.

Notable

• Affects only abilities whose input_schema.type is "object" AND that are called with empty arguments.
• Abilities called with at least one property (e.g. list-posts with per_page: 1) work normally on the same site, same request lifecycle.
• WooCommerce being active appears to influence the reproduction. With Woo deactivated on the test site, the same calls succeed even with arguments: {}. This suggests Woo's rest_api_init ordering or some serialization filter is interacting with the normalizer — but the underlying issue (empty [] reaching a type: object validator) is in the Adapter.
• Removing input_schema entirely (so the normalizer's "no schema → null" branch fires) also breaks execution for these abilities — even with non-empty arguments. So AbilityArgumentNormalizer::normalize() is reachable, but neither of its branches reliably handles the empty-args case on this stack.

Suggested investigation

Trace through ToolsHandler::handle_tools_call between the check_permission return and the mcp_adapter_pre_tool_call filter dispatch when arguments is [] and input_schema.type === 'object'. The silent rejection lives in that window. Possibly worth verifying whether AbilityArgumentNormalizer::normalize() is being called from both the check_permission and execute paths, and whether the stdClass it returns is preserved across them.

Additional notes for maintainers

• Happy to test patches against this exact stack — the reproduction site is a non-production WooCommerce store.
• The generic client message "An error occurred while executing the tool." appears to come from the MCP client side rather than the Adapter — the Adapter's own internal_error factory uses the string "Failed to execute tool". Better passthrough of the Adapter's actual error message to the client would have made this bug far easier to diagnose.

[shawfactor]

Yes I have found the same bug, any progress?