Core Abilities getting error when execution

[arkenon]

When trying to execute "core/get-user-info" and "core/get-environment-info" with an AI assistant's function call, getting these errors:

{
                    "error": "Ability \"core/get-user-info\" does not define an input schema required to validate the provided input.",
                    "code": "ability_missing_input_schema",
                    "data": null
                }

{
                    "error": "Ability \"core/get-environment-info\" does not define an input schema required to validate the provided input.",
                    "code": "ability_missing_input_schema",
                    "data": null
                }

It requires a default input_schema. So the other ability named 'core/get-site-info' runs succesfuly, because it has a default input_schema.

[solankisoftware]

Fixed : Core Abilities getting error when execution

[solankisoftware]

I’ve added a default input_schema to both core/get-user-info and core/get-environment-info.

These abilities were failing validation with ability_missing_input_schema because no schema was defined.
The added schema allows empty input and prevents unexpected parameters, matching the behavior of other core abilities.

Patch attached for review.

[keshav6750]

Tested this patch on WordPress 6.x, works as expected.

[hbhalodia]

Hi @arkenon @solankisoftware @keshav6750, I do have tried to reproduce the issue, but I do not think this is a valid issue. The reason is because, the input_schema is an optional args and not required, hence passing it empty or either does not pass it wholely will not give any errors.

Please see the below recording on how I am able to execute both the APIs and getting the correct output.

​https://app.godam.io/web/video/88o90c4fqu

Also if you see documentation of abilities API it says that input schema is optional, Ref - ​https://developer.wordpress.org/apis/abilities-api/php-reference/#registering-abilities-wp_register_ability:~:text=input_schema,%2C%20Optional)

Could you please check with theme/plugin/custom code that might be changing the core behavior?

Thank You,

[solankisoftware]

Hi @ehabholodia, thank you for checking this and for the detailed feedback.

I reproduced this issue on a clean WordPress install (no plugins, default theme) using the following steps:

Register an ability using register_ability() without defining input_schema.

Execute it via the Assistants API function call.

The execution fails with:
ability_missing_input_schema

While the documentation mentions that input_schema is optional, in practice the execution layer still attempts to validate input and throws an error when the schema is missing.

The proposed patch adds a default empty schema to align runtime behavior with the documented API and with other core abilities that already define a default schema.

I confirmed this on a clean environment, so this does not appear to be caused by custom theme or plugin code.

If you’d like, I can share a minimal reproduction snippet to help validate this further.

Thanks again for reviewing this.

[hbhalodia]

Hi @solankisoftware, Thanks for the test.

Yes it would be great if you add the detail reproduction report, because in my testing I am unable to reproduce the issue. I am not sure what am I missing, or not sure if I am executing the API correctly.

To share what I said, I am using something like this,

$ability = wp_get_ability( 'core/get-environment-info' );
$result = $ability->execute();
print_r( $result );

The above block is executing as expected without error as shown in ticket description.

Thank You,

[arkenon]

@hbhalodia I tried running these abilities through wordpress-ai-client.

If you print the code output to the screen or send a request directly to the WordPress REST API, yes, it works.

However, if you try running the abilities from an external tool like wp-ai-client or other AI tools, it returns an error.

[hbhalodia]

Replying to arkenon:

@hbhalodia I tried running these abilities through wordpress-ai-client.

If you print the code output to the screen or send a request directly to the WordPress REST API, yes, it works.

However, if you try running the abilities from an external tool like wp-ai-client or other AI tools, it returns an error.

Thanks @arkenon, Got your point. Also if you can share a snippet, how you are using wp-ai-client to execute the abilities APIs, I will try to reproduce it on my end and will share the updates.

Basically my concern is, just adding the input_schema for fixing this is not an ideal solution, instead we need to check why it breaks even when documentation says it's optional.

Thanks,

[arkenon]

Here is my project using the wordpress-ai-client:

​https://github.com/Arkenon/orchestrator-for-wp-ai-client

This project executes abilities using the Ability_Function_Resolver::execute_abilities($message).

<?php
// Execute abilities/functions and get the response message
$function_response_message = Ability_Function_Resolver::execute_abilities( $message );

[hbhalodia]

Thanks @arkenon for the details. I will look on this and will find root cause and a potential fix instead of just adding the input schema as a workaround.

[hbhalodia]

Thanks @arkenon @solankisoftware @keshav6750, I got the issue what happens is, when there is a call from AI Assitant, to this function,

$function_response_message = Ability_Function_Resolver::execute_abilities( $message );

It goes, to Ability_Function_Resolver, execute_abilities function, in that, the individual ability would be executed here - ​https://github.com/WordPress/wp-ai-client/blob/dacb6e8b73ff3097c41a256dfe26fb3d0cea9f48/includes/Builders/Helpers/Ability_Function_Resolver.php#L57,

Which further takes us to this 2 lines, ​https://github.com/WordPress/wp-ai-client/blob/dacb6e8b73ff3097c41a256dfe26fb3d0cea9f48/includes/Builders/Helpers/Ability_Function_Resolver.php#L91-L92, The args which is added as a parameter is coming as an empty array, and is added to execute function.

Now if we check for execute function, it has normalize_input and validate_input. normalize_input just checks for the input is null or not, if null or input_schema is empty, it returns null, but in our case it is empty array, coming as input, so it checks only first condition that input is not null, hence it return with empty array instead of null.

Now, coming to validate_input, it takes the value returned from the normalize_input function, and it checks for, empty $input_schema and it checks for null as an input, since our input is not null, but our input schema is empty, hence instead of return true, it returns the wp_error.

The solution of this is to check for empty input as well, either in normalize_input function or in validate_input function. Below are the two solutions which we can think of to implement.

