🐙 O que o GitHub MCP Faz
🎯 Acesso Direto ao GitHub
O GitHub MCP conecta o Claude a API do GitHub via protocolo MCP. Ele pode listar e ler issues, criar e gerenciar pull requests, verificar status de CI/CD, buscar em repositorios e ler conteudo de arquivos remotos. Tudo sem sair do terminal.
- • list_issues / get_issue: Acessa issues com filtros (label, state, assignee)
- • create_pull_request: Cria PRs com title, body e branch
- • get_pull_request_reviews: Le feedback de reviewers
- • search_repositories: Busca repos por nome, topico ou linguagem
📊 Claude Como Membro da Equipe
- Com GitHub MCP, o Claude entende o CONTEXTO do projeto: quem pediu o que, quais issues estao abertas
- Workflow completo: leia issue -> implemente -> crie PR -> sem copy-paste
- Reviews automatizados com contexto real do PR, nao suposicoes
💡 Dica Pratica
O workflow mais poderoso com GitHub MCP: 'leia a issue #42, implemente o que foi pedido e crie um PR linkando a issue'. O Claude busca a issue, entende os requisitos, implementa no codigo e cria o PR formatado. Um unico prompt substitui 15 minutos de trabalho manual.
✓ O que FAZER
- ✓ Usar para integrar issues com implementacao
- ✓ Pedir queries especificas com filtros
- ✓ Combinar com Skills de review para PRs completos
✗ O que NAO fazer
- ✗ Listar todas as issues sem filtro (enche o contexto)
- ✗ Criar PRs sem revisar o que o Claude gerou
- ✗ Deixar conectado durante sessoes de coding puro
🎯 Por Que Vale a Pena
🎯 Contexto Completo do Projeto
Sem GitHub MCP, voce precisa copiar e colar issues, comentarios de PR e feedback de reviewers manualmente. Com GitHub MCP, o Claude busca tudo sozinho e trabalha com o contexto completo do que esta acontecendo no repositorio.
- • Sem MCP: copy-paste de issue -> prompt -> code -> manual PR = 15-20 min
- • Com MCP: 'implemente issue #42 e crie PR' = 2-5 min
- • Economia: 75%+ do tempo em workflows issue-to-PR
📊 Impacto na Produtividade
- Issues como input direto: o Claude le a issue e traduz em codigo
- Reviews como feedback: le comentarios e ajusta codigo automaticamente
- CI/CD como validacao: verifica se checks passaram e corrige se nao
💡 Dica Pratica
Para maximizar valor do GitHub MCP, estruture suas issues com clareza. Uma issue bem escrita com criterios de aceitacao se torna um prompt perfeito para o Claude implementar. Issue clara + GitHub MCP = implementacao quase automatica.
✓ O que FAZER
- ✓ Escrever issues claras com criterios de aceitacao
- ✓ Usar GitHub MCP para fechar o loop issue->code->PR
- ✓ Verificar CI/CD status apos criar PRs
✗ O que NAO fazer
- ✗ Esperar que o Claude implemente issues vagas corretamente
- ✗ Ignorar feedback de reviewers acessivel via MCP
- ✗ Usar para tarefas que nao envolvem GitHub
⚙️ Instalacao + Token
🎯 Setup com Autenticacao
A instalacao requer dois passos: configurar o Personal Access Token (PAT) do GitHub como variavel de ambiente e executar o comando de adicao do MCP. O token define quais permissoes o Claude tera no GitHub.
- • Passo 1: Crie um PAT em github.com → Settings → Developer settings → Personal access tokens → Fine-grained
-
•
Passo 2:
export GITHUB_TOKEN=github_pat_xxxxx -
•
Passo 3:
claude mcp add github -- npx -y @anthropic/mcp-github -
•
Passo 4: Verifique com
/status
📊 Seguranca do Token
- Use Fine-grained PAT (nao classic) para controle preciso
- Escopos minimos: Contents (read), Issues (read/write), PRs (read/write)
- Adicione GITHUB_TOKEN ao seu .bashrc ou .zshrc para persistencia
💡 Dica Pratica
Nunca use um token com permissao de admin no GitHub MCP. Crie um token Fine-grained com escopos minimos: acesso somente aos repos que voce trabalha, permissoes de leitura para a maioria e escrita apenas para issues e PRs. Revise e rotacione o token a cada 90 dias.
✓ O que FAZER
- ✓ Usar Fine-grained PAT com escopos minimos
- ✓ Adicionar GITHUB_TOKEN ao shell profile
- ✓ Rotacionar token a cada 90 dias
✗ O que NAO fazer
- ✗ Usar classic token com full access
- ✗ Compartilhar token com outras pessoas
- ✗ Commitar token em arquivos do projeto
💼 Casos de Uso
🎯 Workflows Praticos
O GitHub MCP habilita workflows que integram gerenciamento de projeto (issues, PRs) com implementacao (codigo). Os casos mais valiosos sao aqueles que eliminam alternancia entre browser e terminal.
- • Issue-driven: 'leia issue #42 e implemente' → Claude busca, implementa e pode criar PR
- • Review-driven: 'leia reviews do PR #15 e ajuste o codigo' → Claude le feedback e aplica correções
- • Triage: 'liste issues com label bug criadas esta semana' → Claude filtra e resumo
- • CI-fix: 'verifique por que o CI falhou no ultimo commit e corrija' → Claude diagnostica e corrige
📊 ROI Por Caso de Uso
- Issue-driven: salva 10-15 min por issue (sem copy-paste)
- Review-driven: salva 5-10 min por ciclo de review
- Triage: salva 15-30 min por sessao de triagem
💡 Dica Pratica
O caso de uso com melhor ROI e issue-driven development: mantenha suas issues bem estruturadas e peca ao Claude 'leia a issue #X, implemente e crie PR'. Para issues complexas, quebre em sub-tarefas na issue e peca ao Claude implementar uma por uma.
✓ O que FAZER
- ✓ Usar issue-driven development como workflow padrao
- ✓ Combinar com Skills de review para PRs mais completos
- ✓ Filtrar queries para minimizar dados retornados
✗ O que NAO fazer
- ✗ Pedir listas enormes sem filtro
- ✗ Criar PRs sem revisar o diff gerado
- ✗ Usar para repos que voce nao tem permissao
🟡 Token Impact: Moderate (~2.000 tokens)
🎯 Custo-Beneficio Equilibrado
O GitHub MCP tem overhead moderado: ~2.000 tokens por mensagem. Isso o coloca no meio-termo - mais caro que Filesystem mas muito mais barato que Browser. O custo e justificavel quando voce esta ativamente trabalhando com issues e PRs.
- • ~2.000 tokens/msg = 1% da janela de 200k
- • Em 50 mensagens: 100k tokens de overhead (significativo)
- • Justificavel quando: trabalhando ativamente com issues/PRs/reviews
📊 Quando Conectar vs Desconectar
- Conectar: inicio de sprint, triagem de issues, ciclo de PR
- Desconectar: coding puro sem referencia a issues, refactoring interno
- Regra: se nao vai interagir com GitHub nas proximas 10 msgs, desconecte
💡 Dica Pratica
Uma estrategia eficiente: conecte GitHub MCP no inicio da sessao para ler issues e entender o que implementar. Depois desconecte e code com apenas Filesystem. No final, reconecte para criar o PR. Isso economiza ~2.000 tokens x mensagens de coding puro.
✓ O que FAZER
- ✓ Conectar quando trabalhando com issues/PRs
- ✓ Desconectar durante coding puro
- ✓ Usar a estrategia conecta-desconecta-reconecta
✗ O que NAO fazer
- ✗ Manter sempre ligado 'por conveniencia'
- ✗ Ignorar o overhead de 2.000 tokens em sessoes longas
- ✗ Conectar para tarefas que nao envolvem GitHub
🎯 Queries Especificas
🎯 Otimize Seus Pedidos
A chave para usar GitHub MCP eficientemente e ser especifico nos pedidos. Queries amplas retornam muitos dados que enchem o contexto. Queries focadas retornam so o necessario.
- • Ruim: 'liste todas as issues do repo' → pode retornar centenas de issues
- • Bom: 'liste issues com label bug criadas esta semana' → retorna 3-5 issues
- • Ruim: 'mostre o PR #42 completo com diff' → diff enorme no contexto
- • Bom: 'mostre titulo, descricao e comments do PR #42' → dados focados
📊 Impacto no Contexto
- Query ampla: pode injetar 10k-50k tokens de dados no contexto
- Query focada: injeta 500-2.000 tokens de dados relevantes
- A diferenca pode ser 10-25x menos tokens gastos
💡 Dica Pratica
Sempre filtre por: label, state (open/closed), assignee, created date. Peca campos especificos em vez de 'tudo'. Para PRs, peca 'titulo e descricao' antes de pedir 'diff completo'. Avalie se realmente precisa do diff no contexto ou se o codigo local ja e suficiente.
✓ O que FAZER
- ✓ Filtrar por label, state, date, assignee
- ✓ Pedir campos especificos em vez de objetos completos
- ✓ Avaliar necessidade antes de pedir diffs grandes
✗ O que NAO fazer
- ✗ Listar 'todas as issues' sem filtro
- ✗ Pedir diffs completos de PRs grandes
- ✗ Buscar em repos inteiros sem especificar filtros
📋 Resumo do Modulo
Proximo:
6.5 - MCP #3: Browser/Chrome