Desde el 19 de marzo de 2026, el Azure DevOps Remote MCP Server puede añadirse como herramienta en Microsoft Foundry en preview. Es una novedad relevante para quienes están construyendo agentes que necesitan interactuar con proyectos reales de Azure DevOps, pero conviene explicarla con precisión: no convierte Foundry en un sistema CI/CD, ni sustituye a Azure DevOps. Añade una capa estandarizada para que un agente pueda invocar capacidades de Azure DevOps como herramientas.
Qué es MCP y por qué importa aquí
MCP son las siglas de Model Context Protocol. Es un protocolo pensado para conectar aplicaciones y agentes de IA con herramientas externas de forma más uniforme. En lugar de que cada agente tenga que implementar integraciones específicas contra cada API, puede conectarse a un MCP Server que expone herramientas invocables.
En este caso, el Azure DevOps Remote MCP Server es la versión hospedada del servidor MCP para Azure DevOps. Microsoft ya había publicado una versión local del servidor, pero esa opción requería instalación y configuración en el entorno del usuario o del equipo. La versión remota reduce esa fricción: está hospedada por el servicio, utiliza transporte HTTP y permite conectar clientes compatibles sin desplegar un servidor local.
La secuencia de anuncios es importante:
- El 17 de marzo de 2026, Microsoft anunció la preview pública del Azure DevOps Remote MCP Server.
- El 19 de marzo de 2026, Microsoft anunció que ese servidor remoto ya estaba disponible para usarse desde Microsoft Foundry.
Por tanto, la novedad no es solo que exista un MCP Server para Azure DevOps, sino que ahora puede añadirse directamente a agentes creados en Foundry desde su catálogo de herramientas.
Qué permite hacer en Microsoft Foundry
La integración se realiza desde la experiencia de herramientas de Foundry. El flujo descrito por Microsoft es directo:
- Ir a Add Tools.
- Abrir el Catalog.
- Buscar Azure DevOps.
- Seleccionar Azure DevOps MCP Server (preview).
- Indicar la organización de Azure DevOps que se quiere conectar.
- Configurar qué herramientas estarán disponibles para el agente.
A partir de ahí, el agente puede invocar las herramientas que expone el servidor MCP de Azure DevOps, dentro de los permisos y capacidades disponibles en la preview. Microsoft menciona escenarios relacionados con datos y operaciones de Azure DevOps, como trabajar con elementos de trabajo, repositorios, wikis, pipelines u otros recursos del proyecto, siempre a través de las herramientas expuestas por el servidor.
La arquitectura conceptual es esta:
- El agente en Foundry recibe una instrucción del usuario o de un flujo automatizado.
- El agente decide si necesita usar una herramienta externa.
- Si corresponde, invoca una herramienta del Azure DevOps Remote MCP Server.
- El servidor MCP actúa como intermediario frente a Azure DevOps.
- Azure DevOps ejecuta la operación o devuelve la información solicitada.
- El agente recibe el resultado y continúa la conversación o el flujo.
El matiz importante es este: Foundry no ejecuta pipelines por sí mismo y el MCP Server no es un motor CI/CD. Azure DevOps sigue siendo el sistema que gestiona repositorios, work items, pipelines y demás capacidades DevOps. El MCP Server es la capa de acceso que permite que un agente interactúe con esas capacidades de forma controlada.
Qué no significa todavía
Aunque la integración es prometedora, sigue estando en preview y tiene límites que conviene tener presentes antes de diseñar flujos críticos sobre ella.
No sustituye a Azure DevOps
El Remote MCP Server no reemplaza Azure Boards, Azure Repos ni Azure Pipelines. Tampoco elimina la necesidad de diseñar correctamente los permisos, ramas, políticas de aprobación, validaciones o entornos de despliegue.
Lo que aporta es una forma de que un agente pueda consultar o accionar capacidades de Azure DevOps mediante herramientas MCP.
No todos los escenarios están cubiertos
Microsoft posiciona esta preview como un paso más en la evolución del servidor MCP de Azure DevOps. La versión remota soporta los escenarios principales del servidor local, pero el alcance exacto depende de las herramientas disponibles y del cliente que se use.
Además, al estar en preview, el comportamiento, la cobertura de herramientas y los requisitos de integración pueden cambiar antes de disponibilidad general.
Requiere tener en cuenta identidad y compatibilidad
Según el anuncio de Microsoft, el Remote MCP Server está orientado a organizaciones de Azure DevOps respaldadas por Microsoft Entra. Las organizaciones que dependen únicamente de cuentas Microsoft personales no forman parte del escenario soportado en esta preview.
También es relevante distinguir entre clientes compatibles y clientes que todavía requieren trabajo adicional. Microsoft indica que algunas experiencias necesitan soporte de registro OAuth dinámico en Microsoft Entra para poder integrarse correctamente. Por tanto, no conviene asumir que cualquier cliente MCP remoto funcionará sin restricciones desde el primer día.
Por qué es relevante para equipos técnicos
La relevancia real de esta integración no está en “meter IA” en DevOps de forma genérica, sino en habilitar un patrón bastante concreto: agentes capaces de operar sobre información y flujos de Azure DevOps con contexto del proyecto.
Algunos ejemplos razonables de uso serían:
- Consultar el estado de work items de una iteración.
- Resumir elementos pendientes de un equipo.
- Crear tareas a partir de una conversación o de requisitos funcionales.
- Revisar información de repositorios o wikis.
- Solicitar la ejecución de una pipeline si esa herramienta está habilitada y el usuario tiene permisos.
- Ayudar a un responsable técnico a navegar por el estado de un proyecto sin entrar manualmente en varias pantallas.
El patrón correcto no es:
Foundry reemplaza Azure DevOps Pipelines.
El patrón correcto es:
Un agente en Foundry puede usar Azure DevOps como una herramienta externa para asistir flujos de trabajo de ingeniería.
Esa diferencia importa. En arquitecturas empresariales, lo recomendable seguirá siendo mantener los controles de Azure DevOps: permisos, políticas de rama, aprobaciones, checks, auditoría y separación de entornos. La capa de agente debe consumir esos controles, no evitarlos.
Cómo empezar
Para probar el Remote MCP Server fuera de Foundry, Microsoft muestra un ejemplo de configuración en mcp.json para clientes compatibles:
{
"servers": {
"ado-remote-mcp": {
"url": "https://mcp.dev.azure.com/{organization}",
"type": "http"
}
}
}
En el caso de Microsoft Foundry, el proceso no requiere editar ese archivo manualmente desde la experiencia descrita por Microsoft. El flujo es:
- Abrir el agente en Foundry.
- Ir a Add Tools.
- Seleccionar Catalog.
- Buscar Azure DevOps.
- Añadir Azure DevOps MCP Server (preview).
- Conectar la organización de Azure DevOps.
- Elegir qué herramientas se exponen al agente.
La recomendación práctica es empezar con un conjunto reducido de herramientas y ampliar solo cuando el caso de uso lo justifique. En agentes con capacidad de ejecutar acciones, limitar permisos y herramientas disponibles es tan importante como diseñar buenos prompts.
Consideraciones de arquitectura
Si vas a evaluar esta preview en un entorno profesional, merece la pena revisar al menos estos puntos:
- Identidad y permisos: el agente no debería tener más capacidad de la necesaria. Los permisos de Azure DevOps siguen siendo una frontera de seguridad crítica.
- Trazabilidad: cualquier acción relevante sobre work items, repositorios o pipelines debería quedar auditada en los sistemas correspondientes.
- Separación de entornos: no conviene mezclar pruebas de agentes con pipelines o proyectos de producción sin controles adicionales.
- Herramientas expuestas: no todas las herramientas tienen el mismo riesgo. Consultar información no es lo mismo que disparar una pipeline o modificar artefactos.
- Estado de preview: evita depender de esta integración para procesos críticos sin un plan de contingencia.
Fuentes oficiales
Conclusión
El Azure DevOps Remote MCP Server en Microsoft Foundry es una integración útil y bien alineada con la dirección actual de los agentes empresariales: conectar modelos y agentes con herramientas reales, manteniendo los sistemas de origen como fuente de verdad.
No convierte Foundry en un reemplazo de Azure DevOps. No sustituye pipelines, repositorios, boards ni políticas de gobierno. Lo que permite es que un agente pueda interactuar con Azure DevOps como una herramienta externa, dentro de las capacidades y límites de la preview.
Para equipos que ya trabajan con Azure DevOps y están explorando agentes en Foundry, es una pieza a seguir de cerca. La clave será usarla con expectativas correctas: menos “automatización mágica” y más integración controlada entre agentes e ingeniería de software.