## Changes to normalize_input -- ​https://github.com/WordPress/wordpress-develop/blob/cfa06b16d210995793f0cee826169e0a986ad28f/src/wp-includes/abilities-api/class-wp-ability.php#L444-L455,

if ( null !== $input && ! empty( $input ) ) {
        return $input;
}

## Changes to validate_input -- ​https://github.com/WordPress/wordpress-develop/blob/cfa06b16d210995793f0cee826169e0a986ad28f/src/wp-includes/abilities-api/class-wp-ability.php#L465-L496,

if ( null === $input || empty( $input )) {
        return true;
}

Cc: @justlevine for some inputs here.

Trac ticket: https://core.trac.wordpress.org/ticket/64483

## Description

1. Added the check in normalize_input function to check for the input value, not only for null, but as well as for empty.
2. Check comment for details.

## Note

1. We have 2 solutions added on the mentioned trac comment, we can update the PR with the other one if the current is not accepted or we can have another approach for the same to fix it.

[justlevine]

@hbhalodia thanks very much for the tag 🙇

Now if we check for execute function, it has normalize_input and validate_input. normalize_input just checks for the input is null or not, if null or input_schema is empty, it returns null, but in our case it is empty array, coming as input, so it checks only first condition that input is not null, hence it return with empty array instead of null.

I'm looking for the prior discussion, but this was actually an intentional design decision when folks decided to support mixed input and not just a shaped array/object (as @hbhalodia noted, input_schema being optional is also intentional).

The gate therefore intentionally differentiates between an ability intentionally called with no value ($a->execute()), but not a falsey/potentially malformed one (e.g. $a->execute( 0 ) or $a->execute( [ ] ).

Based on that I'd suggest against the change proposed ​https://github.com/WordPress/wordpress-develop/pull/10755.

---

Similarly per the above, the true source of the bug reported by @arkenon in wp-ai-client - also as @hbhalodia noted. Assumedly ​| Ability_Function_Resolver::execute_ability() needs to be changed to correctly differentiate between functions with no args and empty args. (Unless the thing feeding [] to it is your orchestrator project. Cool concept btw 🙌).

I'll flag the folks working on that plugin first, but assumedly we want to close this ticket in favor of one over there (cc @jasontheadams)

---

There's still the general DX friction that sourced this. As far as whether we should give these core/* abilities an explicit schema (and/or the ability to take any falsely value), could be a worthwhile discussion for enhancement, but personally I'd be wary of doing that without minimally making input_schema required and ideally banning mixed and require a shape with explicit arg names. Which would be pretty sad since by starting with mixed we now cant enforce this and only warn, but still probably worthwhile.

(PS: Abilities probably needs its own component, or we need clearer signposts that it's still being handled by the AI team. If @hbhalodia didn't tag me none of us would have probably seen this until it merged).

[hbhalodia]

@justlevine Thanks for the detailed insights and the decisions taken while implementing the Abilities API.

I am also in favor of updating wp-api-client to correctly handle and pass the intended value to execute function, instead of changing in the core, but that said I was not 100% sure on whether to fix it to core or update the AI client, hence started with a PR. I would be closing the PR if we are not intending to fix it on core as per above discussion.

The gate therefore intentionally differentiates between an ability intentionally called with no value ($a->execute()), but not a falsey/potentially malformed one (e.g. $a->execute( 0 ) or $a->execute( [ ] ).

I am thinking why we have not added the empty checks? It would have not cause the errors, I agree that could be a design decision, but it would had been good if at least empty checks were there.

Unless the thing feeding [] to it is your orchestrator project.

I don't think so the orchestrator project is feeding that, because I have created a mu-plugin, that uses WP AI Client directly to perform the required thing and that still failed, which made me to debug it further.

I'll flag the folks working on that plugin first, but assumedly we want to close this ticket in favor of one over there

Looking forward the ticket on ​https://github.com/WordPress/wp-ai-client to fix the issue.

If @hbhalodia didn't tag me none of us would have probably seen this until it merged

That would have never happened though, because I would have ultimately tagged you on the PR I raised for review 😉.

[jason_the_adams]

Hi @hbhalodia!

One of the PHP/WP AI Client maintainers here. 👋

I agree with @justlevine. This looks like an issue in the client, not something wrong with the Abilities API itself.

I dug into this enough to determine that it's a bug happening in the PHP AI Client in how we convert the model payload into a Message, in particular how the arguments are turned into a FunctionCall. It's likely misinterpreting an empty JSON object as an empty array, not realizing it should be null.

Can you please tell me which provider you're testing with?

Thank you!

[hbhalodia]

Hey @jason_the_adams, Thanks for the details, Yes below is the info. The exact code I used to replicate the issue.

$text = 'prompt';
$builder = AI_Client::prompt();
$builder->with_text( $text );

$builder->using_model_preference( array( 'google', 'gemini-3-pro-preview' ) )
        ->using_temperature( 0.2 );

// Get and attach abilities
$abilities = wp_get_abilities();

if ( ! empty( $abilities ) ) {
    $builder->using_ability( ...$abilities );
}

$result = $builder->generate_result();
$candidates = $result->getCandidates();
$candidate = $candidates[0];
$message = $candidate->getMessage();

$function_response_message = Ability_Function_Resolver::execute_abilities( $message ); // This is doing an issue here, as rightly said because of $message.

Let me know if this helps?

[jason_the_adams]

Got it! Ok, so you're using whatever Provider is set up with a preference for Gemini 3 Pro. I'm assuming that when testing this you've been using credentials for Google? Have you tested with any other providers?

Thanks!

[jason_the_adams]

I have a tentative fix in the PHP AI Client: ​https://github.com/WordPress/php-ai-client/pull/175