This article shows a minimal, current pattern that adds OpenTelemetry instrumentation and a simple local evaluation loop around an Agent Framework agent hosted in ASP.NET Core. The agent runs against a local Ollama model and has one ordinary C# tool. The same registration works if you later swap the chat client for Azure OpenAI or OpenAI.

What the Agent Framework actually emits

Agent Framework builds on the Microsoft.Extensions.AI middleware pipeline. When you call UseOpenTelemetry on an IChatClientBuilder or on an AIAgent builder, the framework emits traces and metrics that follow the OpenTelemetry GenAI semantic conventions. You get spans for the overall agent invocation, for each chat completion, and for every tool execution. Token counts, latencies, and (optionally) sensitive content appear as attributes.

You do not have to write your own ActivitySource for the common path. You do have to subscribe to the right source names and decide whether sensitive data is allowed in your environment.

Packages and project setup

Create a minimal API project targeting .NET 8 or later (Agent Framework 1.x works on the supported .NET versions). Install the packages that are current as of late 2026:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Extensions.AI
dotnet add package OllamaSharp
dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.Console
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol

OllamaSharp is the recommended way to obtain an IChatClient for a local Ollama instance. Microsoft.Extensions.AI.Ollama is deprecated.

Register the instrumented agent

In Program.cs the registration is short. Add the OpenTelemetry middleware to the chat client and to the agent. You don't need to add function invocation yourself: the agent wraps the chat client in Microsoft.Extensions.AI's function-invocation middleware automatically, so each model call and each tool execution gets its own span under the agent run.

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using OllamaSharp;
using OpenTelemetry.Trace;
using System.ComponentModel;

var builder = WebApplication.CreateBuilder(args);

const string TelemetrySource = "MyApp.Agent";

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource(TelemetrySource)
        .AddConsoleExporter()
        // Uncomment for an OTLP collector or Aspire dashboard
        // .AddOtlpExporter(o => o.Endpoint = new Uri("http://localhost:4317"))
    );

builder.Services.AddSingleton<IChatClient>(sp =>
{
    var ollama = new OllamaApiClient(new Uri("http://localhost:11434"), "llama3.2");
    return ollama
        .AsBuilder()
        .UseOpenTelemetry(sourceName: TelemetrySource, configure: cfg => cfg.EnableSensitiveData = false)
        .Build();
});

builder.Services.AddSingleton<AIAgent>(sp =>
{
    var chatClient = sp.GetRequiredService<IChatClient>();
    return chatClient.AsAIAgent(
        instructions: "You are a helpful assistant. Use the GetWeather tool when the user asks about weather. Never invent weather data.",
        name: "WeatherAgent",
        tools: [AIFunctionFactory.Create(GetWeather)])
        .AsBuilder()
        .UseOpenTelemetry(sourceName: TelemetrySource, configure: cfg => cfg.EnableSensitiveData = false)
        .Build();
});

var app = builder.Build();

app.MapPost("/chat", async (ChatRequest request, AIAgent agent) =>
{
    var result = await agent.RunAsync(request.Message);
    return Results.Ok(new { answer = result.Text });
});

app.Run();

[Description("Get the current weather for a city.")]
static string GetWeather([Description("City name")] string city)
    => $"The weather in {city} is 18°C and partly cloudy.";

record ChatRequest(string Message);

EnableSensitiveData is deliberately false in the example. Turn it on only in development or behind a private collector; otherwise prompts and tool results land in your telemetry store.

What the traces look like

When a request hits /chat, you see a parent span for the agent run. Inside it sits a chat span, and if the model decides to call GetWeather you see a child execute_tool span. The attributes include the model name, token usage, duration, and the tool name. This is enough to answer the usual production questions: Did the agent call the tool it was supposed to call? How many tokens did this turn cost? Was the latency dominated by the model or by the tool?

