Azure SDK | The .NET Blog

Stop Hammering a Struggling Dependency: Retry Patterns for Azure Functions + Service Bus

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

Here’s how a recoverable fault becomes an outage in a Functions app: a dependency starts timing out, every Function instance retries immediately and indefinitely, the dependency gets hammered with hundreds of concurrent failed requests, and what started as a transient hiccup turns into a system-wide backpressure event.

You probably know this story. Azure Functions scale out fast — that’s the whole point. But “scale out fast” and “retry immediately” together can make failures dramatically worse.

Two patterns help. Exponential backoff and circuit breaker. Both are now natively supported for Service Bus-triggered Azure Functions.

Two Patterns, Different Roles

These patterns are complementary, not alternatives:

Exponential backoff answers: when should I try again? It increases the delay between retries so a dependency has time to recover. Message-level, pacing the retry timing.

Circuit breaker answers: should I call this dependency at all right now? It stops repeated calls to an unhealthy dependency after a failure threshold is hit, then probes carefully after a cooldown period. System-level, preventing retry storms.

You want both. Backoff handles per-message retry pacing. Circuit breaker handles aggregate health decisions.

Why This Matters Especially for Service Bus

The queue absorbs burst traffic, which is good. But without controls, the queue can grow while workers keep wasting compute on calls that will fail. Poison messages stay active longer than they should. Hot partitions or limited downstream capacity create cascading problems.

The safer design:

Detect transient failure
Delay the next attempt with exponential backoff
Stop calling the dependency when a failure threshold is reached (circuit open)
Resume carefully after a cooldown period (circuit probe)
Move irrecoverable work to dead-letter or a quarantine path

What the Native Support Looks Like

The new support integrates with the existing Azure Functions host model — no extra libraries, no custom implementations. Configuration goes in your host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

Circuit breaker configuration sets the failure threshold and reset interval so unhealthy dependencies don’t get pummeled during recovery.

Languages Covered

This isn’t .NET only. The feature covers dotnet, JavaScript, TypeScript, and Python — the full set of Service Bus trigger supported languages in Azure Functions.

Wrapping Up

Retry patterns aren’t exciting to configure until the first time a downstream outage causes your Functions to compound the problem instead of gracefully degrading. Setting these up proactively is cheap. Retrofitting them during an incident is not.

Original post: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

Azure MCP Server Is Now a .mcpb — Install It Without Any Runtime

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

You know what was annoying about setting up MCP servers? You needed a runtime. Node.js for the npm version, Python for pip/uvx, .NET SDK for the dotnet flavor, Docker if you wanted containers. Just to get a tool connected to your AI client.

The Azure MCP Server just changed that. It’s now available as an .mcpb — an MCP Bundle — and the setup is drag-and-drop.

What’s an MCP Bundle?

Think of it like a VS Code extension (.vsix) or a browser extension (.crx), but for MCP servers. A .mcpb file is a self-contained ZIP archive that includes the server binary and all its dependencies. Everything needed to run on your platform, packaged together.

The end result: you download one file, open it in a supported client, and the server runs. No runtime to install, no package.json to manage, no version conflicts.

How to install it

Three steps:

1. Download the bundle for your platform

Go to the GitHub Releases page and grab the .mcpb file for your OS and architecture. Make sure you pick the right one — osx-arm64 for Apple Silicon, osx-x64 for Intel Mac, etc.

2. Install in Claude Desktop

The easiest way: drag and drop the .mcpb file into the Claude Desktop window while you’re on the Extensions settings page (☰ → File → Settings → Extensions). Review the server details, click Install, confirm. Done.

Tip: You can also set Claude Desktop as the default app for .mcpb files and double-click to install.

3. Authenticate to Azure

az login

That’s it. The Azure MCP Server uses your existing Azure credentials.

What you can do with it

Once installed, you have access to 100+ Azure service tools directly from your AI client:

Query and manage Cosmos DB, Storage, Key Vault, App Service, Foundry
Generate az CLI commands for any task
Create Bicep and Terraform templates
Get architecture recommendations and diagnostics

Try prompts like:

“List all resource groups in my subscription”
“Generate a Bicep template for a web app with a SQL database”
“What Cosmos DB databases do I have?”
“Show me the secrets in my Key Vault named my-vault”

Which install method should you use?

Method	Best for
`.mcpb`	Claude Desktop users who want zero-config
VS Code Extension	Developers working in VS Code + GitHub Copilot
npm/npx	Developers who already have Node.js
pip/uvx	Python developers
Docker	CI/CD pipelines and containers

