Azure SDK | The .NET Blog

Deja de Martillar una Dependencia en Dificultades: Patrones de Reintento para Azure Functions + Service Bus

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

Aquí te explicamos cómo una falla recuperable se convierte en una interrupción en una aplicación de Functions: una dependencia comienza a dar timeout, cada instancia de Function reintenta inmediatamente e indefinidamente, la dependencia recibe cientos de solicitudes fallidas concurrentes, y lo que comenzó como un problema transitorio se convierte en un evento de contrapresión en todo el sistema.

Probablemente conoces esta historia. Azure Functions escala rápidamente — ese es todo el punto. Pero “escalar rápidamente” y “reintentar inmediatamente” juntos pueden empeorar dramáticamente las fallas.

Dos patrones ayudan. Retroceso exponencial y circuit breaker. Ambos ahora son compatibles de forma nativa para Azure Functions activadas por Service Bus.

Dos Patrones, Roles Diferentes

Estos patrones son complementarios, no alternativas:

El retroceso exponencial responde: ¿cuándo debería intentarlo de nuevo? Aumenta el retraso entre reintentos para que una dependencia tenga tiempo de recuperarse. A nivel de mensaje, marcando el ritmo del temporizador de reintento.

El circuit breaker responde: ¿debería llamar a esta dependencia ahora mismo? Detiene las llamadas repetidas a una dependencia poco saludable después de alcanzar un umbral de fallas, y luego sondea cuidadosamente después de un período de enfriamiento. A nivel de sistema, previniendo tormentas de reintentos.

Quieres ambos. El retroceso maneja el ritmo de reintento por mensaje. El circuit breaker maneja las decisiones de salud agregadas.

Por Qué Importa Especialmente para Service Bus

La cola absorbe el tráfico en ráfagas, lo que es bueno. Pero sin controles, la cola puede crecer mientras los workers continúan desperdiciando cómputo en llamadas que fallarán. Los mensajes envenenados permanecen activos más tiempo del que deberían. Las particiones calientes o la capacidad aguas abajo limitada crean problemas en cascada.

El diseño más seguro:

Detectar la falla transitoria
Retrasar el próximo intento con retroceso exponencial
Detener las llamadas a la dependencia cuando se alcanza un umbral de fallas (circuito abierto)
Reanudar cuidadosamente después de un período de enfriamiento (sonda de circuito)
Mover el trabajo irrecuperable a dead-letter o a una ruta de cuarentena

Cómo se Ve el Soporte Nativo

El nuevo soporte se integra con el modelo de host existente de Azure Functions — sin bibliotecas adicionales, sin implementaciones personalizadas. La configuración va en tu host.json:

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

La configuración del circuit breaker establece el umbral de fallas y el intervalo de restablecimiento para que las dependencias poco saludables no sean acosadas durante la recuperación.

Lenguajes Cubiertos

Esto no es solo para .NET. La funcionalidad cubre dotnet, JavaScript, TypeScript y Python — el conjunto completo de lenguajes compatibles con el trigger de Service Bus en Azure Functions.

Conclusión

Los patrones de reintento no son emocionantes de configurar hasta la primera vez que una interrupción aguas abajo hace que tus Functions empeoren el problema en lugar de degradarse correctamente. Configurarlos de manera proactiva es barato. Implementarlos durante un incidente no lo es.

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

Azure SDK Abril 2026: AI Foundry 2.0 y Lo Que Deben Saber los Desarrolladores .NET

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Los lanzamientos mensuales del SDK son fáciles de ignorar. Este tiene algunas cosas que vale la pena atender — especialmente si construyes con AI Foundry, Cosmos DB en Java, o haces aprovisionamiento de infraestructura desde código .NET.

Azure.AI.Projects 2.0.0 — Cambios Breaking que Tienen Sentido

El paquete NuGet Azure.AI.Projects alcanza la versión estable 2.0.0 con cambios arquitectónicos significativos:

Divisiones de namespace: Evaluaciones movidas a Azure.AI.Projects.Evaluation, operaciones de memoria a Azure.AI.Projects.Memory
Tipos renombrados: Insights → ProjectInsights, Schedules → ProjectSchedules, etc.
Convenciones de nomenclatura: Propiedades booleanas siguen consistentemente la convención Is*

Estos son los cambios breaking que duelen una vez y luego se sienten correctos para siempre.

Cosmos DB Java: Corrección Crítica de Seguridad (RCE)

Esta es seria. La biblioteca Java Cosmos DB versión 4.79.0 incluye una corrección crítica para una vulnerabilidad de Ejecución Remota de Código (CWE-502).

Si tienes servicios Java usando Azure Cosmos DB, actualiza a 4.79.0 inmediatamente.

Nuevas Bibliotecas de Provisioning para .NET

Varias bibliotecas estables de Provisioning llegan a 1.0.0:

Resumiendo

Lo más destacado para desarrolladores .NET es Azure.AI.Projects 2.0.0 alcanzando estabilidad. Post original: Azure SDK Release (April 2026).

El Azure MCP Server Ahora es un .mcpb — Instálalo sin Ningún Runtime

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

