Azure SDK | The .NET Blog

Pare de Bombardear uma Dependência em Dificuldades: Padrões de Retry para Azure Functions + Service Bus

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

Veja como uma falha recuperável se torna uma interrupção em um aplicativo Functions: uma dependência começa a dar timeout, cada instância Functions tenta novamente imediatamente e indefinidamente, a dependência é bombardeada com centenas de requisições com falha concorrentes, e o que começou como um soluço transitório se torna um evento de contrapressão em todo o sistema.

Você provavelmente conhece essa história. Azure Functions escala rapidamente — esse é todo o ponto. Mas “escalar rapidamente” e “tentar novamente imediatamente” juntos podem piorar dramaticamente as falhas.

Dois padrões ajudam. Exponential backoff e circuit breaker. Ambos agora são suportados nativamente para Azure Functions acionadas pelo Service Bus.

Dois Padrões, Papéis Diferentes

Esses padrões são complementares, não alternativos:

O exponential backoff responde a: quando devo tentar novamente? Aumenta o atraso entre as tentativas para que uma dependência tenha tempo de se recuperar. No nível da mensagem, regulando o tempo de retry.

O circuit breaker responde a: devo chamar essa dependência agora? Interrompe chamadas repetidas a uma dependência não saudável após atingir um limiar de falhas e, em seguida, sonda cuidadosamente após um período de resfriamento. No nível do sistema, prevenindo tempestades de retry.

Você quer os dois. O backoff gerencia o ritmo de retry por mensagem. O circuit breaker gerencia as decisões de saúde agregadas.

Por Que Isso Importa Especialmente para Service Bus

A fila absorve o tráfego em rajadas, o que é bom. Mas sem controles, a fila pode crescer enquanto os workers continuam desperdiçando recursos de computação em chamadas que vão falhar. Mensagens envenenadas ficam ativas por mais tempo do que deveriam. Partições quentes ou capacidade downstream limitada criam problemas em cascata.

O design mais seguro:

Detectar a falha transitória
Atrasar a próxima tentativa com exponential backoff
Parar de chamar a dependência quando um limiar de falha é atingido (circuito aberto)
Retomar cuidadosamente após um período de resfriamento (sonda de circuito)
Mover o trabalho irrecuperável para dead-letter ou um caminho de quarentena

Como É o Suporte Nativo

O novo suporte se integra com o modelo de host Azure Functions existente — sem bibliotecas extras, sem implementações personalizadas. A configuração vai no seu host.json:

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

A configuração do circuit breaker define o limiar de falha e o intervalo de reset para que dependências não saudáveis não sejam bombardeadas durante a recuperação.

Linguagens Cobertas

Isso não é apenas para .NET. O recurso cobre dotnet, JavaScript, TypeScript e Python — o conjunto completo de linguagens suportadas pelo trigger Service Bus no Azure Functions.

Conclusão

Os padrões de retry não são emocionantes de configurar até a primeira vez que uma interrupção downstream faz com que suas Functions piorem o problema em vez de degradar graciosamente. Configurá-los proativamente é barato. Adaptá-los durante um incidente não é.

Post original: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

Azure SDK Abril 2026: AI Foundry 2.0 e o Que Desenvolvedores .NET Devem Saber

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

Esta postagem foi traduzida automaticamente. Para a versão original, clique aqui.

Lançamentos mensais do SDK são fáceis de ignorar. Este tem algumas coisas que merecem atenção — especialmente se você constrói com AI Foundry, Cosmos DB em Java, ou faz provisionamento de infraestrutura a partir de código .NET.

Azure.AI.Projects 2.0.0 — Breaking Changes que Fazem Sentido

Splits de namespace, tipos renomeados, e convenção Is* consistente para booleanos.

Cosmos DB Java: Correção Crítica de Segurança (RCE)

Versão 4.79.0 corrige vulnerabilidade de Execução Remota de Código (CWE-502). Atualize imediatamente.

Novas Bibliotecas de Provisioning para .NET

Post original: Azure SDK Release (April 2026).

O Azure MCP Server Agora é um .mcpb — Instale-o sem Nenhum Runtime

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Sabe o que era chato na configuração de servidores MCP? Você precisava de um runtime. Node.js para a versão npm, Python para pip/uvx, .NET SDK para a variante dotnet.

