.NET: Opt in to client function forwarding for Responses hosting

[Copilot]

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 tools request 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

• What are the major changes?

OpenAIResponsesMapOptions.DangerouslyAllowClientFunctionTools is an experimental boolean, defaulting to false. When enabled without a custom factory, it selects a built-in mapping that converts function declarations into ChatClientAgentRunOptions.ChatOptions.Tools, preserving name, description, parameter schema, and optional strict.

#pragma warning disable MAAI001
var mapOptions = new OpenAIResponsesMapOptions
{
    DangerouslyAllowClientFunctionTools = true
};
#pragma warning restore MAAI001

app.MapOpenAIResponses(agent, responsesPath: null, mapOptions);

RunOptionsFactory is the single mapping entry point. A custom factory receives the complete request settings, including raw Tools, 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 existing OpenAIResponses.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.

• What is the impact of these changes?

Default endpoints still reject client tools. The opt-in enables only function declarations; it does not enable request tool_choice or 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 MapOpenAIResponses limitation on subsequent function_call_output input items is not addressed here. This proposal covers declaration forwarding and returned function calls, not the complete client function result continuation flow.

• What do you want reviewers to focus on?

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_choice or client function result continuation, so it does not automatically close the full issue.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change.

[Copilot]

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.

[Roger Barreto (rogerbarreto)]

Closing this, not ready as a draft, just for analysis.