¿Sabes qué era molesto de configurar servidores MCP? Necesitabas un runtime. Node.js para la versión npm, Python para pip/uvx, .NET SDK para la variante dotnet, Docker si querías contenedores. Solo para conectar una herramienta a tu cliente IA.

El Azure MCP Server acaba de cambiar eso. Ahora está disponible como .mcpb — un MCP Bundle — y la configuración es arrastrar y soltar.

¿Qué es un MCP Bundle?

Piénsalo como una extensión de VS Code (.vsix) o una extensión de navegador (.crx), pero para servidores MCP. Un archivo .mcpb es un archivo ZIP autónomo que incluye el binario del servidor y todas sus dependencias. Todo lo necesario para ejecutarlo en tu plataforma, empaquetado junto.

El resultado: descargas un archivo, lo abres en un cliente compatible y el servidor funciona. Sin runtime que instalar, sin package.json que gestionar, sin conflictos de versiones.

Cómo instalarlo

1. Descarga el bundle para tu plataforma

Ve a la página de GitHub Releases y descarga el archivo .mcpb para tu OS y arquitectura. Asegúrate de elegir el correcto — osx-arm64 para Apple Silicon, osx-x64 para Mac Intel, etc.

2. Instala en Claude Desktop

La forma más fácil: arrastra y suelta el archivo .mcpb en la ventana de Claude Desktop mientras estás en la página de configuración de Extensiones (☰ → Archivo → Configuración → Extensiones). Revisa los detalles del servidor, haz clic en Instalar y confirma.

3. Autentícate en Azure

az login

Eso es todo. El Azure MCP Server usa tus credenciales de Azure existentes.

Qué puedes hacer con él

Una vez instalado, tienes acceso a más de 100 herramientas de servicios Azure directamente desde tu cliente IA:

Consultar y administrar Cosmos DB, Storage, Key Vault, App Service, Foundry
Generar comandos az CLI para cualquier tarea
Crear plantillas Bicep y Terraform
Obtener recomendaciones de arquitectura y diagnósticos

Prueba prompts como:

“Lista todos los grupos de recursos en mi suscripción”
“Genera una plantilla Bicep para una app web con base de datos SQL”

¿Qué método de instalación usar?

Método	Ideal para
`.mcpb`	Usuarios de Claude Desktop que quieren cero configuración
Extensión VS Code	Desarrolladores en VS Code + GitHub Copilot
npm/npx	Desarrolladores que ya tienen Node.js
Docker	Pipelines CI/CD y contenedores

Para empezar

Descarga: GitHub Releases
Repositorio: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Consulta el post completo para consejos de solución de problemas.

Azure MCP Server 2.0 Acaba de Llegar — La Automatización Agentic en la Nube Auto-Alojada ya Está Aquí

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

Este artículo fue traducido automáticamente. Para la versión original, haz clic aquí.

Si has estado construyendo algo con MCP y Azure últimamente, probablemente ya sepas que la experiencia local funciona bien. Conecta un servidor MCP, deja que tu agente de IA hable con recursos de Azure, y continúa. Pero en el momento en que necesitas compartir esa configuración entre un equipo? Ahí es donde las cosas se complicaban.

Ya no más. Azure MCP Server acaba de alcanzar 2.0 estable, y la característica principal es exactamente lo que los equipos empresariales han estado pidiendo: soporte para servidor MCP remoto auto-alojado.

¿Qué es Azure MCP Server?

Un repaso rápido. Azure MCP Server implementa la especificación del Protocolo de Contexto del Modelo y expone capacidades de Azure como herramientas estructuradas y detectables que los agentes de IA pueden invocar. Piénsalo como un puente estandarizado entre tu agente y Azure — provisioning, implementación, monitoreo, diagnósticos, todo a través de una interfaz consistente.

Los números hablan por sí solos: 276 herramientas MCP en 57 servicios de Azure. Esa es una cobertura seria.

Lo importante: implementaciones remotas auto-alojadas

Aquí está la cosa. Ejecutar MCP localmente en tu máquina está bien para desarrollo y experimentos. Pero en un escenario de equipo real, necesitas:

Acceso compartido para desarrolladores y sistemas de agentes internos
Configuración centralizada (contexto de tenant, valores predeterminados de suscripción, telemetría)
Límites de red y políticas empresariales
Integración en tuberías CI/CD

Azure MCP Server 2.0 aborda todo esto. Puedes desplegarlo como un servicio interno administrado centralmente con transporte basado en HTTP, autenticación adecuada y gobernanza consistente.

Para autenticación, tienes dos opciones sólidas:

Identidad Administrada — cuando se ejecuta junto a Microsoft Foundry
Flujo On-Behalf-Of (OBO) — delegación de OpenID Connect que llama a APIs de Azure usando el contexto del usuario conectado

Ese flujo OBO es particularmente interesante para nosotros los desarrolladores .NET. Significa que tus flujos de trabajo agentic pueden operar con los permisos reales del usuario, no con alguna cuenta de servicio con excesivos privilegios. Principio de privilegio mínimo, integrado desde el principio.

Endurecimiento de seguridad

