Fala dataholics, chegamos na parte da série que é divertida e assustadora ao mesmo tempo. Nos dois posts anteriores a gente ensinou o agente a trabalhar do jeito do seu repo, com AGENTS.md e instructions e depois com Agent Skills. Só que tudo isso ainda vive dentro do repositório, e o Copilot só sabe o que está escrito lá. Com MCP ele passa a chamar ferramenta de verdade, e aí entra a pergunta que o time de segurança vai fazer.

O que veremos nesse post:

• O que o MCP resolve no Copilot

• mcp.json e o GitHub MCP Server

• MCP no code review, com um limite bem colocado

• Governança: registry curado e allowlist na enterprise

• Como eu recomendo começar

O que o MCP resolve aqui

Se você acompanha o blog já viu MCP em Copilot Studio e em Databricks, então o conceito você conhece: é o protocolo que dá ferramenta e dado externo pro agente de forma padronizada. No GitHub Copilot ele serve pra tirar o agente da caixinha do repositório, porque muita informação que o agente precisa nunca vai estar num arquivo .md. O ticket que descreve o bug está no Jira, o padrão de arquitetura está no Confluence, o schema real da tabela está no Unity Catalog e o erro em produção está no Application Insights.

Sem MCP você fica sendo o copiador humano, colando pedaço de log e pedaço de ticket no chat. Com MCP o agente vai buscar sozinho, e a diferença de qualidade em tarefa de investigação é grande, porque ele olha o dado real em vez de inventar em cima do nome da função.

Reginaldo, mas se ele já lê o repo eu preciso mesmo de MCP?

Pra código não, e eu diria pra nem tentar, porque MCP pra ler arquivo do próprio repositório é dar volta longa numa coisa que ele já faz melhor e mais barato. MCP vale pro que está fora do repo, o ticket, a métrica, o schema, o board. Essa é a linha que eu uso pra decidir.

mcp.json e o GitHub MCP Server

No VS Code a configuração fica num mcp.json com a chave raiz servers, e ele aceita servidor local, que roda por comando na sua máquina, e servidor remoto por HTTP. Pra deixar a configuração viajando junto com o projeto, cria um .vscode/mcp.json na raiz do workspace e comita, aí todo mundo do time já abre o projeto com as ferramentas certas ligadas.

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "databricks": {
      "type": "stdio",
      "command": "uvx",
      "args": ["databricks-mcp-server"],
      "env": { "DATABRICKS_HOST": "${input:dbx_host}" }
    }
  }
}

O suporte a MCP no VS Code é GA desde a versão 1.102 e veio com coisas que fazem diferença no uso diário: sandbox embutido, autenticação por OAuth, sync da configuração entre as suas máquinas e um catálogo curado dentro do painel de extensões. E existe o GitHub MCP Registry, que é a lista curada de servidores que você adiciona com poucos cliques. Essa versão 0.1 do registry é consumida por VS Code, Visual Studio, JetBrains, Eclipse, Xcode e pelo Copilot CLI, então a mesma curadoria vale pra IDE inteira da casa.

O GitHub MCP Server merece menção separada porque é o que a maioria vai ligar primeiro e é remoto, sem instalar nada. Com ele o agente lê issue, PR, workflow e code scanning direto da API, e aí o prompt "por que o build do PR 412 quebrou" para de ser retórico.

MCP no code review

No post anterior eu já tinha adiantado: skills e MCP no Copilot code review ficaram GA em julho de 2026. A configuração fica nas settings do repositório, em Copilot e depois MCP servers, e o token vai em Secrets and variables na aba Agents. Quem já tinha MCP montado pro cloud agent não precisa fazer nada, a configuração é aproveitada automaticamente.

E tem um limite aqui que eu acho muito bem colocado: toda chamada de MCP feita pelo code review é read-only. Faz total sentido, porque revisão de PR é leitura por definição e você não quer que um comentário malicioso escondido num diff faça o revisor automático fechar um ticket ou mexer num board. Detalhe pequeno na doc e enorme na hora de aprovar isso internamente.

Governança, a parte que vai travar seu rollout