If you point the OTLP exporter at the Aspire dashboard or at Jaeger, the same spans appear with the parent-child relationship intact. No extra custom instrumentation is required for the basic path.

Local evaluation before the agent leaves the machine

Traces tell you what happened. Evaluation tells you whether the behavior is acceptable, and you can start with plain assertions that run against your local model without a cloud bill.

A practical starting point is a small console harness (or an integration test) that exercises the same agent registration and checks two things: the final answer contains expected keywords, and the required tool was actually invoked.

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

// Assume the same AIAgent registration as above, resolved from a test host or built directly.

AIAgent agent = BuildWeatherAgent(); // same chat client + AsAIAgent registration as Program.cs

var evalResult = await agent.RunAsync("What is the weather in Seattle?");

// Simple local checks
bool containsExpected = evalResult.Text.Contains("Seattle", StringComparison.OrdinalIgnoreCase)
                        && evalResult.Text.Contains("18", StringComparison.OrdinalIgnoreCase);

// The response includes the intermediate tool-call messages, so check that GetWeather was really invoked
bool toolWasCalled = evalResult.Messages
    .SelectMany(m => m.Contents)
    .OfType<FunctionCallContent>()
    .Any(call => call.Name == "GetWeather");

Console.WriteLine($"Content check: {containsExpected}");
Console.WriteLine($"Tool check: {toolWasCalled}");

When keyword checks stop being enough, the Microsoft.Extensions.AI.Evaluation libraries (Microsoft.Extensions.AI.Evaluation.Quality and .Reporting) add LLM-graded evaluators such as relevance, coherence, and groundedness, plus cached, repeatable reports you can run in CI. The important design point stays the same: run the checks against the live agent (or a recorded fixture) before the endpoint is exposed, and every time you change the prompt, the model, or a package version.

Putting both pieces behind an ASP.NET Core endpoint

The pattern that works in production is to keep the agent registration exactly as shown above and to surface only a thin endpoint. Health checks can verify that Ollama (or the cloud endpoint) is reachable. A separate internal endpoint or a background job can run a small evaluation suite on a schedule and emit a custom metric if the checks start failing.

app.MapGet("/health/agent", async (AIAgent agent) =>
{
    try
    {
        var result = await agent.RunAsync("Say OK if you can use tools.");
        return Results.Ok(new { status = "healthy", preview = result.Text });
    }
    catch (Exception ex)
    {
        return Results.Problem(ex.Message);
    }
});

Keep this probe on a slow schedule or behind an internal route, because every call is a real model request. Because the OpenTelemetry middleware is already on the agent, every health-check call also appears in traces. You can alert on elevated error rates, missing tool spans, or sudden token spikes without writing extra logging code.

Practical constraints

Local models such as llama3.2 support tool calling reliably enough for this pattern, but smaller models sometimes skip the tool or hallucinate arguments. The evaluation checks catch that before users do. Sensitive data in traces is the other hard constraint: EnableSensitiveData = true is useful while you are debugging a single developer machine and dangerous once the collector is shared.

Agent Framework ships updates often, and the GenAI telemetry conventions are still evolving. Pin the packages you use and re-run the evaluation suite when you upgrade.

Closing

The difference between a working agent demo and an agent you can leave running is visibility and a repeatable check that the agent still does what you intended. OpenTelemetry on the Agent Framework builders gives you the traces and metrics. A short local evaluation loop gives you the quality gate. Both fit inside a normal ASP.NET Core host and stay provider-agnostic, so the same code works with Ollama today and with Azure OpenAI tomorrow.

Rahmat Afridi is an AI Integration Developer and Senior .NET Developer based in Islamabad, Pakistan, building production .NET and AI-integrated systems since 2016. See his work and AI integration services at rahmatafridi.com, or browse his code on GitHub.

This article shows a practical pattern: take a typical order-management API, expose a small set of read-only tools over MCP, lock it down with authentication and authorization, and verify the surface with an MCP client. The approach works for any existing service layer you already trust.

