MCP para IDEs e agentes de desenvolvimento: como transformar seu editor num agente real

O que muda quando você adiciona MCP a uma IDE

Antes do MCP, o assistente de código (seja GitHub Copilot, Claude no Cursor ou qualquer outro) trabalhava com o que você colava na janela de chat: um trecho de código, uma mensagem de erro, um bloco de contexto que você manualmente selecionava.

Com MCP, a dinâmica muda completamente. O modelo pode:

• Ler o arquivo real em vez de depender do que você colou.
• Verificar o histórico de commits para entender por que aquele código existe.
• Rodar os testes e analisar os resultados sem você precisar copiar a saída.
• Abrir uma issue ou PR diretamente no repositório após fazer uma mudança.
• Consultar o schema do banco antes de sugerir uma query — sem adivinhar nomes de coluna.

Isso transforma a IDE num agente de desenvolvimento — algo que age no ambiente, não só que responde ao que você digita. A produtividade reportada por times que adotam esse fluxo varia entre 30% e 60% de redução no tempo de tarefas rotineiras como refatoração, criação de testes e revisão de código.

Como MCP funciona no Cursor e no VS Code

Tanto o Cursor quanto o VS Code (via extensão oficial da Anthropic e via Claude Dev) suportam MCP como clientes. A configuração fica num arquivo JSON na raiz do projeto ou na configuração global do usuário:

// .cursor/mcp.json (Cursor) ou .vscode/mcp.json (VS Code)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/dev/projetos/meu-projeto"  // Restrinja ao diretório do projeto!
      ]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${env:DB_STAGING_URL}"
      }
    }
  }
}

Note dois detalhes importantes nesse config: as credenciais vêm de variáveis de ambiente (nunca hardcoded no arquivo), e o Filesystem está restrito ao diretório do projeto — não à raiz do sistema.

Os 8 MCP servers mais usados para desenvolvimento

A tabela abaixo descreve os servidores MCP mais comuns no contexto de desenvolvimento, com avaliação honesta do risco de cada um e a configuração recomendada para uso seguro.

Casos de uso reais: o que um agente de desenvolvimento faz na prática

Os exemplos abaixo são baseados em fluxos reais, não em demos de marketing.

Caso 1: revisão de PR assistida

Com MCP GitHub configurado, o desenvolvedor digita: "Revise o PR #142. Liste os arquivos alterados, identifique code smells e sugira melhorias."

O agente usa o MCP GitHub para buscar o diff real do PR, lê cada arquivo alterado via MCP Filesystem para entender o contexto completo (não só as linhas do diff), e retorna uma análise estruturada com localização exata dos problemas.

Sem MCP, o desenvolvedor precisaria colar manualmente o diff no chat — e perder o contexto dos arquivos que não foram alterados mas são referenciados.

Caso 2: debug com acesso ao banco de staging

O desenvolvedor descreve um bug: "A função calcular_desconto retorna valor errado para clientes do plano Gold. Olha o código e depois consulta o banco para ver se os dados de teste fazem sentido."

O agente lê a função via MCP Filesystem, depois usa MCP PostgreSQL para consultar a tabela de clientes Gold e a tabela de regras de desconto. Cruza as informações e identifica que há uma inconsistência nos dados de configuração — o problema não é no código, é nos dados.

Esse tipo de debug cruzado (código + dados) normalmente levaria 20-40 minutos. Com o agente, leva menos de 2 minutos.

Caso 3: criação automática de testes

"Cria testes unitários para o módulo src/servicos/pagamentos.py. Usa o padrão que já existe nos outros arquivos de teste do projeto."

O agente usa MCP Filesystem para ler o módulo de pagamentos, depois lê dois ou três arquivos de teste existentes para entender o padrão, e gera os novos testes já no estilo do projeto — mesmos imports, mesmo nível de granularidade, mesma convenção de nomes.

Riscos reais de dar acesso ao filesystem para o agente

O MCP Filesystem é o server mais útil e também o que tem os riscos mais concretos. Vamos ser diretos sobre o que pode dar errado:

• Leitura de arquivos com segredos: se o diretório configurado inclui .env, secrets.yaml, ~/.ssh/id_rsa ou qualquer arquivo com chaves, o modelo pode lê-los — inclusive por acidente, ao explorar o projeto. Mitigação: restrinja ao diretório do código-fonte, use .mcpignore (similar ao .gitignore) para excluir arquivos sensíveis.
• Deleção acidental de arquivos: se o MCP Filesystem tiver permissão de deleção e o modelo interpretar mal uma instrução como "limpa os arquivos temporários da pasta", arquivos importantes podem ser deletados. Mitigação: desabilite a ferramenta de deleção. Leitura + escrita são suficientes para 95% dos casos de uso.
• Escrita em arquivos de configuração críticos: o agente pode modificar arquivos como package.json, pyproject.toml ou arquivos de CI/CD. Isso raramente é intencional e pode quebrar pipelines. Mitigação: mantenha controle de versão e revise diffs antes de commitar.