O Azure MCP Server acabou de mudar isso. Agora está disponível como .mcpb — um MCP Bundle — e a configuração é arrastar e soltar.

O que é um MCP Bundle?

Pense como uma extensão do VS Code (.vsix) ou extensão de navegador (.crx), mas para servidores MCP. Um arquivo .mcpb é um arquivo ZIP independente que inclui o binário do servidor e todas as suas dependências.

Como instalar

1. Baixe o bundle para sua plataforma

Vá para a página de GitHub Releases e baixe o arquivo .mcpb para seu OS e arquitetura.

2. Instale no Claude Desktop

O mais fácil: arraste e solte o arquivo .mcpb na janela do Claude Desktop na página de configurações de Extensões (☰ → Arquivo → Configurações → Extensões). Revise os detalhes, clique em Instalar, confirme.

3. Autentique no Azure

az login

Só isso. O Azure MCP Server usa suas credenciais Azure existentes.

O que você pode fazer

Mais de 100 ferramentas de serviços Azure diretamente do seu cliente IA:

Consultar e gerenciar Cosmos DB, Storage, Key Vault, App Service, Foundry
Gerar comandos az CLI para qualquer tarefa
Criar templates Bicep e Terraform

Para começar

Download: GitHub Releases
Repositório: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Veja o post completo.

Azure MCP Server 2.0 Chegou — Automação Agnóstica em Nuvem Self-Hosted Está Aqui

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

Este artigo foi traduzido automaticamente. Para a versão original, clique aqui.

Se você vem construindo algo com MCP e Azure ultimamente, provavelmente já sabe que a experiência local funciona bem. Coloque um servidor MCP, deixe seu agente IA falar com recursos do Azure, siga em frente. Mas no momento em que você precisa compartilhar essa configuração com um time? É aí que as coisas ficavam complicadas.

Não mais. Azure MCP Server acabou de atingir a versão 2.0 estável, e a feature principal é exatamente o que times empresariais estão pedindo: suporte para servidor MCP remoto self-hosted.

O que é Azure MCP Server?

Um rápido refresco. Azure MCP Server implementa a especificação do Model Context Protocol e expõe capacidades do Azure como ferramentas estruturadas e descobríveis que agentes IA podem invocar. Pense nisto como uma ponte padronizada entre seu agente e o Azure — provisionamento, implantação, monitoramento, diagnósticos, tudo através de uma interface consistente.

Os números falam por si: 276 ferramentas MCP em 57 serviços do Azure. Isso é cobertura séria.

O grande destaque: implantações remotas self-hosted

Aqui está a questão. Executar MCP localmente na sua máquina é bom para dev e experimentos. Mas em um cenário real de time, você precisa de:

Acesso compartilhado para desenvolvedores e sistemas de agentes internos
Configuração centralizada (contexto de tenant, padrões de assinatura, telemetria)
Limites de rede e política empresariais
Integração em pipelines CI/CD

Azure MCP Server 2.0 aborda tudo isso. Você pode implantá-lo como um serviço interno gerenciado centralmente com transporte baseado em HTTP, autenticação apropriada e governança consistente.

Para autenticação, você tem duas opções sólidas:

Managed Identity — quando em execução junto com Microsoft Foundry
Fluxo On-Behalf-Of (OBO) — delegação OpenID Connect que chama APIs do Azure usando o contexto do usuário autenticado

Esse fluxo OBO é particularmente interessante para nós desenvolvedores .NET. Significa que seus fluxos de trabalho agnósticos podem operar com as permissões reais do usuário, não alguma conta de serviço com privilégios excessivos. Princípio do menor privilégio, embutido certo.

Endurecimento de segurança

Isso não é apenas um lançamento de feature — é um de segurança também. O lançamento 2.0 adiciona:

Validação de endpoint mais forte
Proteções contra padrões de injeção em ferramentas orientadas a query
Controles de isolamento mais rigorosos para ambientes de dev

Se você vai expor MCP como um serviço compartilhado, essas salvaguardas importam. Muito.

Onde você pode usá-lo?

A história de compatibilidade do cliente é ampla. Azure MCP Server 2.0 funciona com:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agentes CLI: GitHub Copilot CLI, Claude Code
Standalone: servidor local para configurações simples
Self-hosted remoto: a nova estrela do 2.0

Além disso há suporte a nuvem soberana para Azure US Government e Azure operado pela 21Vianet, que é crítico para implantações reguladas.

