GitHub MCP Server — Add-ons e integraciones

GitHub MCP Server

✓ Oficial★ 31.389

Servidor MCP mantenido por el propio GitHub para repos, pull requests, issues, búsqueda de código e información de CI/CD — remoto o local, con inicio de sesión OAuth.

El GitHub MCP Server conecta agentes directamente con la plataforma GitHub — en dos modos de funcionamiento. El servidor remoto lo aloja el propio GitHub en https://api.githubcopilot.com/mcp/ y, según el README, es la forma más sencilla de empezar: inicio de sesión vía OAuth en el navegador (el token permanece entonces solo en memoria), o alternativamente con un Personal Access Token (PAT) en el header Authorization: Bearer. Quien quiera mantenerlo todo en local puede iniciar el servidor como contenedor Docker (ghcr.io/github/github-mcp-server) con PAT o callback OAuth — o compilarlo él mismo desde el código fuente con go build.

Las capacidades están organizadas en toolsets que se pueden activar y desactivar de forma selectiva: repos (operaciones de repositorio), issues, pull_requests, actions (CI/CD), code_security (escaneo de código y de secretos), además de dependabot, discussions, gists, projects, orgs, users, notifications y labels. Sin especificar nada, están activos por defecto context, repos, issues, pull_requests y users. La selección se controla con el flag --toolsets o la variable de entorno GITHUB_TOOLSETS; herramientas individuales se pueden activar mediante GITHUB_TOOLS. Un flag --read-only desactiva todas las herramientas de escritura — útil cuando el agente solo debe analizar, sin modificar nada.

Con esto, un agente puede triar issues, crear y revisar pull requests, inspeccionar ejecuciones de CI y buscar código entre repositorios — con soporte oficial del proveedor por parte de GitHub, en lugar de una solución improvisada por la comunidad.

🔧 SETUP

La vía más sencilla (remoto): registrar el servidor alojado en el cliente MCP como servidor HTTP: `{"servers": {"github": {"type": "http", "url": "https://api.githubcopilot.com/mcp/"}}}` — inicio de sesión después vía OAuth en el navegador
Alternativamente con Personal Access Token en lugar de OAuth: configurar además el header `"Authorization": "Bearer <PAT>"`
En local en lugar de remoto: `docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN=<your-token> ghcr.io/github/github-mcp-server`
Restringir los toolsets según se necesite, p. ej. `--toolsets repos,issues,pull_requests,actions` o mediante la variable de entorno `GITHUB_TOOLSETS="repos,issues,pull_requests"`
Para tareas puramente de análisis, activar el flag `--read-only` — así se omiten las herramientas de escritura

✅ ¿CUÁNDO USARLO?

Trabajo de PR e issues directamente desde el agente

«Resume los issues abiertos con la etiqueta ‘bug', priorízalos y crea para el más crítico una rama con un PR en borrador» — todo mediante las herramientas oficiales de GitHub, sin cambiar al navegador.

Diagnosticar fallos de CI/CD

Con el toolset `actions`, obtener la ejecución de workflow fallida del último push, analizar los logs y que se sugiera directamente una solución.

⛔ ¿CUÁNDO MEJOR NO?

Operaciones de git locales en el directorio de trabajo

El servidor habla con la API de GitHub — no ve commits, ramas ni diffs en un estado de trabajo local aún no subido.

Mejor: Hacer el trabajo de git local con la CLI de git normal del agente; usar el GitHub MCP Server para la parte de plataforma (PRs, issues, actions).

El agente solo debería leer, pero obtiene acceso de escritura completo

Con los toolsets estándar y un PAT con permisos amplios, el agente puede modificar issues, PRs y más — más permisos de los necesarios son un riesgo innecesario.

Mejor: Activar `--read-only`, elegir toolsets mínimos y usar un PAT de granularidad fina con la menor cantidad de scopes posible.