.NET: Opt in to client function forwarding for Responses hosting - #7844
Conversation
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: rogerbarreto <19890735+rogerbarreto@users.noreply.github.com>
|
Closing this, not ready as a draft, just for analysis. |
Code Coverage OverviewLanguages: C# C# / code-coverage/dotnetThe overall line coverage in commit 196d3b7 in the Show a line coverage summary of the most covered files.
Updated |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2d6ca13a-3274-4167-a074-bfe4df9423ed
|
/review |
There was a problem hiding this comment.
MAF Automated Review — Iteration 1
Result: Findings reported
Scope: full PR (7 commit(s)): 817af2d50f55, 50aa41849948, 41c68b25e1d3, bc86a5305cf8, 01193fb78ca8, 2790966322f7, 87f357a78cb1
Model: gpt-5.6-sol-fast
Overview
The PR preserves default rejection, converts opted-in client functions to declaration-only tools, disables parallel tool calls, and applies conflict checks both before execution and after normal ChatOptions merging. Tests cover the three policies for statically discoverable ChatClientAgent tools and preserve hosted MCP behavior. Residual gaps remain for non-chat agents, tools hidden inside a custom ChatClientFactory, and conflicts introduced late by an AIContextProvider.
Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
3 verified findings remained after source verification (3 medium) across 1 file. Details are attached to the affected lines below.
Affected areas: dotnet/src/Microsoft.Agents.AI.Hosting.OpenAI/Responses/OpenAIResponseRunOptionsBuilder.cs
Centralize mapping in RunOptionsFactory and make dangerous opt-in a boolean. Leave conflict handling and tool execution to downstream clients. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2d6ca13a-3274-4167-a074-bfe4df9423ed
Motivation & Context
Hosted agents exposed over the OpenAI Responses protocol reject client-provided tools by default. Applications sometimes need to supply function declarations through the conventional
toolsrequest field so the model can request functions executed by the calling application.This proposal adds an explicit experimental opt-in without promising conflict resolution in the hosting layer. Client function names, descriptions, and schemas can steer the model away from hosted functions and cause arguments or data to be returned to the caller.
Description & Review Guide
OpenAIResponsesMapOptions.DangerouslyAllowClientFunctionToolsis an experimental boolean, defaulting tofalse. When enabled without a custom factory, it selects a built-in mapping that converts function declarations intoChatClientAgentRunOptions.ChatOptions.Tools, preserving name, description, parameter schema, and optionalstrict.RunOptionsFactoryis the single mapping entry point. A custom factory receives the complete request settings, including rawTools, replaces the built-in mapping, and returns options that the hosting layer does not modify. The boolean has no effect on a custom factory. The existingOpenAIResponses.ToAgentRunRequest(body, mapOptions)helper uses the same factory; no agent-aware overload is needed.The previous conflict behavior types, name checks, deduplication, conflict decorator, and parallel-call override have been removed. The internal converter returns a named tuple
(ClientTools, RemainingTools)and does not assign a support policy to entries it leaves unconverted.Default endpoints still reject client tools. The opt-in enables only function declarations; it does not enable request
tool_choiceor other unsupported request settings. Non-function tools remain rejected by the built-in mapping.Duplicate names are forwarded without resolving collisions. The downstream ChatClient and provider determine whether duplicates are accepted and which function is selected. The hosting layer does not guarantee hosted-function precedence and does not change the developer's parallel-call configuration.
The mapping produces
ChatClientAgentRunOptions, not a provider-neutral tool contract. Other agent implementations may ignore those options; the hosting layer does not reject agents by type or add function support to them. Developers can supply a custom factory for their agent's contract.The existing
MapOpenAIResponseslimitation on subsequentfunction_call_outputinput items is not addressed here. This proposal covers declaration forwarding and returned function calls, not the complete client function result continuation flow.The explicit boolean opt-in and risk documentation; the single mapping contract and custom-factory precedence; declaration fidelity; and leaving collision handling, execution, and parallelism to downstream components. Coverage includes default rejection, raw request preservation, duplicate forwarding, custom factories, hosted functions and MCP tools, non-chat agents, and a credential-gated live OpenAI scenario.
Related Issue
Related to #6416. This proposal addresses opt-in declaration forwarding, but does not implement request
tool_choiceor client function result continuation, so it does not automatically close the full issue.Contribution Checklist