MCP de GitHub

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "TU_TOKEN" }
    }
  }
}

El MCP de GitHub conecta tu agente con tu cuenta: leer y crear issues, revisar y abrir Pull Requests, navegar repositorios y buscar código, siempre con tu permiso. El agente deja de estar “ciego” a tu GitHub y pasa a poder hacer el trabajo repetitivo de gestión de un repo por ti. Hay dos formas de usarlo y conviene empezar por la remota, que es la que te ahorra manejar tokens.

GitHub publica un servidor oficial, no es uno de tantos clones de la comunidad. Eso importa por dos razones: por un lado, sigue el ritmo de la API de GitHub (cuando aparecen funciones nuevas, el servidor las expone pronto); por otro, está pensado para ser auditable. Cuando le das acceso a tu cuenta, sabes a qué SDK estás dando permiso.

Lo que cambia respecto a hablar con la API directamente es la forma de la conversación. En vez de recordar endpoints, parámetros y formatos, le dices al agente “abre un issue en mi repo X describiendo este bug” y él se encarga de la sintaxis. Tu trabajo pasa a ser revisar y aprobar, no escribir JSON.

Qué te abre

La parte más usada es la gestión de issues. El agente puede listar issues abiertos, filtrar por etiqueta o asignación, leerlos enteros con sus comentarios y abrir nuevos con un título y un cuerpo bien redactados. Eso convierte el triaje, esa tarea que nadie quiere hacer, en algo que se delega: “mira los issues de la última semana y agrúpalos por área”.

Los Pull Requests son el segundo gran caso. El agente puede revisar PRs abiertos, leer el diff, comentar dentro del PR e incluso abrir uno nuevo si tienes un cambio ya en una rama. Para revisiones de código no sustituye a un humano sénior, pero sí filtra lo obvio y libera tiempo de los revisores reales.

La navegación de código y la búsqueda son las funciones que más cambian el día a día. Pídele “busca en mi organización todos los sitios donde se usa esta función” y obtienes un mapa sin tener que clonar nada localmente. Si llegas a un repo nuevo, “lee el README y los archivos principales y resúmeme la arquitectura” te ahorra horas de exploración a ciegas.

Por debajo, el servidor habla con la API de GitHub, así que cualquier permiso que tu cuenta tenga (ver issues privados, crear ramas en repos de la empresa, comentar en PRs ajenos) se hereda. Esto es bueno y peligroso a la vez: bueno porque no hay que duplicar nada, peligroso porque el alcance está marcado por tu cuenta, no por el chat.

Cómo conectarlo

Hay dos caminos y son muy distintos.

Opción remota (hosted, recomendada). GitHub aloja el servidor y el login es por OAuth, así que no manejas tokens. Necesitas un cliente compatible (por ejemplo VS Code 1.101 o superior, o cualquier cliente que entienda transporte HTTP de MCP). Añades a la configuración del cliente el bloque que aparece en el frontmatter, dentro de servers (no mcpServers) y con type: "http". Al conectarte por primera vez, el cliente te abre el flujo de OAuth en el navegador. Tú apruebas el acceso desde la cuenta de GitHub real, eliges qué organizaciones quedan dentro del alcance y el cliente recibe la sesión. A partir de ahí no hay token que filtrar, porque no hay token en tu disco.

Opción local con Docker. Si prefieres correr el servidor en tu propia máquina, por privacidad o por trabajar offline, este es el camino. Necesitas Docker instalado y corriendo, y un token personal (PAT). Crea el PAT en github.com/settings/personal-access-tokens/new y, muy importante, dale solo los permisos mínimos para lo que vas a hacer. Si solo vas a gestionar issues, no le marques permisos de admin de organización ni de escritura en packages. Cuanto menos permiso, menos margen para sorpresas. Después pegas en el cliente el bloque que aparece en el frontmatter, sustituyendo TU_TOKEN por el valor real. Docker tiene que estar corriendo cuando arranques el cliente, o el servidor no levantará.

En ambos casos, una vez añadida la configuración, cierra el cliente por completo y vuélvelo a abrir. La primera vez que el agente quiera tocar GitHub, te pedirá confirmación; a partir de ahí queda activo durante la sesión.

