Support Dynamic Input_Schema

[chubes4]

Currently input_schema must be a static array at registration time.

Request: Allow input_schema to be a callable that returns the schema, enabling context-aware parameters.

Use case: Automation pipelines where tool parameters depend on data collected earlier in the workflow. Parameters should exclude fields that already have values from previous steps.

wp_register_ability('myplugin/process-data', [
      'input_schema' => function(array $context): array {
          return MyPlugin\Schema::generate($context);
      },
  ]);

[justlevine]

Thanks for sharing this suggestion, @chubes4 🙇

From my understanding and advocacy, the primary purpose of Abilities API is to provide a predictable and stable schema that can because statelessly, so I'd strongly advocate against supporting the proposed pattern.

Not entirely sure what specifics you have in mind, but from the use case you provided, I'd recommend either ensuring potential optional args during validation (where you're assumedly already validating and building the context to ensure "previous steps" were actually called), or splitting your ability into multiple smaller abilities and directing your pipeline to use properly scoped ones to the task.

[chubes4]

Hey @justlevine thanks for the reply. I've been trying to wrap my head around this, so forgive me if I've gotten a bit confused.

The specific use case I had in mind:

An ability that lets an agent publish an event to a calendar. The input schema contains the full event schema by default. When predictable structured data is available from the event source, that data is used directly and the corresponding fields are removed from the input schema - the agent shouldn't see or fill fields that are already populated.

When structured data is unavailable or unreliable, those fields remain in the schema for the agent to fill out.

This isn't optional parameters with runtime validation - the schema itself changes based on what data is available at execution time.

That said, I've realized this isn't a hard blocker for my use case. I can use WP AI Client's using_function_declarations() directly and bypass the Abilities API for tools with dynamic schemas.

I was operating under the assumption that the WP AI Client uses the Abilities API exclusively for exposing tools to agents. Happy to discuss further, but also feel free to close the issue if the request is fundamentally incompatible with the principles of the API.

[justlevine]

Thanks very much for clarifying the use case for me. (Also to be extra clear I was sharing my personal opinion, and it's possible and historically likely that others on the team disagree with me 😎)

That said, I've realized this isn't a hard blocker for my use case. I can use WP AI Client's using_function_declarations() directly and bypass the Abilities API for tools with dynamic schemas.

I was operating under the assumption that the WP AI Client uses the Abilities API exclusively for exposing tools to agents.

I want to take this a step further and suggest you invert the mental model even more and think of Abilities as a primitive, similar to actions and filters. They're not a transport or wrapper for writing tools (or other agentic/non-AI protocols or tooling) but a stable function shape those tools can call reliably.

So using your Event Publish example (conceptually because I'm not up to date on wp ai client's abstraction and still via phone):

tool_call: create_event<Partial<AllEventData>> => {
  res = createEventAbility::execute( unknown $input );

  res.success ? handle success : prompt for missing data;
}

[chubes4]

@justlevine this is a really helpful way to think about it, thank you.

Picturing Abilities as low-level primitives was exactly the mental model that I needed.

They are building blocks for tools, not the tools themselves.

Appreciate the insight and understanding.