Azure DevOps MCP Server remoto: conecte o Copilot aos pipelines sem instalar nada

O Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → DevOps MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → Server é a ponte que dá aos agentes de IA (Copilot Chat, Copilot CLI, Cursor e afins) acesso aos seus projetos, pipelines, repos e work items via Model Context Protocol. A novidade que muda o setup: a Microsoft agora recomenda o servidor remoto hospedado no lugar do servidor local em Node.js↳Node.js45 conteúdosComo criar aplicações console em Node.jsDev (Back & Front) · fev 2025Entendendo o ciclo de publicação do Node.jsDev (Back & Front) · fev 2020Nodejs por baixo dos panosDev (Back & Front) · jul 2019Ver tudo em Dev (Back & Front) →. Menos coisa rodando na sua máquina e, segundo o próprio repositório, as features novas chegam primeiro no remoto.

Eu migrei meu setup local pro remoto essa semana. Segue o caminho inteiro, incluindo os tropeços.

Por que o remoto ganha do local

O servidor local (@azure-devops/mcp via npx) sempre funcionou bem, mas tem dois custos: você mantém Node.js 20+ na máquina e precisa configurar a autenticação por conta do cliente. O exemplo oficial de config local usa --authentication azcli (a credencial do az cli), e o README também menciona login interativo com conta Microsoft. Ou seja, é mais peça pra manter e mais passo pra dar errado.

O remoto encurta isso. O endpoint é hospedado pela Microsoft em https://mcp.dev.azure.com/{organization} e você não instala nada: aponta o cliente pra URL e pronto. O README é explícito: "We recommend using the Remote MCP Server instead of this local server. It requires no installation and gets new features first." A própria Microsoft avisa que o local continua suportado, mas o desenvolvimento novo foca no remoto, e que quem usa o local deve começar a planejar a migração.

O trade-off honesto: você passa a depender de um serviço externo da Microsoft e do suporte do seu cliente a servidores MCP remotos via HTTP. É aí que mora a pegadinha que explico no final.

Setup: o arquivo mcp.json

O setup remoto é absurdamente mais curto que o local. Crie .vscode/mcp.json na raiz do projeto:

{
  "servers": {
    "ado-remote-mcp": {
      "url": "https://mcp.dev.azure.com/{organization}",
      "type": "http"
    }
  },
  "inputs": []
}

Troque {organization} pelo nome da sua organização no Azure DevOps (o mesmo que aparece em dev.azure.com/suaorg). Não é a URL completa, é só o slug da org.

Salve o arquivo. No VS Code, abra a MCP view (painel de servidores MCP) e dê start no ado-remote-mcp. Depois disso, segundo o guia do README, é só rodar um prompt. A documentação completa do fluxo de onboarding e as opções extras de configuração estão na Remote MCP Server onboarding documentation e na remote server configuration documentation linkadas no repositório.

Para validar que subiu, no Copilot Chat mande o clássico:

List ADO projects

Se voltar a lista dos seus projetos, o pipe está de pé. No meu caso, foi aqui que precisei confirmar que a conta que eu usava no VS Code era a mesma com acesso à organização, senão a lista volta vazia sem erro claro.

O que dá pra automatizar hoje

Depois do primeiro List ADO projects, testei o que interessa no dia a dia de quem cuida de entrega. As ferramentas cobrem os domínios principais e você conversa em linguagem natural. Prompts que o próprio README lista como exemplos e que rodei:

• Pipelines/builds: List ADO Builds for 'Contoso' para ver o histórico e o status das últimas execuções.
• Repos: List ADO Repos for 'Contoso' e navegar por branches e PRs.
• Work items: List my work items for project 'Contoso' e o mais útil no cerimonial de sprint, List work items in current iteration for 'Contoso' project and 'Contoso Team'.
• Test plans: List test plans for 'Contoso'.
• Iterações e times: List iterations for project 'Contoso' e List teams for project 'Contoso'.
• Wiki: além de ler (Get the content of the wiki page '/API/Authentication'), dá para criar e atualizar páginas, tipo Create a wiki page '/Architecture/Overview' with content about system design. Isso é o que mais me poupou tempo: gerar documentação a partir do contexto do repo sem sair do editor.