All methods give you the same tools. The .mcpb is just the most frictionless path for Claude Desktop users.

Why this matters

MCP servers are genuinely useful — they let AI clients interact with external systems in a structured way. But the setup friction has been a real barrier, especially for users who aren’t developers or who just don’t want to manage runtimes for every tool they install.

The .mcpb format feels like the right direction. It’s the same principle as VS Code extensions or browser extensions: one file, platform-native binary, install and go.

If the MCP ecosystem keeps moving this direction, connecting AI clients to services will get a lot simpler.

Get started

Download: GitHub Releases
Repo: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Check the full post for troubleshooting tips and a comparison of all install methods.

Azure SDK April 2026: AI Foundry 2.0 and What .NET Developers Should Know

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Monthly SDK releases are often easy to skip. This one has a few things worth paying attention to — especially if you’re building with AI Foundry, Cosmos DB in Java, or doing infrastructure provisioning from .NET code.

Azure.AI.Projects 2.0.0 — Breaking Changes That Make Sense

The Azure.AI.Projects NuGet package reaches stable 2.0.0 with some significant architectural changes. If you’re already using the preview, here’s what changed:

Namespace splits: Evaluations moved to Azure.AI.Projects.Evaluation, memory operations moved to Azure.AI.Projects.Memory. Your using statements will need updating.
Renamed types: Insights → ProjectInsights, Schedules → ProjectSchedules, Evaluators → ProjectEvaluators, Trigger → ScheduleTrigger
Naming conventions: Boolean properties now follow the Is* convention consistently

These are the kinds of breaking changes that hurt once and then feel right forever. If you’ve been building on the preview, update your imports and let the compiler point you to the rest.

The good news: it’s stable. You can actually rely on this API now.

Cosmos DB Java: Critical Security Fix (RCE)

This one is serious. The Java Cosmos DB library (azure-cosmos) version 4.79.0 includes a critical security fix for a Remote Code Execution vulnerability (CWE-502).

The issue was Java deserialization in CosmosClientMetadataCachesSnapshot, AsyncCache, and DocumentCollection. The fix replaces Java deserialization with JSON-based serialization, eliminating the entire class of deserialization attacks.

If you have any Java services using Azure Cosmos DB, update to 4.79.0 immediately. This isn’t optional.

New Provisioning Libraries for .NET

A wave of stable Provisioning libraries hit 1.0.0 this month — these are the libraries that let you define Azure infrastructure in C# code rather than ARM templates or Bicep:

Several more are in beta.1, covering API Management, Batch, Compute, Monitor, MySQL, and Security Center. If you’re doing infrastructure-as-code from .NET — particularly with Aspire deployments — these libraries are your entry point.

Azure AI Agents Java: 2.0.0 GA

The Java Azure AI Agents library also reaches general availability this month. The key breaking changes:

Several enum types converted to ExpandableStringEnum-based classes (more flexible for new values)
*Param model classes renamed to *Parameter
MCPToolConnectorId → McpToolConnectorId (consistent casing)
New convenience overload for beginUpdateMemories

Wrapping up

The headline for .NET developers this month is Azure.AI.Projects 2.0.0 hitting stable — if you’re building with AI Foundry, now’s the time to pin to stable and update your imports. For Java shops using Cosmos DB, the security update is urgent.

Full release notes at aka.ms/azsdk/releases. Original post: Azure SDK Release (April 2026).

Azure MCP Server 2.0 Just Dropped — Self-Hosted Agentic Cloud Automation Is Here

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

If you’ve been building anything with MCP and Azure lately, you probably already know the local experience works well. Plug in an MCP server, let your AI agent talk to Azure resources, move on. But the moment you need to share that setup across a team? That’s where things got complicated.

Not anymore. Azure MCP Server just hit 2.0 stable, and the headline feature is exactly what enterprise teams have been asking for: self-hosted remote MCP server support.

What’s Azure MCP Server?

Quick refresher. Azure MCP Server implements the Model Context Protocol specification and exposes Azure capabilities as structured, discoverable tools that AI agents can invoke. Think of it as a standardized bridge between your agent and Azure — provisioning, deployment, monitoring, diagnostics, all through one consistent interface.

The numbers speak for themselves: 276 MCP tools across 57 Azure services. That’s serious coverage.

The big deal: self-hosted remote deployments

Here’s the thing. Running MCP locally on your machine is fine for dev and experiments. But in a real team scenario, you need:

