|

Azure DevOps MCP ya está en GA (pero Claude queda afuera)

“`html

En pocas palabras: Sí. Microsoft anunció la disponibilidad general del Azure DevOps Remote MCP Server en agosto de 2026, accesible en mcp.dev.azure.com sobre streamable HTTP. Sin embargo, no soporta clientes de terceros como Claude, ChatGPT o Cursor, porque la autenticación exige Microsoft Entra ID.

Microsoft anunció en agosto de 2026 la disponibilidad general del Azure DevOps Remote MCP Server, un endpoint alojado que expone work items, pull requests, repositorios y pipelines a asistentes de IA sin instalar nada. La integración con Claude, ChatGPT y Cursor, eso sí, sigue bloqueada.

El Azure DevOps Remote MCP Server es un servidor remoto del protocolo Model Context Protocol (MCP) operado por Microsoft, accesible en https://mcp.dev.azure.com/{organización} sobre streamable HTTP. Sirve para que un asistente de IA consulte y actualice datos de Azure DevOps en lenguaje natural, autenticando mediante Microsoft Entra ID. Esa dependencia de Entra es justo lo que hoy deja afuera a los clientes de terceros.

En 30 segundos

  • GA confirmada: Microsoft anunció la disponibilidad general del Remote MCP Server en agosto de 2026, según el informe de InfoQ.
  • Cero instalación: el endpoint corre en https://mcp.dev.azure.com/{organización} y conectar un cliente compatible exige agregar una entrada al mcp.json.
  • El bloqueo: Claude Desktop, Claude Code, ChatGPT y Cursor no pueden autenticarse porque Entra no soporta dynamic OAuth client registration ni Client ID Metadata Documents.
  • Quién sí entra: VS Code con GitHub Copilot, Visual Studio, Copilot Studio, GitHub Copilot CLI, la app de GitHub Copilot y Microsoft Foundry.
  • Sin fecha: Microsoft trabaja con el equipo de Entra, pero no publicó timeline; el servidor MCP local sigue siendo el camino para el resto.

¿Qué significa que el Remote MCP Server de Azure DevOps esté en GA?

Que salió de preview y que cualquier organización respaldada por un tenant de Entra puede usarlo hoy mismo. El endpoint lo hostea Microsoft, corre sobre streamable HTTP y es stateless, así que conectar un cliente compatible se reduce a sumar una línea en el mcp.json con la URL de tu organización.

Si alguna vez tuviste que explicarle a cinco developers cómo levantar el mismo servidor MCP local, sabés por qué esto es un golazo. Antes de este lanzamiento, cada equipo que quería un asistente conectado a Azure DevOps tenía que correr su propia instancia y lidiar con el manejo de credenciales que eso implica. Con el modelo alojado te olvidás de esa carga de un plumazo (y de paso sacás tokens personales de los archivos de configuración, que es otro cantar). Ya lo cubrimos antes en cómo pueden filtrarse tus secretos de CI/CD.

¿Por qué la integración de Azure DevOps MCP con Claude no funciona (todavía)?

Por la autenticación, no por una decisión comercial misteriosa. Claude Desktop, Claude Code, ChatGPT y Cursor requieren que Entra soporte dynamic OAuth client registration o Client ID Metadata Documents para poder conectarse, y hoy no soporta ninguno de los dos mecanismos. Así lo planteó Dan Hellem, product manager de Azure Boards, Repos y Wiki: el soporte depende de la capacidad de cada cliente de autenticarse con Entra, y Microsoft está trabajando con el equipo de Entra para habilitarlo. Falta saber cuándo.

¿Y cuándo se resuelve? Nadie lo sabe. Microsoft no publicó fecha ni ventana estimada, así que el horizonte oficial es “en algún momento” (spoiler: no sirve para planificar un trimestre).

Acá hay una ironía de fondo que vale nombrar. MCP nació con la promesa de “conectá cualquier asistente a cualquier herramienta”, y en el transporte ya casi la cumplió: headers estándar, servidores stateless, hosting trivial. Pero la capa de identidad de abajo sigue siendo territorio de cada vendor. Un protocolo puede estandarizar cómo un cliente descubre y llama herramientas, pero no puede obligar a un proveedor de identidad a dejarlo entrar.

¿Qué clientes de IA soportan el Remote MCP Server hoy?

Hoy entran sin fricción únicamente los clientes first-party de Microsoft, según la documentación oficial. La lista es corta y clara:

Cliente¿Remote MCP?Notas
VS Code + GitHub CopilotSin onboarding extra
Visual StudioSin onboarding extra
Copilot StudioNovedad, según Hellem
GitHub Copilot CLISin onboarding extra
App de GitHub CopilotSin onboarding extra
Microsoft FoundryVía catálogo de herramientas
Claude Desktop / Claude CodeNoRequiere servidor MCP local
ChatGPTNoRequiere servidor MCP local
CursorNoRequiere servidor MCP local
azure devops mcp claude diagrama explicativo

El efecto sobre un equipo mixto es directo: quien usa Copilot conecta en dos minutos, quien usa Claude Code o Cursor carga con el servidor local, el PAT y el mantenimiento. Misma empresa, misma organización de Azure DevOps, experiencias opuestas. Y ojo con esto: hay una segunda restricción que no tiene arreglo a la vista, porque el acceso remoto no está disponible para las organizaciones standalone que usan cuentas Microsoft personales. El remoto exige un tenant de Entra atrás, sí o sí.

¿Cómo funciona la autenticación con Entra y por qué choca con la spec MCP 2026-07-28?

Entra valida tu identidad y el asistente hereda exactamente tus permisos, ni uno más ni uno menos. Farhan Shahnewaz, ingeniero de soluciones de IA y cloud en Microsoft, defiende ese diseño como la respuesta a la primera pregunta que hace todo equipo de seguridad: no hay un personal access token durmiendo en un archivo de config esperando a filtrarse.

El problema es de timing, y es casi cómico. La especificación MCP 2026-07-28 salió el 28 de julio de 2026, una semana antes de este GA, y reordenó los mecanismos de registro de clientes: ahora prefiere clientes pre-registrados, después Client ID Metadata Documents, y dejó el Dynamic Client Registration como fallback deprecado con eliminación programada después del verano 2027. Entra no soporta ninguno de los dos mecanismos que la spec pone primero. Traducido: el único camino que a Entra le resultaría más sencillo implementar es justamente el que el protocolo mandó al cajón (sí, en serio).

Dicho esto, conviene leer el anuncio sin atribuir intenciones oscuras. Todo indica que es una dependencia de plataforma genuina y no una jugada para encerrar usuarios en el ecosistema Microsoft: el compromiso público con el servidor local y la paridad entre ambos apuntan en esa dirección. Igual, tomalo con pinzas, porque el efecto sobre tu equipo es idéntico tenga Microsoft buena o mala intención.

¿Cómo conecto Azure DevOps con Claude o Cursor hoy?

Con el servidor MCP local de Azure DevOps, que es la única vía oficial mientras se resuelve el tema Entra. El flujo básico es este (y si estás evaluando plataformas, complementá con nuestra comparativa de plataformas CI/CD para 2026):

  • Generá un personal access token en tu organización de Azure DevOps, con los scopes mínimos que necesites (work items, code, builds).
  • Levantá el servidor MCP local en tu máquina o en un servidor compartido del equipo; Microsoft consolidó recientemente el toolset local para alinearlo con el remoto.
  • Agregalo a la configuración de tu cliente: Claude Desktop, Claude Code y Cursor consumen servidores MCP desde su archivo de configuración correspondiente.
  • Probá con algo simple antes de meterlo en tu flujo diario, por ejemplo pedirle los work items activos del sprint actual.

Instalás el servidor, generás el token, lo pegás en la config, todo funciona bárbaro, y tres semanas después alguien rota el PAT, nadie avisa a nadie, y el asistente empieza a tirar errores de autenticación que el equipo tarda días en conectar con el cambio de credenciales. Ese guion es viejo y se repite en todas partes.

Una forma de reducir el dolor: en vez de una instancia por developer, corran un único servidor MCP local compartido en infraestructura propia del equipo, un VPS o servidor dedicado (uno de donweb.com cumple sobrado para esto) y administren el token desde ahí. Menos superficies donde filtrar credenciales, un solo lugar para rotar. Si tampoco querés administrar nada, existen automatizaciones de terceros como la integración entre Claude y Azure DevOps de Make, aunque son otra cosa: flujos rígidos, no un asistente consultando en vivo.

¿Para qué sirve en la práctica? Casos de uso reales

Ponele que tu pipeline de dos stages detrás de una app ASP.NET Core falla un martes a la mañana. Sin MCP, abrís cinco pestañas del navegador y te ponés a scrollear un log de cuatro mil líneas. Con el asistente conectado, le preguntás qué stage falló y por qué, y él lee el contexto del pipeline y los logs por el mismo sistema que ya usa tu equipo. Ese es el ejemplo operativo que describe Shahnewaz, y es de los que convencen.

Sobre esas mismas superficies se abren otros usos obvios: resúmenes automáticos de work items, análisis de pull requests en lenguaje natural, consultas rápidas sobre blockers del sprint. Frente a una integración REST hecha a mano, con MCP ganás descubrimiento de herramientas estandarizado y menos código pegamento que mantener.

¿Conviene MCP o una API REST directa?

Depende de la forma de tu problema. Si tenés un caso único y acotado (un bot que crea bugs desde un formulario, por ejemplo), una llamada REST directa es más simple y te evita correr infraestructura extra. Si querés que varios asistentes aprovechen varias capacidades de Azure DevOps, MCP amortiza el esfuerzo: definís la integración una vez y cualquier cliente compatible la usa. La regla rápida: 1 a 1, REST; muchos a muchos, MCP. Más contexto en elegir entre Jenkins y GitHub Actions.

Errores comunes al implementar MCP en Azure DevOps

Estos son los tropiezos que más se ven cuando los equipos arrancan:

  • Endpoint mal formado: la URL remota lleva la organización en el path (https://mcp.dev.azure.com/{organización}). Si te olvidás el slug o dejás las llaves literales, el cliente no descubre ninguna herramienta y el mensaje de error no ayuda mucho.
  • Logs a stdout en el servidor local: MCP habla JSON-RPC sobre stdio, así que si tu script loguea a stdout estás metiendo ruido dentro del protocolo. Logueá a stderr y listo.
  • PAT vencido o con scopes de menos: se manifiesta como errores 401 o 403 crípticos del asistente. Rotá el token, revisá los scopes y anotá la fecha de vencimiento en un lugar visible.
  • Health checks que rompen el protocolo: algunos proxies hacen un GET periódico al endpoint para medir salud, pero MCP opera con POST; excluí la ruta del health check o vas a ver desconexiones intermitentes.
  • Insistir con el remoto en una org standalone: si tu organización usa cuentas Microsoft sin tenant de Entra, el Remote MCP Server no va a funcionar por más que la config esté perfecta. Primero el tenant, después el endpoint.

Qué está confirmado y qué sigue pendiente

Confirmado, según el anuncio y la documentación oficial:

  • Disponibilidad general del Remote MCP Server, anunciada en agosto de 2026.
  • Endpoint alojado en https://mcp.dev.azure.com/{organización} sobre streamable HTTP, con autenticación Entra.
  • Clientes first-party conectados sin onboarding adicional, incluido Copilot Studio como novedad.
  • Paridad comprometida entre el servidor local y el remoto mientras dure el trabajo de Entra.

Pendiente, con fecha desconocida:

  • Soporte de Entra para dynamic OAuth client registration o Client ID Metadata Documents.
  • Conexión de Claude, ChatGPT y Cursor al remoto: frenada hasta que lo anterior caiga.
  • Destino del Dynamic Client Registration, que la spec eliminará después del verano 2027.

Preguntas Frecuentes

¿Por qué el Azure DevOps Remote MCP Server no soporta Claude ni ChatGPT?

Porque Microsoft Entra no soporta los dos mecanismos de autenticación que estos clientes necesitan: dynamic OAuth client registration y Client ID Metadata Documents. Microsoft trabaja con el equipo de Entra para habilitarlos, pero no publicó fecha de llegada.

¿Qué es MCP y por qué lo usan los asistentes de IA?

MCP (Model Context Protocol) es un protocolo abierto que estandariza cómo un asistente de IA descubre y llama herramientas externas. En Azure DevOps permite consultar work items, pull requests, repos y pipelines en lenguaje natural sin construir una integración a medida por cada cliente.

¿Cómo conecto Claude a Azure DevOps hoy?

Con el servidor MCP local de Azure DevOps: generás un personal access token, levantás el servidor en tu máquina o en un servidor compartido y lo registrás en la configuración de Claude Desktop o Claude Code. El endpoint remoto todavía no acepta clientes de Anthropic.

¿El Remote MCP Server tiene costo adicional?

El anuncio de disponibilidad general no menciona ningún cargo extra por el endpoint: corre sobre tu organización existente de Azure DevOps y autentica con tu identidad de Entra. Lo que sí necesitás es una organización respaldada por un tenant de Entra; las organizaciones standalone con cuentas Microsoft quedan afuera.

¿Tengo que instalar un servidor MCP local en mi máquina?

Depende del cliente que uses. Con VS Code, Visual Studio, Copilot Studio, la CLI o la app de GitHub Copilot y Microsoft Foundry, no: el remoto es cero instalación. Con Claude, ChatGPT o Cursor, sí, hasta que Entra habilite los mecanismos de autenticación que les faltan.

Conclusión

Lo que cambió: Azure DevOps tiene desde agosto de 2026 un endpoint MCP alojado y sin instalación, algo que antes exigía correr servidores locales por developer o por equipo. Lo que no cambió: la capa de identidad sigue siendo el cuello de botella, y esta vez le tocó a Entra chocar de frente con la spec más nueva de MCP.

Si tu equipo vive en el mundo Microsoft, adopten el remoto sin dudar. Si estandarizaron en Claude Code o Cursor, quédense en el local, cuiden la higiene de los PAT y sigan de cerca los movimientos de Entra, porque ahí se define cuándo se abre la puerta. La lección de fondo vale para cualquier stack: el transporte ya se estandarizó, la identidad no, y eso decide quién entra y quién mira de afuera.

Fuentes

Te puede interesar...