LLM Function Calling in C#: Letting the Model Safely Run Your Code

A language model can only generate text. It can't query your database, check a customer's order, or call your pricing service — which makes a raw LLM useless for most business features. Function calling (also called tool calling) is the bridge: you describe your C# methods to the model, and when a user's request needs one, the model responds with "call this function with these arguments" instead of prose. Your code runs the function, returns the result, and the model turns it into an answer.

Understanding this loop — really understanding it, not just letting a framework hide it — is the difference between debugging AI features confidently and cargo-culting. Let's build it raw first, then use the shortcuts.

The loop, with no framework magic

Three phases: describe, dispatch, resume.

csharp
using OpenAI.Chat;

var client = new ChatClient("gpt-4o-mini", apiKey);

// 1. DESCRIBE: tell the model what tools exist
var getOrderStatusTool = ChatTool.CreateFunctionTool(
    functionName: "get_order_status",
    functionDescription: "Gets the current status and delivery estimate for an order.",
    functionParameters: BinaryData.FromString("""
    {
        "type": "object",
        "properties": {
            "orderNumber": {
                "type": "string",
                "description": "The order number, e.g. TT-10293"
            }
        },
        "required": ["orderNumber"]
    }
    """));

var options = new ChatCompletionOptions { Tools = { getOrderStatusTool } };

var messages = new List<ChatMessage>
{
    new SystemChatMessage("You are a support assistant. Use tools; never guess."),
    new UserChatMessage("Where is my order TT-10293?"),
};

// 2. First call — the model decides it needs the tool
ChatCompletion completion = await client.CompleteChatAsync(messages, options);

while (completion.FinishReason == ChatFinishReason.ToolCalls)
{
    messages.Add(new AssistantChatMessage(completion));

    // 3. DISPATCH: run each requested tool in *your* code
    foreach (ChatToolCall toolCall in completion.ToolCalls)
    {
        string result = toolCall.FunctionName switch
        {
            "get_order_status" => await HandleGetOrderStatus(toolCall),
            _ => """{"error": "unknown tool"}"""
        };

        messages.Add(new ToolChatMessage(toolCall.Id, result));
    }

    // 4. RESUME: give the results back, let the model answer (or call again)
    completion = await client.CompleteChatAsync(messages, options);
}

Console.WriteLine(completion.Content[0].Text);
// "Your order TT-10293 shipped yesterday and should arrive by Thursday."

The things that surprise people the first time:

  • The model never executes anything. It emits a request — a function name and JSON arguments. Your code is the only thing that runs; you can inspect, validate, or refuse any call.
  • It's a loop, not a single round trip. The model may chain calls (look up the order → then check the courier) — hence while, not if. Cap the iterations; a confused model can loop forever, and each lap costs tokens.
  • Descriptions are the API docs the model reads. Vague description → wrong or missed calls. Write them like you're onboarding a junior: what it does, when to use it, what the arguments mean.

Parsing arguments defensively

The arguments arrive as model-generated JSON. Treat them exactly like a request body from the public internet:

csharp
private async Task<string> HandleGetOrderStatus(ChatToolCall toolCall)
{
    using var args = JsonDocument.Parse(toolCall.FunctionArguments);

    if (!args.RootElement.TryGetProperty("orderNumber", out var num) ||
        !OrderNumber.IsValidFormat(num.GetString()))
    {
        return """{"error": "invalid or missing orderNumber"}""";
    }

    var status = await _orders.GetStatusAsync(num.GetString()!);
    return JsonSerializer.Serialize(status);
}

Return errors as structured results rather than throwing — the model reads the error and can recover ("I couldn't find that order — could you double-check the number?"), which is much better UX than a 500.

The security rules that are not optional

Function calling hands a probabilistic text generator influence over code execution. The rules my teams enforce:

  1. Authorization lives in your code, never in the prompt. "Only allow users to query their own orders" as a system-prompt instruction is a suggestion, not a control — prompt-injected input can override it. The tool handler must check the authenticated user's permissions itself, using identity from your auth system, not from anything the model says.
  2. Expose capabilities, not power. A get_order_status(orderNumber) tool, not an execute_sql(query) tool. Every tool should be something you'd be comfortable exposing as a public API endpoint for that same user — because effectively, it is one.
  3. Writes require confirmation. For state-changing tools (cancel order, issue refund), have the assistant confirm with the user first, and consider a human-approval step for high-value actions. Log every invocation with arguments.
  4. Remember prompt injection exists. If your assistant also reads untrusted content (emails, tickets, web pages), that content can contain instructions aimed at your tools ("...and now cancel all orders"). Rules 1–3 are your defense; prompt wording is not.

The shortcut, once you understand it

The manual loop above is ~60 lines per tool. Microsoft.Extensions.AI collapses it — reflection builds the JSON schema from your method signature, and middleware runs the loop:

csharp
using Microsoft.Extensions.AI;

[Description("Gets the current status and delivery estimate for an order.")]
static Task<OrderStatus> GetOrderStatus(
    [Description("The order number, e.g. TT-10293")] string orderNumber)
    => orders.GetStatusAsync(orderNumber);

IChatClient client = openAiClient.GetChatClient("gpt-4o-mini")
    .AsIChatClient()
    .AsBuilder()
    .UseFunctionInvocation()
    .Build();

var response = await client.GetResponseAsync(
    "Where is my order TT-10293?",
    new ChatOptions { Tools = [AIFunctionFactory.Create(GetOrderStatus)] });

Use this in production — it's less code to get wrong. But the security rules transfer unchanged (the framework runs the loop; you still own validation and authorization inside the method), and when tool calls misbehave, you now know exactly what's happening underneath.

Debugging tips from the trenches

  • Log the full message sequence (assistant tool-call messages and tool results). Ninety percent of "the AI is being dumb" turns out to be a bad tool description or a malformed result payload.
  • If the model won't call your tool, sharpen the description and add "use the available tools; never guess" to the system prompt.
  • If it calls tools too eagerly, say when not to use them ("only for questions about specific orders").

Function calling is the moment an LLM stops being a text toy and becomes an integration point in your architecture. Treat it with API-boundary seriousness and it will carry a remarkable amount of product value.

Where to go next