Why a Separate MCP Surface Beats Auto-Exposing Every Endpoint

Agents are not ordinary API clients. They decide which tools to call based on descriptions and schemas, then chain those calls. Exposing every controller action as a tool quickly produces a noisy, dangerous surface. A better design is a thin MCP server that sits beside your application (or inside the same host) and offers only the operations that are safe and useful for agents.

Start with read-only lookups that answer familiar questions: “What is the status of order 12345?” or “List open orders for customer C-789.” Write clear, specific descriptions so the model chooses the right tool. Later you can add carefully guarded write tools that require explicit human approval or elevated roles. The official SDK (ModelContextProtocol.AspNetCore 2.2.0 at the time of writing) makes this straightforward with attribute-based tools and first-class ASP.NET Core integration.

Setting Up the MCP Server

Create or open an ASP.NET Core web project and add the package:

dotnet add package ModelContextProtocol.AspNetCore --version 2.2.0

In Program.cs register the server. The SDK’s HTTP transport is stateless by default in v2, which is ideal for load-balanced deployments:

using ModelContextProtocol.Server;

var builder = WebApplication.CreateBuilder(args);

// Your existing services
builder.Services.AddScoped<IOrderService, OrderService>();

builder.Services.AddMcpServer()
    .WithHttpTransport()
    .AddAuthorizationFilters()
    .WithToolsFromAssembly();

var app = builder.Build();

app.MapMcp("/mcp");

app.Run();

WithToolsFromAssembly discovers every class marked [McpServerToolType] and every method marked [McpServerTool]. You can also register individual types with .WithTools<OrderTools>() if you prefer explicit control.

Wrapping Existing Services as Tools

Keep business logic in the services you already have. The tool methods simply call them and return results the agent can use. Inject the service (or any other DI-registered dependency) directly:

using Microsoft.AspNetCore.Authorization;
using ModelContextProtocol.Server;
using System.ComponentModel;
using System.Security.Claims;

[McpServerToolType]
public class OrderTools
{
    private readonly IOrderService _orders;

    public OrderTools(IOrderService orders) => _orders = orders;

    [McpServerTool, Description(
        "Gets the current status and key details of a single order by its ID. " +
        "Use this when the user asks about a specific order number.")]
    public async Task<string> GetOrderStatus(
        [Description("The unique order identifier")] string orderId)
    {
        var order = await _orders.GetByIdAsync(orderId);
        if (order is null)
            return $"Order {orderId} was not found.";

        return $"Order {order.Id}: Status={order.Status}, Total={order.Total:C}, Customer={order.CustomerId}";
    }

    [McpServerTool, Description(
        "Lists open orders for a given customer. Returns at most 20 recent open orders.")]
    public async Task<string> ListOpenOrders(
        [Description("The customer identifier")] string customerId)
    {
        var orders = await _orders.GetOpenOrdersAsync(customerId, limit: 20);
        if (orders.Count == 0)
            return $"No open orders found for customer {customerId}.";

        return string.Join("\n", orders.Select(o =>
            $"{o.Id}: {o.Status} - {o.Total:C}"));
    }
}

The [Description] attributes become the tool descriptions the agent sees. Write them the way you would write a good API comment—clear purpose, expected inputs, and any limits. The SDK generates the JSON schema from the method signature automatically.

Adding Authentication and Authorization

Treat the MCP endpoint as a protected API. Configure JWT bearer authentication the same way you already do for your other APIs, then require authorization on the MCP mapping:

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.AspNetCore.Authorization;

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = builder.Configuration["Auth:Authority"];
        options.Audience = builder.Configuration["Auth:Audience"];
        options.TokenValidationParameters.ValidateIssuer = true;
        options.TokenValidationParameters.ValidateAudience = true;
    });

builder.Services.AddAuthorization();

// ... AddMcpServer as before ...

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapMcp("/mcp").RequireAuthorization();