Por que isso importa para desenvolvedores .NET

Se você está construindo aplicações agnósticas com .NET — seja com Semantic Kernel, Microsoft Agent Framework, ou sua própria orquestração — Azure MCP Server 2.0 lhe dá uma maneira pronta para produção de deixar seus agentes interagirem com infraestrutura do Azure. Sem wrappers REST customizados. Sem padrões de integração específicos do serviço. Apenas MCP.

Combinado com a API fluente para MCP Apps que saiu alguns dias atrás, o ecossistema MCP .NET está amadurecendo rapidamente.

Começando

Escolha seu caminho:

Repositório GitHub — código fonte, documentação, tudo
Imagem Docker — implantação containerizada
Extensão VS Code — integração de IDE
Guia de self-hosting — a feature principal do 2.0

Resumindo

Azure MCP Server 2.0 é exatamente o tipo de upgrade de infraestrutura que não parece vistoso em uma demo mas muda tudo na prática. MCP remoto self-hosted com autenticação apropriada, endurecimento de segurança e suporte a nuvem soberana significa que MCP está pronto para times reais construindo fluxos de trabalho agnósticos reais no Azure. Se você estava esperando o sinal “pronto para empresas” — esse é ele.

MCP Apps ganham uma API fluente — Construa interfaces ricas para ferramentas de IA em .NET em três passos

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Ferramentas MCP são ótimas para dar capacidades aos agentes de IA. Mas e se a sua ferramenta precisa mostrar algo ao usuário — um dashboard, um formulário, uma visualização interativa? É aí que entram as MCP Apps, e elas ficaram muito mais fáceis de construir.

Lilian Kasem da equipe do Azure SDK apresentou a nova API de configuração fluente para MCP Apps no Azure Functions com .NET, e é o tipo de melhoria na experiência do desenvolvedor que faz a gente se perguntar por que não era sempre assim tão simples.

O que são MCP Apps?

MCP Apps estendem o Model Context Protocol permitindo que as ferramentas carreguem suas próprias views de UI, assets estáticos e controles de segurança. Em vez de apenas retornar texto, sua ferramenta MCP pode renderizar experiências HTML completas — dashboards interativos, visualizações de dados, formulários de configuração — tudo invocável por agentes de IA e apresentado aos usuários pelos clientes MCP.

O problema era que conectar tudo isso manualmente exigia conhecer a especificação MCP a fundo: URIs ui://, tipos MIME especiais, coordenação de metadados entre ferramentas e recursos. Não era difícil, mas trabalhoso.

A API fluente em três passos

Passo 1: Defina sua função. Uma ferramenta MCP padrão do Azure Functions:

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

Passo 2: Promova-a a MCP App. No startup do seu programa:

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");
 }));

Passo 3: Adicione sua view HTML. Crie assets/hello-app.html com a interface que você precisa.

É isso. A API fluente cuida de toda a encanação do protocolo MCP — gera a função de recurso sintético, define o tipo MIME correto e injeta os metadados que conectam sua ferramenta à sua view.

A superfície da API é bem projetada

Algumas coisas que eu realmente gosto:

As fontes de views são flexíveis. Você pode servir HTML a partir de arquivos no disco, ou embutir recursos diretamente no seu assembly para deploys independentes:

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

O CSP é componível. Você permite explicitamente as origens que sua app precisa, seguindo princípios de menor privilégio. Chame WithCsp várias vezes e as origens se acumulam:

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

Controle de visibilidade. Você pode tornar uma ferramenta visível apenas para o LLM, apenas para a UI do host, ou ambos. Quer uma ferramenta que só renderiza UI e não deve ser chamada pelo modelo? Fácil:

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

Primeiros passos

Adicione o pacote preview:

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

Se você já está construindo ferramentas MCP com Azure Functions, isso é apenas uma atualização de pacote. O quickstart de MCP Apps é o melhor lugar para começar se você é novo no conceito.

Finalizando

MCP Apps são um dos desenvolvimentos mais empolgantes no espaço de ferramentas de IA — ferramentas que não apenas fazem coisas, mas podem mostrar coisas aos usuários. A API fluente remove a complexidade do protocolo e permite que você se concentre no que importa: a lógica da sua ferramenta e sua interface.

Leia o post completo para a referência completa da API e exemplos.