Si trabajas con varias cuentas (una personal y una de empresa), conviene tener perfiles de configuración separados para no mezclarlas. La hosted lo resuelve eligiendo cuenta en el OAuth; con PAT, simplemente generas un PAT distinto por cuenta y los mantienes en clientes diferentes.

Seguridad y permisos

Este MCP toca cosas que viven fuera de tu disco: si el agente abre un PR mal redactado, queda en tu cuenta y lo ve el equipo. Por eso conviene revisar todas las acciones de escritura (crear issue, comentar, abrir PR, mergear) antes de aprobarlas. La opción remota con OAuth es claramente más segura que la local con PAT, porque no hay un secreto guardado en tu disco que se pueda filtrar.

Si usas PAT, trátalo como una contraseña: nunca lo pegues en chats públicos, en capturas, ni en repositorios. Si por error queda expuesto (sobre todo si subes el JSON de config a un repo), revócalo desde la pantalla de tokens y genera uno nuevo. Limítalo a los repos que el agente realmente necesita tocar; los PAT de “fine-grained” permiten justamente eso. Y si trabajas en cuentas de organización, asegúrate de que tu admin esté al tanto: en muchas empresas hay políticas sobre qué tokens pueden vivir en máquinas locales.

Casos de uso reales

Una mantenedora de un proyecto open source conecta el MCP y le pide al agente “agrupa los issues abiertos de la última semana por área, marca los que parecen duplicados y propónme respuestas para los de incorporación”. El triaje del fin de semana, que antes le costaba dos horas, sale en quince minutos de revisión.

Un equipo pequeño automatiza el feedback inicial de PRs: el agente lee el diff, comprueba que se actualizaron los tests y deja un comentario con su lectura antes de que un humano lo mire. No reemplaza la revisión, pero la prepara.

Un técnico que llega a un repo nuevo le pide “lee el README, el archivo principal y los últimos cinco commits, y dime qué hace este proyecto y qué se está moviendo ahora mismo”. En cinco minutos tiene un brief que en condiciones normales le habría llevado media mañana.

Errores comunes y cómo evitarlos

• Confundir la clave servers con mcpServers. La opción hosted usa servers (transporte HTTP); la local con Docker usa mcpServers. Si pegas el bloque equivocado en el sitio equivocado, el cliente no carga nada.
• Docker apagado. El bloque local arranca docker run; si Docker no está corriendo, el servidor no aparece. Comprueba primero con docker ps que el daemon esté vivo.
• PAT con permisos insuficientes. Si el agente te dice “no tengo permiso para abrir un issue en este repo”, suele ser que el PAT no incluye el repo o el scope issues:write. Revisa el token, no el código del servidor.
• OAuth caducado. En la opción hosted, las sesiones pueden expirar. Si de pronto el MCP “deja de funcionar”, vuelve a hacer el login desde el cliente.
• Acciones de escritura aprobadas sin leer. Aprobar a ciegas un “abre este PR” puede llenarte el repo de basura. Léete el título y el cuerpo antes de pulsar permitir.
• Tokens en el repo. Si por accidente subes el JSON con el PAT a GitHub, revócalo inmediatamente: los bots de scraping de tokens los encuentran en minutos.

Combinarlo con otros MCPs y skills

GitHub se complementa muy bien con el MCP de filesystem (para leer y editar el código local antes de abrir el PR) y con Firecrawl (para enriquecer issues con información externa, por ejemplo un enlace a una documentación oficial). Si usas Claude Code, las skills de revisión de código y de gestión de PRs se apoyan en este MCP para cerrar el círculo entre “leer el diff” y “comentar en el PR real”.

Mini-ejercicio

Conecta el MCP (preferiblemente la opción remota con OAuth) y pídele al agente “lista los tres últimos issues abiertos en mi repo X y resume cada uno en una frase”. Después pídele que abra un issue de prueba con título “Prueba MCP” y cuerpo “Este issue lo creó un agente”. Sabrás que está bien si el issue aparece en tu repo y puedes cerrarlo a mano para terminar.