Weekly .NET Roundup: MCP skills, IDE agents, and safer web apps

by TechHub

This week's .NET roundup centers on MCP becoming a practical foundation for agent tooling, with the MCP C# SDK v2.0 and new Agent Framework hooks that let agents discover skills at runtime with clearer safety boundaries. Visual Studio and VS Code also pushed further into agent-driven workflows, from a Copilot Chat Agent preview to an MCP-backed MSBuild binlog analyzer that can explain failures and performance bottlenecks. On the engineering side, the focus shifted to reliable automation (a unit-test agent that validates tests end-to-end and traced multi-agent orchestration with OpenTelemetry) plus a solid web security refresher on Fetch Metadata headers for defense-in-depth CSRF protection.

This Week's Overview

MCP and Agent Framework: a more standard way to plug tools into .NET agents

Building on last week's focus on making MCP tools production-friendly (including Durable Functions patterns for long-running tool calls) and instrumenting local agents with OpenTelemetry, this week pushed Model Context Protocol (MCP) further into the .NET agent stack with a clear emphasis on interoperability: expose capabilities as “skills” on an MCP server, discover them at runtime, and let agent runtimes call them without tight coupling. The throughline is that agents are getting more modular, and .NET developers now have sharper primitives for routing, transport, and safety when connecting LLMs to real tools.

A practical takeaway is that MCP is no longer just “a protocol you read about” - the SDKs, Agent Framework hooks, and examples are converging on repeatable patterns. If you are building internal agent tools, it is getting easier to separate concerns: keep your tool surface area in MCP skills, keep your orchestration in Agent Framework (or Copilot SDK clients), and keep model hosting flexible (cloud or local).

MCP C# SDK v2.0 aligns with the 2026-07-28 spec (stateless HTTP + MRTR)

Following last week's MCP-on-Azure-Functions guidance (where request/response timing and client expectations matter), the official MCP C# SDK hit v2.0, implementing the 2026-07-28 MCP specification with a stateless-by-default HTTP approach and standardized routing headers. For developers building MCP servers and clients, this matters because it reduces the need for sticky sessions while still enabling richer interactions through Multi Round-Trip Requests (MRTR), which support interactive tools without forcing a long-lived session model.

The announcement also calls out compatibility and lifecycle details: what is deprecated, what remains supported, and how upgrades should be approached. It also introduces opt-in extension packages for “Apps” and “Tasks”, which gives teams a way to adopt higher-level capabilities without pulling them into the core SDK surface area by default.

Agent Framework can now discover MCP-based skills on demand (with guardrails)

Building on last week's Visual Studio “built-in Agent Skills” story (and the broader push toward governable, reusable tool surfaces), Microsoft Agent Framework added MCP-based Agent Skills support for .NET, so agents can discover and load skills from an MCP server as needed instead of shipping every tool definition up front. The new Microsoft.Agents.AI.Mcp package and the UseMcpSkills builder API are the key touchpoints, and they formalize how you wire MCP skill discovery into an agent runtime.

Safety is treated as a first-class concern, especially around skills packaged as archives. The post highlights controls for archive extraction, which is important if you plan to let agents dynamically fetch capabilities at runtime (where “download and run tools” can quickly become an organizational risk if not constrained).

Exposing a skill from a .NET MCP server (and calling it from an agent with a local model)

Following last week's local-agent walkthroughs using Ollama (including telemetry and tool-approval patterns), a companion tutorial shows the other side of the MCP story: how to expose a skill as a resource from a .NET MCP server, then have an agent client use that skill to answer a question with the LLM running locally via Ollama. The real value here is the end-to-end wiring: define the skill surface, publish it via MCP, then consume it from an agent without embedding the tool logic inside the agent itself. If you are trying to standardize “tools” across multiple agent clients, this separation is the part to copy.

Copilot SDK and IDE agents: Visual Studio and VS Code keep shifting toward agent-driven workflows

Building on last week's Visual Studio Copilot additions (Agent Skills, model selection controls, and extension governance), the common theme across Visual Studio and VS Code this week was agent integration that feels closer to day-to-day development tasks: code review on selected code, organizational policy via instructions, and specialized tooling (like build log analysis) delivered through Copilot Chat and MCP servers. The net effect is that the IDE is increasingly the host for multiple agent-like capabilities, rather than a single “chat box” feature.

Visual Studio July update: Copilot Chat Agent (Preview) built on the Copilot SDK

Visual Studio's July update introduced a new Agent (Preview) inside Copilot Chat built on the GitHub Copilot SDK, continuing the “skills-first” direction from last week's Agent Skills update by emphasizing tool-backed assistance rather than purely conversational help. The update also mentions built-in .NET and Azure skills, which signals a direction toward tool-backed assistance rather than purely conversational help.

Two workflow additions stand out for teams: organization-level Copilot custom instructions (so you can standardize how Copilot behaves across a company) and branch attachment for chat context (so the agent can reason against the right code state). There is also an engineering-quality-of-life improvement: better MSVC toolset discovery across installations, which should reduce friction when working across multiple VS setups.

VS Code: MSBuild Binlog Analyzer preview uses Copilot Chat + an MCP server