O desenho é deliberadamente enxuto: pelo README, cada tool é uma camada fina sobre a REST API do Azure DevOps, e a inteligência de encadear ações fica com o agente. Ou seja, o servidor não faz mágica; ele expõe operações e o Copilot decide a ordem.

A lista completa das ferramentas remotas está na documentação Available Tools do projeto. Vale conferir antes de prometer automação para o time, porque a paridade entre remoto e local ainda está em construção (o README aponta para o TOOLSET.md para a lista de tools locais).

Ajuda o Copilot a escolher a ferramenta certa

Um detalhe que faz diferença prática: adicione um .github/copilot-instructions.md no projeto com a instrução que a própria Microsoft sugere:

This project uses Azure DevOps. Always check whether the Azure DevOps MCP server has a tool relevant to the user's request.

Sem isso, o Copilot às vezes tenta responder de cabeça em vez de chamar a tool. Com a instrução, a taxa de acerto na seleção de ferramenta subiu nos meus testes.

O tropeço: nem todo cliente entra pelo remoto no mesmo caminho

Aqui está a parte que ninguém conta no anúncio. O setup remoto que mostrei acima é o descrito no README para VS Code + Copilot. Para os demais clientes suportados, o README apenas remete a outro documento: "For other supported clients, including Visual Studio 2022, Codex, Claude Code, Cursor, OpenCode, and Kilo Code, see the getting started guide." Ou seja, esses clientes têm instruções próprias, e o README não deixa claro, nesse ponto, se o caminho recomendado para eles é o remoto ou o servidor local via stdio.

Tradução prática: antes de padronizar a migração no time, confira no getting started guide como cada cliente que vocês usam se conecta, porque o caminho de VS Code não é necessariamente o mesmo dos outros.

Quando eu preciso do local, a config muda para stdio e volta a pedir a org como input:

{
  "inputs": [
    {
      "id": "ado_org",
      "type": "promptString",
      "description": "Azure DevOps organization name (e.g. 'contoso')"
    }
  ],
  "servers": {
    "ado": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "${input:ado_org}"]
    }
  }
}

No local, dois ajustes valem ouro. Primeiro, domínios: o servidor local carrega todas as ferramentas por padrão, o que estoura o limite de tools de alguns clientes. Use -d para carregar só o que precisa (domínios disponíveis, segundo o README: core, work, work-items, search, test-plans, repositories, wiki, pipelines, advanced-security):

"args": ["-y", "@azure-devops/mcp", "${input:ado_org}", "-d", "core", "work", "work-items"]

Sempre inclua core, senão o agente não consegue nem recuperar informação dos projetos. Segundo, defaults de projeto e time via variáveis de ambiente, para o agente parar de perguntar toda hora:

"env": {
  "ado_mcp_project": "Contoso",
  "ado_mcp_team": "Fabrikam Team"
}

Um aviso sobre versão

A Microsoft acabou de concluir uma consolidação de ferramentas que renomeou tools existentes. Se você tem agentes ou skills que chamam nomes específicos de ferramenta, essa é uma breaking change. Dá para segurar temporariamente fixando a versão em @azure-devops/mcp@2.8.1 enquanto adapta os nomes novos (a lista está no TOOLSET.md). Para builds noturnos, troque @azure-devops/mcp por @azure-devops/mcp@next na configuração.

Veredito para times BR

Se você está no VS Code com Copilot, migrar para o remoto vale a pena: zero instalação e as features novas chegam primeiro, como a própria Microsoft afirma. Se seu time está espalhado por Cursor, Claude Code e companhia, leia o getting started guide de cada cliente antes de prometer o mesmo fluxo para todo mundo, e mantenha o servidor local com domínios filtrados onde ainda for necessário. O que fica em aberto é a paridade total de ferramentas entre os dois modos. Até lá, medir qual das duas configs seu time realmente usa é o que decide a migração.

Fonte: Microsoft — Azure DevOps MCP Server (repositório oficial)