Esto no es solo un lanzamiento de características — también es uno de seguridad. El lanzamiento 2.0 añade:

Validación de extremos más fuerte
Protecciones contra patrones de inyección en herramientas orientadas a consultas
Controles de aislamiento más estrictos para entornos de desarrollo

Si vas a exponer MCP como un servicio compartido, estas salvaguardas importan. Mucho.

¿Dónde puedes usarlo?

La historia de compatibilidad con clientes es amplia. Azure MCP Server 2.0 funciona con:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agentes CLI: GitHub Copilot CLI, Claude Code
Independiente: servidor local para configuraciones simples
Remoto auto-alojado: la nueva estrella de 2.0

Además hay soporte de nube soberana para Azure US Government y Azure operado por 21Vianet, que es crítico para implementaciones reguladas.

Por qué esto importa para desarrolladores .NET

Si estás construyendo aplicaciones agentic con .NET — ya sea Semantic Kernel, Microsoft Agent Framework, u orquestación propia — Azure MCP Server 2.0 te da una forma lista para producción de dejar que tus agentes interactúen con la infraestructura de Azure. Sin wrappers REST personalizados. Sin patrones de integración específicos del servicio. Solo MCP.

Combinado con la API fluida para MCP Apps que salió hace unos días, el ecosistema .NET MCP está madurando rápidamente.

Empezando

Elige tu ruta:

Repositorio de GitHub — código fuente, documentación, todo
Imagen de Docker — implementación contenedorizada
Extensión de VS Code — integración con IDE
Guía de auto-alojamiento — la característica insignia de 2.0

Resumiendo

Azure MCP Server 2.0 es exactamente el tipo de actualización de infraestructura que no se ve llamativa en una demostración pero lo cambia todo en la práctica. MCP remoto auto-alojado con autenticación adecuada, endurecimiento de seguridad y soporte de nube soberana significa que MCP está listo para equipos reales construyendo flujos de trabajo agentic reales en Azure. Si has estado esperando la señal de “listo para empresas” — esto es.

Las MCP Apps tienen una API fluida — Construye interfaces ricas para herramientas de IA en .NET en tres pasos

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Las herramientas MCP son geniales para darle capacidades a los agentes de IA. Pero ¿qué pasa si tu herramienta necesita mostrarle algo al usuario — un dashboard, un formulario, una visualización interactiva? Ahí es donde entran las MCP Apps, y ahora son mucho más fáciles de construir.

Lilian Kasem del equipo de Azure SDK presentó la nueva API de configuración fluida para MCP Apps en Azure Functions con .NET, y es el tipo de mejora en experiencia de desarrollador que te hace preguntarte por qué no fue siempre así de simple.

¿Qué son las MCP Apps?

Las MCP Apps extienden el Model Context Protocol permitiendo que las herramientas lleven sus propias vistas de UI, assets estáticos y controles de seguridad. En lugar de solo devolver texto, tu herramienta MCP puede renderizar experiencias HTML completas — dashboards interactivos, visualizaciones de datos, formularios de configuración — todo invocable por agentes de IA y presentado a los usuarios por clientes MCP.

El problema era que conectar todo esto manualmente requería conocer la especificación MCP a fondo: URIs ui://, tipos MIME especiales, coordinación de metadatos entre herramientas y recursos. No era difícil, pero sí tedioso.

La API fluida en tres pasos

Paso 1: Define tu función. Una herramienta MCP de Azure Functions estándar:

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

Paso 2: Promuévela a MCP App. En el startup de tu 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");
 }));

Paso 3: Añade tu vista HTML. Crea assets/hello-app.html con la interfaz que necesites.

Eso es todo. La API fluida se encarga de toda la plomería del protocolo MCP — genera la función de recurso sintético, establece el tipo MIME correcto e inyecta los metadatos que conectan tu herramienta con su vista.

La superficie de la API está bien diseñada

Algunas cosas que me gustan mucho:

Las fuentes de las vistas son flexibles. Puedes servir HTML desde archivos en disco, o embeber recursos directamente en tu ensamblado para despliegues autónomos:

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

El CSP es componible. Explícitamente permites los orígenes que tu app necesita, siguiendo principios de mínimo privilegio. Llama a WithCsp varias veces y los orígenes se acumulan:

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

Control de visibilidad. Puedes hacer que una herramienta sea visible solo para el LLM, solo para la UI del host, o ambos. ¿Quieres una herramienta que solo renderice UI y no deba ser llamada por el modelo? Fácil:

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

Primeros pasos

Añade el paquete preview:

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

Si ya estás construyendo herramientas MCP con Azure Functions, esto es solo una actualización de paquete. El quickstart de MCP Apps es el mejor lugar para empezar si eres nuevo en el concepto.

Para cerrar

Las MCP Apps son uno de los desarrollos más emocionantes en el espacio de herramientas de IA — herramientas que no solo hacen cosas sino que pueden mostrar cosas a los usuarios. La API fluida elimina la complejidad del protocolo y te permite enfocarte en lo que importa: la lógica de tu herramienta y su interfaz.

Lee el post completo para la referencia completa de la API y ejemplos.