A new preview MSBuild Binlog Analyzer for VS Code uses GitHub Copilot Chat backed by the Microsoft.AITools.BinlogMcp MCP server to interpret .binlog files, and it pairs naturally with last week's push toward MCP tooling patterns that stay modular and observable. Instead of manually hunting through MSBuild output, you can ask for explanations of build failures, identify performance bottlenecks (including critical path analysis), compare builds, and spot regressions.

For .NET teams, this is one of the clearest “AI + dev tooling” matches because .binlog already contains structured build execution data. The important implementation detail is the architecture: the analyzer is not just a prompt trick, it is Copilot Chat connected to a purpose-built MCP server that can read and reason over the log content.

Visual Studio 18.9 Insiders: “thinking effort” adds a knob for speed vs reasoning (and credits)

This builds on last week's work to make Copilot behavior more transparent in the IDE (model picking, context windows, and usage visibility) by adding a “thinking effort” control for supported AI models in Visual Studio 18.9 Insiders 2. The control lets you choose between faster responses with less reasoning and deeper reasoning for harder problems, with an explicit trade-off that more reasoning can consume more usage credits.

This kind of control is most useful when you can standardize expectations across a team. For example, you might encourage low effort for quick refactors or IDE questions, then switch to higher effort for debugging multi-project build failures or complex architectural changes where shallow answers waste time.

VS Code 1.132 Insiders: track changes as they land

As with last week's VS Code Insiders callout (1.130), VS Code 1.132 (Insiders) published its evolving release notes, pointing to the commit log and closed milestone issues so you can follow features as they ship. If your team depends on specific editor behaviors (or you maintain extensions), this is the easiest way to catch breaking changes early and validate against Insiders before Stable updates roll out.

AI-assisted engineering workflows in .NET: tests, multi-agent orchestration, and production patterns

This continues last week's shift from “agent demos” to operational patterns (modernization playbooks, telemetry, and controlled tool execution) by focusing on applying agents to concrete engineering work: generating trustworthy tests, coordinating multiple subagents with tracing, and carrying AI prototypes into production architectures. The common thread is operationalizing AI in ways that fit real repos and real team constraints.

A polyglot unit-test agent that learns repo conventions and validates tests end-to-end

The code-testing-generator in dotnet/skills is positioned as a unit-test agent that does more than spit out test files, and it fits the same “skills as reusable building blocks” direction we highlighted last week with Visual Studio's built-in Agent Skills and the dotnet/skills repo. It learns a repository's conventions, generates tests, and then validates that the tests build and run using the repo's normal test workflow, which is the part that tends to fail when generated tests do not match real dependencies and patterns.

The benchmarks highlighted in the post show higher task completion and fewer failures than stock GitHub Copilot, especially on vague prompts and diff-based test requests. For teams, the practical value is in closing the loop: instead of “generated code” that might compile in theory, you get a workflow aimed at producing tests that actually pass in CI, with mutation testing and code coverage called out as part of the quality conversation.

Wrapping a Squad multi-agent team as a Microsoft Agent Framework AIAgent (with tracing)

Following last week's emphasis on tracing agent behavior with OpenTelemetry (even in local harnesses), a separate release post shows how to connect GitHub Copilot CLI/SDK with Microsoft Agent Framework by wrapping a Squad multi-agent team as an MAF AIAgent. The walkthrough includes C# dependency injection (DI) setup, session configuration, and OpenTelemetry tracing for subagents, which is the kind of instrumentation you need once “multiple agents working together” becomes more than a demo.

The main takeaway is that orchestration is starting to look like normal distributed systems work. If you can trace subagent calls and tool usage, you can debug “why did the agent do that” problems with the same discipline you apply to services, and you can measure where latency or failures are coming from inside an agent team.

Enterprise AI patterns: moving from prototype to production in .NET

This complements last week's “make it real” thread (modernization workflows, governed tools, and production-ready MCP patterns) with a longer-form session collecting patterns aimed at taking .NET AI solutions from early experiments into production-ready systems. The focus is on integration approaches and architecture decisions, which is where many teams get stuck after they prove an idea in a notebook or a single service.

If you are building internal copilots or AI-powered workflows, the useful framing is to treat the LLM as one dependency inside an application architecture. That pushes you to address issues like operational boundaries, deployment models, and maintainability early, instead of bolting them on once the prototype is already popular.

Web security fundamentals for .NET: Fetch Metadata headers for CSRF and isolation

This pairs well with last week's patch-and-servicing mindset (CVE awareness and defense-in-depth) by digging into Fetch Metadata request headers (like Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, and Sec-Fetch-User) with a thorough, developer-focused breakdown, including what their values mean and how servers can use them to flag suspicious cross-origin requests. The practical angle is strengthening CSRF defenses by making decisions based on browser-provided context, rather than relying only on referrer/origin checks or assuming CORS is a CSRF control.

For .NET web apps, this fits neatly into modern defense-in-depth: you can use these headers to reject high-risk request patterns, tighten resource isolation policies, and reduce the attack surface for cross-site navigation and embedded requests. The post frames this in terms of real server-side checks you can add, which is useful if you are preparing for newer platform behaviors (it also references .NET 11 in the broader context).

Other .NET News

A few smaller items this week were more about day-to-day editor habits and lightweight workflow tweaks than platform changes, but they are still useful if your team lives in VS Code or is trying to reduce wasted Copilot iterations.