For finer control, apply [Authorize] attributes to individual tools. Because we called AddAuthorizationFilters(), the SDK honors them: unauthorized tools disappear from tools/list results, and direct calls return a forbidden error.

[McpServerTool, Description("Cancels an order. Admin role required.")]
[Authorize(Roles = "Admin")]
public async Task<string> CancelOrder(
    ClaimsPrincipal user,
    [Description("The order to cancel")] string orderId,
    [Description("Reason for cancellation")] string reason)
{
    // Audit who called it
    var caller = user.Identity?.Name ?? "unknown";
    await _orders.CancelAsync(orderId, reason, caller);
    return $"Order {orderId} cancelled by {caller}.";
}

The SDK injects ClaimsPrincipal automatically when the parameter is present; it never appears in the tool schema the agent sees. This gives you both declarative role checks and the ability to log or further filter inside the method.

You can also set a policy on the endpoint itself:

app.MapMcp("/mcp").RequireAuthorization("McpToolsPolicy");

where the policy requires an authenticated user plus a specific scope claim:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("McpToolsPolicy", policy => policy
        .RequireAuthenticatedUser()
        .RequireClaim("scope", "mcp.tools"));
});

Limiting What Agents Can Call

Several complementary techniques keep the surface small:

• Only mark the methods you want with [McpServerTool]. Everything else stays private to your normal API.

• Prefer read-only tools first. Write operations should carry [Authorize] and, for high-risk actions, an extra confirmation step or human-in-the-loop flow.

• Use precise descriptions and parameter constraints so the model is less likely to invent calls.

• Consider separate MCP endpoints or tool groups for different agent roles if your organization needs stronger isolation.

• Log every tool invocation (the SDK’s request filters or ordinary ASP.NET Core logging make this easy) so you can audit what agents actually did.

Because the MCP server calls your existing service layer, all of the validation, business rules, and database constraints you already trust remain in force.

Testing with an MCP Client

You can verify the server without an LLM by using the SDK’s client. In a separate console project (or a test):

using ModelContextProtocol.Client;
using ModelContextProtocol.Protocol;

var transport = new HttpClientTransport(new HttpClientTransportOptions
{
    Endpoint = new Uri("http://localhost:5000/mcp")
    // Add authentication headers here if required
});

await using var client = await McpClient.CreateAsync(transport);

var tools = await client.ListToolsAsync();
foreach (var tool in tools)
{
    Console.WriteLine($"{tool.Name}: {tool.Description}");
}

var result = await client.CallToolAsync(
    "GetOrderStatus",
    new Dictionary<string, object?> { ["orderId"] = "ORD-1001" });

var text = result.Content.OfType<TextContentBlock>().FirstOrDefault()?.Text;
Console.WriteLine(text);

If you configured authentication, supply a valid bearer token on the HttpClient used by the transport. The tools returned by ListToolsAsync are AIFunction instances, so you can pass them to an IChatClient (Microsoft.Extensions.AI) through ChatOptions.Tools and let an agent invoke them automatically.

Production Notes

• Keep the MCP server stateless unless you specifically need server-to-client notifications.

• Place it behind the same reverse proxy, rate limits, and WAF you use for the rest of your APIs.

• Start with an internal-only deployment so you can observe real agent behavior before opening it more widely.

• Monitor tool call volume and latency; agents can be chatty.

• Version your tool contracts carefully—agents cache schemas and descriptions.

The combination of a thin, explicitly curated tool surface, ordinary ASP.NET Core authentication, and per-tool authorization gives you a controlled way to let AI agents work with systems you already run. You do not need to rebuild your APIs; you only need to decide which capabilities are safe to describe and expose.

About the author
Rahmat Afridi is an AI Integration Developer & Senior .NET Developer based in Islamabad, Pakistan, with experience since 2016 building practical systems in C#, ASP.NET Core, Azure, and modern AI integration patterns.
https://rahmatafridi.com
https://github.com/rahmatafridi