OpenAPI tool name/description not loaded from Foundry agent definition

[brandonh-msft]

Description

When the user loads an Agent definition from Azure Foundry that includes an openapi type tool, the resulting tool object does not include the OpenAPI tool name or description.

Because the tool definition is incomplete after load, subsequent requests to the agent for completion/response can misbehave.

Impact

Subsequent completion/response requests operate against an incomplete tool definition, which can lead to incorrect or unstable agent behavior.

Notes

This appears to be a deserialization or mapping gap when importing the Foundry Agent definition into the runtime tool model.

Reproduction Steps

1. Define an Agent in Foundry with an openapi type tool.
2. Set the tool name and description in the Foundry definition.
3. Load that Agent through the agent framework.
4. Inspect the loaded tool object.
5. Observe that name and description are not populated on the tool object.
6. Send a subsequent completion/response request to the agent and observe misbehavior caused by the incomplete tool definition.

Expected behavior

When loading an Agent definition from Foundry, the framework should hydrate the OpenAPI tool object with the same name and description metadata defined in Foundry.

Actual behavior

The loaded tool object is missing the OpenAPI tool name and description fields.

Foundry definition:

Resulting object after _projectClient.GetAIAgentAsync:

Regression?

Not sure

Known Workarounds

One would have to bypass the SDK and go after the data on their own to re-hydrate the tool properly.

Configuration

No response

Other information

No response

[stephentoub]

@brandonh-msft what is the relevance to this repo? I'm missing it.

[brandonh-msft]

The problem appears to exist in the MicrosoftExtensionsAIResponsesExtensions.AsAITool() path from what I could discern...

[stephentoub]

What problem? MicrosoftExtensionsAIResponsesExtensions.AsAITool has little to do with the cited scenario; all it does is construct an AITool-derived type that the IChatClient can then unwrap to access the original ResponseTool instance.