Weekly .NET Roundup: Agents, safer web APIs, and MCP tools

by TechHub

This week in .NET, Microsoft Agent Framework hit a more practical stride with a batteries-included runtime (Harness) and Declarative Workflows 1.0 that moves multi-agent orchestration into YAML you can review and change without rewriting core code. On the web stack, .NET 11 Preview 6 focused on safer defaults and sharper APIs, including async validation for minimal APIs, automatic CSRF protection, and OpenAPI updates that help keep server and client contracts aligned. We also saw VS Code refine the in-editor agent experience and more hands-on guidance for building MCP servers in .NET, with sampling and logging patterns that improve repeatability and observability. Rounding things out, hybrid integration stayed in focus with a detailed walkthrough for running Azure Logic Apps Hybrid on a self-managed Kubernetes setup.

This Week's Overview

Microsoft Agent Framework: runtime and YAML-defined orchestration land in 1.0

Building on last week's Agent Framework momentum (orchestration patterns reaching 1.0 and “skills” becoming a governable unit), Microsoft pushed two pieces that fit together: a new “batteries-included” runtime (Harness) and a way to move orchestration out of code (Declarative Workflows 1.0). The net effect is that more of an agent app's behavior can be described, inspected, and changed without rewriting core logic, while still running on a standard workflow runtime.

Declarative Workflows 1.0 (for .NET and Python) lets teams define multi-agent orchestration in YAML, including state, branching, tool calls, and human handoffs. The workflow definitions support Power Fx expressions, and they can integrate with MCP tools (Model Context Protocol), which helps when your agent needs to call external tools with a consistent contract.

The Microsoft Agent Framework Harness release complements that by providing a runtime that already includes planning, tool-calling, memory, approvals, web search, and OpenTelemetry instrumentation. For .NET teams, the OpenTelemetry piece is especially practical because it makes it easier to trace tool calls and agent steps end-to-end (which is usually where “it worked locally” turns into debugging sessions in production), and it aligns with common observability stacks.

ASP.NET Core and Blazor: .NET 11 Preview 6 focuses on safer defaults and better APIs

Preview 6 continues the .NET 11 web story with changes that target everyday friction points: input validation patterns, CSRF safety, and keeping your API description accurate as OpenAPI evolves. The updates shown in the ASP.NET Community Standup span minimal APIs, OpenAPI output, and general framework improvements.

Async minimal API validation is one of the more practical developer workflow changes because it aligns validation with how real services work (database lookups, remote checks, and other async dependencies). Automatic CSRF protection pushes the platform toward safer defaults, so teams can reduce the odds of missing a security step when adding endpoints or wiring up UI-to-API flows.

On the API contract side, the update includes OpenAPI 3.2-related work, plus support for unions, which can matter when you need to describe endpoints that return one of several shapes (and you want generated clients to reflect that accurately). If you're maintaining both server and client code, these kinds of OpenAPI improvements can reduce the “hand-maintained contract drift” that shows up over time.

VS Code + Copilot changes that matter for .NET devs

Building on last week's focus on Copilot configuration and enterprise governance in VS Code, VS Code continues to tighten the loop between the editor and agent-driven workflows, and this week's updates show both near-term UI changes and how to track what's landing next. For .NET developers using VS Code as their primary IDE, these changes mostly affect how you review, steer, and iterate on agent output without leaving the editor.

Agents Window: redesigned editor panel in VS Code 1.129

Following last week's tracking of the 1.129 Insiders train, VS Code 1.129 introduces a redesigned editor panel inside the Agents window, aimed at making agent-driven coding feel more “in-editor” rather than a separate chat surface. The demo focuses on how the UI supports workflows where an agent proposes changes and you review or apply them directly in the editor context.

For day-to-day work, this kind of UI shift matters because it can reduce context switching: you spend less time mapping an agent response back to files, diffs, and editor state. It is also a signal that agent features are becoming a first-class editor workflow, not just an add-on pane.

Tracking what is coming: VS Code 1.131 (Insiders) and the July recap

If you rely on extensions and editor integrations (C#, Razor, debugging, test runners), the Insiders notes are often the fastest way to see upcoming changes that could affect your setup. The VS Code 1.131 (Insiders) release notes page is maintained as changes land, and it links directly to the main branch commit log and the 1.131.0 milestone's closed issues, which makes it easier to correlate a behavior change with a specific fix or PR.

The “VS Code Live: July Releases Recap” video provides a higher-level walkthrough of recent VS Code release highlights and GitHub Copilot improvements. If you manage a team setup, the recap format can be useful for quickly spotting features worth standardizing (or disabling) before they hit everyone through auto-updates.

Building MCP servers in .NET: sampling and observable tool runs

Building on last week's thread of MCP showing up across the .NET stack (from Foundry/Blazor discussions to Azure integration surfaces), more .NET teams are experimenting with MCP (Model Context Protocol) to expose tools that LLM clients can call consistently, and this week had two practical tutorials that focus on making those tool calls more robust. One adds sampling (how the model chooses tokens), and the other adds server logging that surfaces back in the client console when tools run.

Add sampling to a .NET MCP server (Ollama local LLM)

The sampling tutorial shows an MCP tool that triggers a chat-client request to a locally running LLM in Ollama, then adds sampling configuration to control response behavior. This is useful when you're iterating on agent/tool quality and want repeatable outputs for debugging, or when you want to deliberately trade determinism for creativity depending on the tool.

Because the example runs locally with Ollama, it is a workable pattern for development environments where you want fast feedback and lower cost before switching to hosted models. It is also a reminder that MCP servers are not just “wrappers” around tools - they often end up owning model-call defaults and guardrails that affect downstream behavior.

Add server logging and display logs in a .NET console client

The logging follow-up focuses on observability: adding server-side logs to the MCP server and then surfacing those logs in the .NET console client when a tool is invoked. When tools fail, time out, or return unexpected output, this kind of “tool run transcript” can save time compared to hunting through multiple processes and log files.

If you're moving from prototype to something others will run, piping the right logs back to the caller is a practical step toward supportability. It also pairs naturally with the broader OpenTelemetry push in agent runtimes (including Microsoft's Agent Framework Harness), where you want consistent traces across tool calls and agent steps.

Other .NET News

Following last week's Logic Apps Standard coverage (and its drift toward more “real app” hosting and deployment concerns), hybrid integration remains a steady theme, and this week included a detailed guide to running Azure Logic Apps Hybrid on a self-managed Kubernetes setup. The walkthrough covers a single-node RKE2 cluster, MetalLB for LoadBalancer IPs, and Azure Arc for connectivity, plus practical fixes for RKE2-specific issues like DNS/CoreDNS behavior and inotify limits.