Boas práticas: permissão mínima para agentes de desenvolvimento

O princípio de permissão mínima, aplicado ao contexto de IDEs com MCP:

1. Comece somente com leitura. Antes de habilitar qualquer operação de escrita (criar arquivo, criar issue, commitar), valide que o agente se comporta corretamente nas operações de leitura por pelo menos uma semana.
2. Use tokens com escopo mínimo. Para GitHub, crie um fine-grained token com acesso somente ao repositório do projeto atual. Rotacione tokens a cada 90 dias.
3. Mantenha ambientes separados. MCP Postgres deve apontar para staging ou dev, nunca para produção. Crie regras de DNS ou variáveis de ambiente que impossibilitem apontar para produção por acidente.
4. Revise o que o agente faz. Em vez de deixar o agente commitar diretamente, configure para criar um branch e abrir um PR. Você revisa antes de qualquer mudança ir para main.
5. Desabilite servidores quando não estiver usando. Se você está numa sessão de documentação e não precisa de acesso ao banco, remova o MCP Postgres da configuração ativa. Menos ferramentas disponíveis = menor superfície de ataque.

MCP em agentes autônomos vs. assistidos por humano

Existe uma diferença crítica entre dois modos de uso:

Assistido: o desenvolvedor está presente, pede ao agente que faça algo, revisa o resultado e decide o próximo passo. O agente é uma ferramenta de produtividade. Nesse modo, praticamente todos os MCP servers da tabela acima são seguros com as configurações recomendadas.

Autônomo: o agente opera sem supervisão, em loop, executando tarefas por conta própria. Nesse modo, os riscos são radicalmente diferentes. Um agente autônomo com MCP Shell pode tomar ações que você não esperava e que são difíceis de reverter.

Para agentes autônomos de desenvolvimento (ex.: "resolva todos os issues do tipo 'bug' abertos há mais de 30 dias"), a recomendação é:

• Limite a uma única ação por execução, com checkpoint de confirmação humana entre elas.
• Habilite apenas MCP com operações de baixo risco (criação de branch, abertura de PR rascunho).
• Desabilite completamente MCP Shell e MCP Filesystem com escrita em agentes autônomos.
• Implemente rollback automático: toda mudança vai para um branch isolado, nunca direto para main.

Configuração completa recomendada: ponto de partida seguro

Para um time de desenvolvimento que está começando com MCP, esta é a configuração que equilibra utilidade e segurança:

// .cursor/mcp.json — configuração de ponto de partida
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
      // Token fine-grained: somente este repositório
      // Permissões: issues:rw, pull-requests:rw, contents:r, metadata:r
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "${workspaceFolder}/src",
        "${workspaceFolder}/tests"
        // SÓ src/ e tests/ — não a raiz completa
      ]
    },
    "postgres-staging": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${env:DB_STAGING_READONLY_URL}"
        // Usuário somente-leitura, banco de staging
      }
    }
    // Linear e Jira: adicione depois de validar os 3 acima por 1-2 semanas
    // Shell: NÃO adicione sem sandbox configurado
  }
}

MCP e o futuro do desenvolvimento de software

A tendência é clara: as IDEs estão se tornando ambientes de agente. Cursor, VS Code, JetBrains e outros estão investindo ativamente em integração com protocolos de ferramentas como MCP. No horizonte de 12 a 24 meses, é provável que:

• MCP vire padrão de integração em todas as IDEs principais, não mais uma extensão opt-in.
• Aparecerão MCP servers específicos para stacks (MCP para Django, MCP para Rails, MCP para Spring) com ferramentas otimizadas para aquele ecossistema.
• Times de desenvolvimento terão "engenheiros de agente" — pessoas que configuram, mantêm e melhoram os agentes de desenvolvimento da equipe.

Para times de desenvolvimento que querem começar hoje, o caminho mais direto é instalar o MCP GitHub e o MCP Filesystem com a configuração restrita acima, e usar por 2 semanas em modo assistido antes de expandir.

Para entender como estruturar múltiplos MCP servers num contexto de empresa, veja MCP para empresas: o que é e quando implementar. Para os aspectos de segurança antes de ir para produção, leia segurança em MCP: allowlist, sandbox, scopes e logs. E para comparar MCP com a alternativa tradicional de APIs, veja MCP vs. API REST: qual a diferença e quando usar cada um.