.NET: Hosting with OpenAI Responses output yielding unexpected function call requests

[stephentoub]

The OpenAI Responses support is dutifully translating FunctionCallContent / FunctionResultContent from a hosted agent into function_call and function_call_output response items. But such content represents already-invoked functions, and function_call in Responses is actually a request from the server to invoke the corresponding function on the client. Commensurately, there's no situation where a server sends function_call_output, because that's intended for the client to send to the server. With how things are currently arranged, then, the hosted agent is sending notifications about functions it invoked but those will be interpreted by a responses client as a request for invocation.

To my knowledge, there's no general "this arbitrary function was invoked on the server" set of response items in the OpenAI Responses spec, so it's unclear what these should map to. It's possible the right answer for now is for the OpenAI Responses hosting to filter them out.

FunctionCallContent.InformationOnly conveys whether the FCC is information-only (e.g. a notification of a function already invoked) or whether it's a request for invocation.

cc: Reuben Bond (@ReubenBond), Korolev Dmitry (@DeagleGross), westey (@westey-m), Roger Barreto (@rogerbarreto)

[vsantele]

As documentation:
This issue openresponses/openresponses#5 talks about internally hosted tools that could be a solution, where tools defined in MAF are internals for the client.
The Vercel AI SDK has a property providerExecuted for this use case: https://ai-sdk.dev/docs/foundations/tools#provider-executed-tools.

As mentioned in #3971, if FC and FCC are filtered out from the response, it removes the stateless usage of the responses API.

[CorgiBoyG]

I rechecked this against current main at 2c49f50cf. Both response conversion paths still emit every FunctionCallContent as function_call and every FunctionResultContent as function_call_output; neither path inspects FunctionCallContent.InformationOnly.

A narrow fix appears possible without taking over the stateless-history work in #3971:

• suppress only calls marked InformationOnly and their matching results by CallId;
• apply the same rule to non-streaming responses and streaming events;
• preserve ordinary client-executable function calls and results unchanged;
• cover a mixed response containing both a server-executed pair and a real client-executable call.

This would prevent a server execution notification from becoming a new client execution request while retaining protocol items that genuinely belong in stateless client history.

Before I proceed with the implementation, could the core team confirm that filtering InformationOnly call/result pairs is the intended behavior until the Responses protocol has a representation for server-executed tools? I can prepare the focused change within 2–3 days after confirmation.

AI assistance was used for repository triage and call-path analysis.