Aqui é onde a conversa fica adulta. MCP é ótimo e é também a porta que você acabou de abrir na máquina do dev, porque um servidor MCP roda com as credenciais que alguém colocou nele e a ferramenta que ele expõe pode escrever, deletar e chamar API paga. Se ficar solto, cada pessoa do time instala o que quiser e você não sabe o que está conectado no seu código-fonte.

O GitHub montou duas frentes pra isso e vale saber qual é qual, porque a documentação é explícita no assunto:

• MCP private registry enforcement: você aponta a org ou a enterprise pra um registry privado e os clientes do Copilot só descobrem, e opcionalmente só permitem, os servidores que a empresa aprovou. Está em public preview e a própria doc diz que não é o método recomendado pra restringir acesso.

• allowedMcpServers e deniedMcpServers no enterprise managed settings: as chaves que você define no managed-settings.json da enterprise. Ficou GA em agosto de 2026 e é o caminho recomendado, hoje aplicado no app do GitHub Copilot, no Copilot CLI e no VS Code.

Além disso, desde abril de 2026 o Copilot CLI também respeita allowlist baseada em registry customizado, ainda em public preview. Ou seja, dá pra ter a lista aprovada valendo do terminal até a IDE, o que é importante, porque governança que só existe no VS Code não é governança.

Um ponto que eu levanto sempre nessa conversa e que a doc não vai resolver pra você: conteúdo que vem de ferramenta é entrada não confiável. Se o agente lê a descrição de um ticket que alguém de fora escreveu, aquele texto entra no contexto do modelo. Preferir servidor read-only, aprovar por registry e olhar quais tools de escrita realmente precisam existir é bem mais eficiente do que confiar no bom senso do modelo.

Como eu recomendo começar

• Liga o GitHub MCP Server primeiro, é remoto, não instala nada e já resolve issue, PR e workflow.

• Comita um .vscode/mcp.json no repo pra padronizar o time em vez de cada um montar o seu.

• Antes de abrir pra geral, define o allowedMcpServers na enterprise, porque depois de virar hábito é muito mais chato tirar.

• Começa com servidores de leitura. Escrita entra depois, um por um, com o motivo escrito.

• No code review, aproveita o que já está configurado no cloud agent, o read-only já vem de graça.

No próximo post eu tiro o Copilot da IDE e levo pro terminal com o Copilot CLI, que ficou GA esse ano e tem plan mode, autopilot e delegação pra cloud agent. Comenta aí quais servidores MCP você já ligou no seu Copilot.

Referências:

https://code.visualstudio.com/docs/agent-customization/mcp-servers

https://github.blog/changelog/2026-08-06-mcp-allowlists-in-enterprise-managed-settings/

https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-registry

Fique bem e até a próxima.

#githubcopilot #mcp #copilot #ia #agentes #datainaction

Hey dataholics, we got to the part of the series that is fun and scary at the same time. In the two previous posts we taught the agent to work the way your repo works, first with AGENTS.md and instructions and then with Agent Skills. All of that still lives inside the repository though, and Copilot only knows what is written there. With MCP it starts calling real tools, and that is where the question your security team will ask comes in.

What we will see in this post:

• What MCP solves in Copilot

• mcp.json and the GitHub MCP Server

• MCP in code review, with a well placed limit

• Governance: curated registry and enterprise allowlist

• How I recommend starting

What MCP solves here

If you follow the blog you have already seen MCP in Copilot Studio and in Databricks, so you know the concept: it is the protocol that gives the agent tools and external data in a standardized way. In GitHub Copilot it serves to pull the agent out of the repository box, because a lot of the information the agent needs will never live in a .md file. The ticket describing the bug is in Jira, the architecture standard is in Confluence, the real table schema is in Unity Catalog and the production error is in Application Insights.

Without MCP you become the human copier, pasting a chunk of log and a chunk of ticket into the chat. With MCP the agent goes and fetches it, and the quality difference on investigation tasks is big, because it looks at the real data instead of making things up based on a function name.

Reginaldo, but if it already reads the repo do I really need MCP?

Not for code, and I would say do not even try, because MCP to read a file from your own repository is taking the long way around something it already does better and cheaper. MCP is worth it for what sits outside the repo, the ticket, the metric, the schema, the board. That is the line I use to decide.

