AI Agents in .NET: Build Production-Ready AI Agents with Semantic Kernel and MCP

• Microsoft.Extensions.AI provides provider-agnostic abstractions such as IChatClient and IEmbeddingGenerator. This lets a .NET application work with different model providers without rewriting the application layer.
• Semantic Kernel provides orchestration through the Kernel, plugins, and agent capabilities. For teams evaluating Semantic Kernel .NET and AI agents with Semantic Kernel, it can serve as an AI agent framework for .NET, exposing C# functions as tools so the model can interact with application services through typed contracts.

Model Context Protocol (MCP)

MCP is an open standard for exposing tools and data to AI applications. Model Context Protocol in .NET scenarios is useful when an agent needs governed access to shared capabilities such as GitHub, databases, or internal APIs. This is part of a broader .NET AI development approach in which provider-specific model access and external tool integrations remain behind clear application boundaries. A .NET application can also expose its own capabilities through an MCP server.

AI Model Providers

The model provider supplies the underlying chat or embedding model. Keep provider-specific configuration at the infrastructure boundary so the agent and business logic remain as portable as practical.

How to Build an AI Agent in .NET

The implementation below builds an agent incrementally: register the model, create the Semantic Kernel, add local tools, connect MCP tools, ground responses with RAG, and run the agent loop.

Register the AI Model

Everything starts with  IChatClient, wired through standard dependency injection.

 

builder.Services
    .AddChatClient(sp =>
        new AzureOpenAIClient(
            new Uri(config["AzureOpenAI:Endpoint"]!),
            new DefaultAzureCredential())        // managed identity, no keys in code
        .GetChatClient(config["AzureOpenAI:Deployment"]!)
        .AsIChatClient())
    .UseFunctionInvocation()                     // enables tool calling
    .UseOpenTelemetry()                          // traces every model call
    .UseLogging();

 

Notice what comes for free: no API keys in source, automatic tool invocation, and telemetry — all through the same middleware pattern used elsewhere in .NET.

Create the Semantic Kernel

Create the Kernel around the registered AI services and application dependencies. The Kernel becomes the composition point for the model, plugins, MCP tools, and other services the agent can use.

Step 1: Add Tools and Plugins

A tool is just a C# method the model is allowed to call. Keep inputs and outputs typed.

 

public sealed class OrdersPlugin(IOrderService orders)
{
    [KernelFunction, Description("Gets the current status of a customer order by id.")]
    public async Task<OrderStatus> GetOrderStatusAsync(
        [Description("The order identifier, e.g.: ORD-10293")] string orderId)
        => await orders.GetStatusAsync(orderId);
}

 

The model reads the descriptions to decide when to call this method. Treat descriptions as part of the contract — they are effectively the API documentation the model reads.

Step 2: Connect MCP Tools

These tools are functions you wrote inside your own app. But some data or capability lives outside your app or is owned by another team — and you don’t want to re-implement it everywhere. MCP is a standard plug format for tools — like a USB port for AI. If a capability is exposed as an MCP server, any AI app can plug in and use it without custom integration code.Consuming an external MCP server takes a few lines, and the tools plug straight into the kernel alongside local plugins.

 

public sealed class OrdersPlugin(IOrderService orders)
{
    [KernelFunction, Description("Gets the current status of a customer order by id.")]
    public async Task<OrderStatus> GetOrderStatusAsync(
        [Description("The order identifier, e.g.: ORD-10293")] string orderId)
        => await orders.GetStatusAsync(orderId);
}

 

Using Model Context Protocol (MCP) with AI Agents in .NET

MCP is most valuable when tools or data are shared across applications or teams. In a production .NET system, treat MCP servers as governed integration boundaries: authenticate connections, restrict available tools, validate tool inputs and outputs, and monitor calls just as you would for any other enterprise API.

Add RAG and External Knowledge

The LLM only knows what it was trained on — not your company documents, policies, or anything recent or private. Ask it about those and it may guess. Grounding forces the model to answer from your real content instead of its memory, which is what RAG (Retrieval-Augmented Generation) does:

• Retrieve the relevant documents from your knowledge base,
• Augment the prompt by inserting those documents,
• the LLM generates an answer grounded in them.

Documents are converted into embeddings (numeric representations of meaning) and kept in a vector store (Azure AI Search, Qdrant, or pgvector via  Microsoft.Extensions.VectorData). Retrieval is then exposed as just another tool the agent can call when it needs background knowledge, instead of stuffing everything into the prompt.

 

[KernelFunction, Description("Searches the firm's policies and research notes.")]
public async Task<string> SearchResearch(string query)
    => await _vectorStore.SearchAsync(query);  // returns the most relevant document
chunks

 

Adding RAG to .NET AI Agents for Grounded Responses

RAG helps an agent answer from current, private, or company-specific information instead of relying only on model training data. Documents are embedded and stored in a vector store, then retrieved as context when the agent needs grounded knowledge. In a production system, retrieval should be treated as a tool with clear access controls, relevance checks, and observability.

Run the Agent

 

ChatCompletionAgent agent = new()
{
    Name = "support-agent",
    Instructions = "Help customers with orders. Use tools for facts. Never guess an
order status.",
    Kernel = kernel,
    Arguments = new(new PromptExecutionSettings
    {
        FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
    })
};
await foreach (var response in agent.InvokeStreamingAsync(userMessage, thread))
    yield return response.Message.Content;  // stream tokens to the UI

 

That’s a working agent. The remaining work is what makes it production-grade.

Production Engineering for AI Agents

The model is the easy part; the engineering around it is what makes production-ready AI agents reliable, secure, cost-bounded, observable, and testable.

Reliability and Resilience

Model endpoints fail, rate-limit, and time out. Wrap them with the standard resilience stack:

 

builder.Services.ConfigureHttpClientDefaults(http =>
    http.AddStandardResilienceHandler(o =>
    {
        o.AttemptTimeout.Timeout       = TimeSpan.FromSeconds(30);
        o.TotalRequestTimeout.Timeout = TimeSpan.FromSeconds(90);
        o.Retry.MaxRetryAttempts      = 3;
    }));

 

The same capability can be published as an MCP server so other agents reuse it — one implementation, exposed once and governed centrally. (If your app only ever uses its own data, you can skip MCP; it earns its place when tools are shared across apps or teams.)