Power Platform Community Forum Thread Details

When a tool, based on an OpenAPI connector, contains optional input parameters, Copilot Studio appears to actively request values for certain missing parameters before executing the action, even when:

The parameter is not marked as required in OpenAPI.

The action accepts null or empty values.

The parameter description explicitly instructs the agent to send null when the user does not provide a value.

The available user input already contains sufficient information to execute the query.

The same OpenAPI schema behaves differently when executed through GitHub Harness, where the tool is invoked immediately without requesting additional optional parameters.

This suggests a possible inconsistency in the planning/orchestration layer rather than in the OpenAPI definition itself.

Categories:

Calling actions from Copilot Studio

General topics

Hi @jrussi1301

Your OpenAPI definition is not the problem. The prompting comes from a Copilot Studio layer that sits above your schema, and required is not what controls it.
Every tool input has a Fill using setting, and the default is Dynamically fill with AI. Per the docs, the agent tries to extract the value from available context, and if no appropriate value is found, it generates a question to ask the user. That is the behaviour you are seeing, and it applies regardless of whether the parameter is optional in your spec.

Two fixes, depending on what you need.

If the parameter should never be collected from the user, override it. In the tool's Inputs tab, switch Fill using to a custom value and supply a literal, a variable, or a Power Fx formula. The docs describe this as overriding an input with an explicit value instead of letting the agent extract it. A parameter with a value is not missing, so no question is generated.
If the value genuinely varies and needs to stay dynamic, keep Dynamically fill with AI but rewrite the description. This is where I would correct a common approach: instructing the agent to send null does not work well, because you are asking it to produce absence, and its fallback when it has nothing is to ask. Give it a concrete default value to return instead.

There is a Microsoft CAT-authored example of precisely this pattern for an optional filter input. The description tells the agent to generate a filter only when the request clearly implies one, explicitly says not to ask the user any follow-up questions, says not to invent filters, and then gives a literal fallback expression to return when no criterion is present. That last part is what stops the question being generated.

Also worth setting Identify as on each input to the right entity type, since it improves extraction from context and reduces how often the agent decides it found nothing.
On the harness difference. Your read looks right. Standard applies its own input collection layer over the tool schema, whereas GitHub appears to hand the schema to the model directly. That is an orchestration difference rather than an OpenAPI one. I have not used the GitHub harness enough to know whether that is intentional or just less mature, so I would not design around it yet, and it is worth raising with support so the inconsistency gets tracked.

References:
https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent
https://microsoft.github.io/mcscatblog/posts/dataverse-search-in-copilot-studio-unauthenticated-structured-data/