Shared access for developers and internal agent systems
Centralized configuration (tenant context, subscription defaults, telemetry)
Enterprise network and policy boundaries
Integration into CI/CD pipelines

Azure MCP Server 2.0 addresses all of this. You can deploy it as a centrally managed internal service with HTTP-based transport, proper authentication, and consistent governance.

For auth, you get two solid options:

Managed Identity — when running alongside Microsoft Foundry
On-Behalf-Of (OBO) flow — OpenID Connect delegation that calls Azure APIs using the signed-in user’s context

That OBO flow is particularly interesting for us .NET developers. It means your agentic workflows can operate with the user’s actual permissions, not some over-privileged service account. Principle of least privilege, built right in.

Security hardening

This isn’t just a feature release — it’s a security one too. The 2.0 release adds:

Stronger endpoint validation
Protections against injection patterns in query-oriented tools
Tighter isolation controls for dev environments

If you’re going to expose MCP as a shared service, these safeguards matter. A lot.

Where can you use it?

The client compatibility story is broad. Azure MCP Server 2.0 works with:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agents: GitHub Copilot CLI, Claude Code
Standalone: local server for simple setups
Self-hosted remote: the new star of 2.0

Plus there’s sovereign cloud support for Azure US Government and Azure operated by 21Vianet, which is critical for regulated deployments.

Why this matters for .NET developers

If you’re building agentic applications with .NET — whether that’s Semantic Kernel, Microsoft Agent Framework, or your own orchestration — Azure MCP Server 2.0 gives you a production-ready way to let your agents interact with Azure infrastructure. No custom REST wrappers. No service-specific integration patterns. Just MCP.

Combined with the fluent API for MCP Apps that dropped a few days ago, the .NET MCP ecosystem is maturing fast.

Getting started

Pick your path:

GitHub Repo — source code, docs, everything
Docker Image — containerized deployment
VS Code Extension — IDE integration
Self-hosting guide — the 2.0 flagship feature

Wrapping up

Azure MCP Server 2.0 is exactly the kind of infrastructure upgrade that doesn’t look flashy in a demo but changes everything in practice. Self-hosted remote MCP with proper auth, security hardening, and sovereign cloud support means MCP is ready for real teams building real agentic workflows on Azure. If you’ve been waiting for the “enterprise-ready” signal — this is it.

MCP Apps Get a Fluent API — Build Rich AI Tool UIs in .NET with Three Steps

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP tools are great for giving AI agents capabilities. But what if your tool needs to show something to the user — a dashboard, a form, an interactive visualization? That’s where MCP Apps come in, and they just got a lot easier to build.

Lilian Kasem from the Azure SDK team introduced the new fluent configuration API for MCP Apps on .NET Azure Functions, and it’s the kind of developer experience improvement that makes you wonder why it wasn’t always this simple.

What are MCP Apps?

MCP Apps extend the Model Context Protocol by letting tools carry their own UI views, static assets, and security controls. Instead of just returning text, your MCP tool can render full HTML experiences — interactive dashboards, data visualizations, configuration forms — all invocable by AI agents and presented to users by MCP clients.

The catch was that wiring all this up manually required knowing the MCP spec intimately: ui:// URIs, special mime types, metadata coordination between tools and resources. Not hard, but fiddly.

The fluent API in three steps

Step 1: Define your function. Just a standard Azure Functions MCP tool:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Step 2: Promote it to an MCP App. In your program startup:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Step 3: Add your HTML view. Create assets/hello-app.html with whatever UI you need.

That’s it. The fluent API handles all the MCP spec plumbing — generating the synthetic resource function, setting the correct mime type, injecting the metadata that connects your tool to its view.

The API surface is well-designed

A few things I really like:

View sources are flexible. You can serve HTML from files on disk, or embed resources directly in your assembly for self-contained deployments:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP is composable. You explicitly allowlist origins your app needs, following least-privilege principles. Call WithCsp multiple times and origins accumulate:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Visibility control. You can make a tool visible to the LLM only, the host UI only, or both. Want a tool that only renders UI and shouldn’t be called by the model? Easy:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Getting started

Add the preview package:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

If you’re already building MCP tools with Azure Functions, this is just a package update. The MCP Apps quickstart is the best place to start if you’re new to the concept.

Wrapping up

MCP Apps are one of the more exciting developments in the AI tooling space — tools that don’t just do things but can show things to users. The fluent API removes the protocol complexity and lets you focus on what matters: your tool’s logic and its UI.

Read the full post for the complete API reference and examples.