mcp.json and the GitHub MCP Server

In VS Code the configuration lives in an mcp.json with a servers root key, and it takes local servers, which run by command on your machine, and remote servers over HTTP. To make the configuration travel with the project, create a .vscode/mcp.json in the workspace root and commit it, then everyone on the team opens the project with the right tools already wired up.

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "databricks": {
      "type": "stdio",
      "command": "uvx",
      "args": ["databricks-mcp-server"],
      "env": { "DATABRICKS_HOST": "${input:dbx_host}" }
    }
  }
}

MCP support in VS Code has been GA since version 1.102 and it came with things that matter in daily use: built in sandboxing, OAuth authentication, config sync across your machines and a curated catalog inside the extensions panel. And there is the GitHub MCP Registry, the curated list of servers you add with a couple of clicks. This 0.1 version of the registry is consumed by VS Code, Visual Studio, JetBrains, Eclipse, Xcode and Copilot CLI, so the same curation covers every IDE in the house.

The GitHub MCP Server deserves its own mention because it is the one most people will turn on first and it is remote, nothing to install. With it the agent reads issues, PRs, workflows and code scanning straight from the API, and then the prompt "why did the build on PR 412 break" stops being rhetorical.

MCP in code review

I already teased this in the previous post: skills and MCP in Copilot code review went GA in July 2026. The configuration lives in the repository settings, under Copilot and then MCP servers, and the token goes into Secrets and variables on the Agents tab. Whoever already had MCP wired up for the cloud agent does not need to do anything, the configuration carries over automatically.

And there is a limit here that I find very well placed: every MCP call made by code review is read-only. It makes total sense, because reviewing a PR is reading by definition and you do not want a malicious comment hidden in a diff making the automated reviewer close a ticket or touch a board. Small detail in the docs and a huge one when you go get this approved internally.

Governance, the part that will stall your rollout

This is where the conversation gets grown up. MCP is great and it is also the door you just opened on the dev machine, because an MCP server runs with the credentials somebody put into it and the tools it exposes can write, delete and call paid APIs. Left loose, every person on the team installs whatever they want and you have no idea what is connected to your source code.

GitHub built two fronts for this and it is worth knowing which is which, because the docs are explicit about it:

• MCP private registry enforcement: you point the org or the enterprise at a private registry and Copilot clients only discover, and optionally only allow, the servers your company approved. It is in public preview and the docs themselves say it is not the recommended method to restrict access.

• allowedMcpServers and deniedMcpServers in enterprise managed settings: the keys you define in the enterprise managed-settings.json. It went GA in August 2026 and it is the recommended path, currently enforced in the GitHub Copilot app, in Copilot CLI and in VS Code.

On top of that, since April 2026 Copilot CLI also respects allowlists based on a custom registry, still in public preview. So you can have the approved list holding from the terminal all the way to the IDE, which matters, because governance that only exists in VS Code is not governance.

One point I always raise in this conversation and that the docs will not solve for you: content coming from a tool is untrusted input. If the agent reads a ticket description that somebody outside wrote, that text enters the model context. Preferring read-only servers, approving through a registry and looking hard at which write tools really need to exist is far more effective than trusting the model's common sense.

How I recommend starting

• Turn on the GitHub MCP Server first, it is remote, installs nothing and already covers issues, PRs and workflows.

• Commit a .vscode/mcp.json in the repo to standardize the team instead of everyone rolling their own.

• Before opening it to everyone, set allowedMcpServers at the enterprise level, because once it becomes a habit it is much harder to walk back.

• Start with read servers. Write comes later, one at a time, with the reason written down.

• In code review, reuse what is already configured for the cloud agent, read-only comes for free.

In the next post I take Copilot out of the IDE and into the terminal with Copilot CLI, which went GA this year and has plan mode, autopilot and delegation to cloud agents. Tell me in the comments which MCP servers you already turned on in your Copilot.

References:

https://code.visualstudio.com/docs/agent-customization/mcp-servers

https://github.blog/changelog/2026-08-06-mcp-allowlists-in-enterprise-managed-settings/

https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-registry

Stay well and see you next time.

#githubcopilot #mcp #copilot #ai #agents #datainaction