DeepSeek-R1-0528 on Foundry, Tool calls and "Unknown ChatFinishReason value. (Parameter 'value') Actual value was tool_call."

[davidames]

I don't really know where this issue sits from a team preservice. The way I'm looking at it is that MS are offering access to models such as DeepSeek via Foundry and they offer frameworks such as SK, ME.AI and Azure.AI.OpenAI to access Foundry so the assumption is that they should work together.

The problem is the above MS frameworks app depend on the OpenAI Nuget package. OpenAI defines the valid ChatFinishReason's as an enum with tool_calls (plural) being a valid value.

DeepSeek-R1-0528 on Foundry returns 'toolcall' (singular) as the ChatFinishReason, and that causes the exception

Unknown ChatFinishReason value. (Parameter 'value')
Actual value was tool_call.

in all of the above packages.

Here is a trace of the offending response

data: {"choices":[{"content_filter_results":{},"delta":{"content":null,"reasoning_content":null,"role":"assistant","tool_calls":[{"function":{"arguments":" 2025\"}","name":null},"id":null,"index":0,"type":"function"}]},"finish_reason":"tool_call","index":0,"logprobs":null,"matched_stop":null}],"created":1758348287,"id":"51703108f11841ab9e5ca2c42e8d4444","model":"DeepSeek-r1-0528","object":"chat.completion.chunk","usage":null}

Here is a trace of a valid response using a different model

{"choices":[{"content_filter_results":{},"delta":{},"finish_reason":"tool_calls","index":0,"logprobs":null}],"created":1758348644,"id":"chatcmpl-CHl5wgXzXrsPXWR8le7ogSRhzySTQ","model":"gpt-4o-2024-11-20","object":"chat.completion.chunk","system_fingerprint":"fp_ee1d74bde0","usage":null}

The difference is finish_reason=toolcall vs finish_reason=tool_calls

I can work around this by writing my own HttpClientHandler and do a string replacement to fix the JSON that comes back from Foundry for DeepSeek, but this feels pretty gross.

Questions:

1. Do Microsoft support using SDKS like SK/ME.AI and/or Azure.AI.OpenAI on Foundry for models such as DeepSeek?
2. Is there a repo that I should be raising this issue in?
3. How are others working around this issue?

These sorts of minor incompatibilities happen in other places too, such as https://github.com/orgs/azure-ai-foundry/discussions/89

[leestott]

Hi @davidames

You're absolutely right to flag this, this is issue between model responses and SDK expectation and model architectures.

Does Microsoft support using SK / ME.AI / Azure.AI.OpenAI with Foundry-hosted models like DeepSeek?

Yes, but with caveats. Microsoft explicitly promotes Foundry as a unified access layer for OSS and proprietary models, and frameworks like Semantic Kernel (SK), ME.AI, and Azure.AI.OpenAI are designed to work with Foundry endpoints.

However:

• These SDKs often wrap the OpenAI NuGet package, which assumes OpenAI-compliant response formats.
• Foundry-hosted models like DeepSeek or Mistral may diverge subtly from OpenAI’s schema (as you’ve seen with tool_call vs tool_calls), causing deserialization failures.

So while support exists in principle, in practice it’s not yet robust across all models, especially OSS ones with looser schema adherence.

There are two key repos depending on where the fix should land:

Repo	Purpose	Link
openai/openai-dotnet	If the issue is with strict enum parsing in the OpenAI NuGet package	Already suggested in Discussion #89
azure-ai-foundry	If the issue is with Foundry’s response formatting or model integration	You could open a new issue or extend Discussion #89

Given that DeepSeek is returning a non-standard finish_reason, it’s arguably a Foundry-side issue but the SDK’s rigidity compounds it.

How are others working around this?

From Discussion #89 and similar threads:

• Custom HttpClientHandler: Like you mentioned, intercepting and rewriting the response is a common workaround, but yes, it’s brittle and can be messy.
• Manual deserialization: Some devs bypass the SDK’s strict enums and deserialize into dynamic objects or custom DTOs.
• Forking the SDK: A few have forked openai-dotnet to relax enum parsing or add fallback logic.
• Model-specific wrappers: Others build thin wrappers around Foundry responses to normalize them before passing to SK or ME.AI.

Suggested Path Forward

Here's a cleaner workaround than rewriting JSON strings:

public static ChatFinishReason ToChatFinishReasonSafe(string value)
{
    return value.ToLowerInvariant() switch
    {
        "tool_calls" => ChatFinishReason.ToolCalls,
        "tool_call" => ChatFinishReason.ToolCalls, // normalize singular to plural
        "function_call" => ChatFinishReason.FunctionCall,
        _ => throw new ArgumentOutOfRangeException(nameof(value), value, "Unknown ChatFinishReason value.")
    };
}

You could inject this into your deserialization pipeline or patch the SDK locally while waiting for upstream fixes.

[davidames]

Thank you @leestott for that well-considered answer.

I think I understand the situation now - where Foundry hosts 3rd party models, Foundry is basically passing the request/response pairs as-is - it's not like you are doing any real transformation of payloads inside of Foundry.

RE: Your suggestion - from a practical POV, how do I inject something like ToChatFinishReasonSafe into my deserialization pipeline, assuming I'm using something like M.E.AI or SK or something else that leverages the underling OpenAI Dotnet SDK? These classes seem to be very "sealed", "closed" and hard to modify, apart from at the HTTP layer.

dave

[aaronpowell]

If you're using MEAI as the interface to talk to the underly SDK (whether it's the OpenAI SDK, Azure.AI.Inference, etc.), you might be able to leverage the pipeline support and do your own processing of the messages as they come back as part of the response.

My other thought was whether you can use a custom JsonConverter and that's where that ToChatFinishedReasonSafe could be implemented but it uses a custom serialization/deserialization pipeline (part of the code generation system from the azure sdk I think) and it doesn't give hooks out that you can leverage.

[achandmsft]

@davidames Are you finding this issue when using the OpenAI SDK for .NET directly with Azure AI Foundry Models with an endpoint using the latest OpenAI /v1 route API defined here: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/latest (https://learn.microsoft.com/en-us/azure/ai-foundry/openai/api-version-lifecycle?tabs=key)?

If yes, could you please file an issue in the OpenAI repo https://github.com/openai/openai-dotnet/issues? cc @brandom-msft

[KrzysztofCwalina]

@m-nash, @JoshLove-msft, will the JsonPatch feature handle this case? Logically, this is equivalent to a type of a property changing.

[m-nash]

@KrzysztofCwalina I don't know exactly which codebase the screenshot of ChatFinishReason.Serialization.cs came from but JsonPatch might help in some scenarios.

If ChatFinishReason is a extensible enum then the fix here is to simply relax the strict parsing. If it is a clr enum then JsonPatch can help. I wrote a gist on this explaining how it could help here.