Remove AIFunctionDeclaration tools on last iteration in FunctionInvokingChatClient

[Copilot]

• Understand the problem: When FunctionInvokingChatClient reaches its maximum iterations limit, it should not include any AIFunctionDeclaration tools in the ChatOptions.Tools it sends to the inner service

Changes

• Added PrepareOptionsForLastIteration helper method that removes AIFunctionDeclaration tools from options
• Modified GetResponseAsync to call this method when iteration >= MaximumIterationsPerRequest
• Modified GetStreamingResponseAsync similarly
• If no tools remain after filtering, also clears ToolMode
• Added 4 comprehensive tests for the new behavior

Tests Added

• LastIteration_RemovesFunctionDeclarationTools_NonStreaming - Verifies tools are removed on last iteration
• LastIteration_RemovesFunctionDeclarationTools_Streaming - Verifies tools are removed on last iteration for streaming
• LastIteration_PreservesNonFunctionDeclarationTools - Verifies non-AIFunctionDeclaration tools (like HostedWebSearchTool) are preserved
• LastIteration_DoesNotModifyOriginalOptions - Verifies original options are not mutated

Verification

• All 56 FunctionInvokingChatClientTests pass on net9.0
• Code review feedback addressed

Original prompt

FunctionInvokingChatClient exposes a max iterations setting, where it will stop making additional calls to the inner client once it reaches that limit. Please update it so that when it's on its last iteration, it doesn't include any tools AIFunctionDeclarations in the ChatOptions.Tools it sends to the inner service (and if that drops the Tools count to 0, clear the ToolsMode setting). Otherwise, the final request to the inner client can end up coming back with tool requests. Please ensure this is thoroughly tested, adding any necessary tests to existing test files.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Microsoft Reviewers: Open in CodeFlow

[stephentoub]

@westey-m , @rogerbarreto , @eiriktsarpalis I've opened this after seeing microsoft/agent-framework#3113. Good idea? Better to leave as is?

[Copilot]

Pull request overview

This PR addresses an issue where FunctionInvokingChatClient would send function declaration tools to the inner client on the final iteration (when the maximum iterations limit is reached), potentially causing the inner client to return tool call requests that would never be executed.

Changes:

• Added PrepareOptionsForLastIteration helper method that filters out AIFunctionDeclaration tools when reaching the iteration limit
• Applied this filtering to both GetResponseAsync and GetStreamingResponseAsync methods
• Options are cloned before modification to preserve the original caller's options
• ToolMode is cleared when all tools are removed (all were AIFunctionDeclaration), but preserved when non-function tools remain

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvokingChatClient.cs	Added PrepareOptionsForLastIteration method and integrated it into both streaming and non-streaming code paths to remove AIFunctionDeclaration tools on the last iteration
test/Libraries/Microsoft.Extensions.AI.Tests/ChatCompletion/FunctionInvokingChatClientTests.cs	Added comprehensive tests covering non-streaming, streaming, non-function tool preservation, and original options immutability scenarios

[westey-m]

This seems reasonable to me. If an answer cannot be reached after the configured iterations, I do think it's better to have the LLM respond with an inconclusive answer (i.e. I cannot answer this question) rather than produce a result more consistent with manual function invocation. The whole point of maximum iterations is to stop endlessly cycling through functions, and producing yet another one is not consistent with that goal.
Also, if the developer is using FICC, they do not typically expect FCC to be returned, and it wouldn't be great if all developers had to defensively code for that scenario.

[rogerbarreto]

In my opinion, a new setting in the FICC should be available to define what is the CircuitBreak behavior defaulting on this solution (throwing / advertising / not advertising once the limit is reached).

For scenarios where the caller unintentionally caused tool cycling loop would not possible to discern if there was an infinite iteration loop error or normal finite iteration.

If the above is not a concern, looks good.