Conecta el GitHub MCP server a VS Code, Claude Desktop o Cursor con OAuth o con un token acotado, recorta sus definiciones de herramientas con toolsets y el modo de solo lectura, y gestiona los límites de 5.000 por hora y 80 por minuto de GitHub sin sorpresas de 403 o 429.
Conecta el GitHub MCP server a tu editor y un agente de IA podrá leer incidencias, revisar pull requests y crear ramas en tu nombre. Además, carga una larga lista de definiciones de herramientas en cada conversación y consume el presupuesto de solicitudes del token que le des. Tres factores deciden si la configuración resulta fluida o dolorosa: cómo te conectas, cuántos tokens de contexto consume el servidor y qué límites de uso alcanzas primero.
Todas las cifras de abajo provienen de la documentación de GitHub o de mediciones de la comunidad publicadas en 2026, y cada una está señalada como tal. Los recuentos de tokens, en particular, cambian entre versiones del servidor, así que tómalos como rangos y no como promesas. Lo mismo vale para cualquier cifra que leas sobre herramientas MCP: comprueba la versión con la que se midió antes de planificar un presupuesto a partir de ella.
💡 Versión corta: usa el servidor remoto, dale un token acotado, activa solo los toolsets que uses y espera al menos un minuto cuando GitHub responda 403 o 429.
Ambas opciones exponen las mismas herramientas de GitHub. Lo que cambia es quién ejecuta el proceso y cómo inicias sesión. Si eliges mal, acabarás manteniendo Docker en cinco equipos portátiles o esperando a GitHub por una función que necesitabas ayer.
GitHub aloja el servidor remoto en https://api.githubcopilot.com/mcp/. Tu cliente apunta a esa URL e inicias sesión desde el navegador con OAuth, o envías un token de acceso personal en una cabecera Authorization. No hay nada que instalar ni que actualizar, porque las nuevas herramientas llegan según el calendario de GitHub, no según el tuyo.
El mismo host ofrece una variante insiders en https://api.githubcopilot.com/mcp/insiders para funciones tempranas. Pruébala en una máquina de pruebas antes de que toque tu configuración diaria.
El servidor local se distribuye como la imagen ghcr.io/github/github-mcp-server. Tu cliente la lanza con docker run -i --rm y se comunica con ella por stdio. Tú eliges la versión, controlas cada variable de entorno y puedes apuntarlo a GitHub Enterprise Server con GITHUB_HOST. El precio es tener Docker en cada equipo y un token guardado en un archivo de configuración.
| Servidor remoto | Servidor local con Docker | |
|---|---|---|
| Instalación | Ninguna | Imagen de Docker |
| Inicio de sesión | OAuth o un token en una cabecera | Token en GITHUB_PERSONAL_ACCESS_TOKEN, o OAuth con un puerto de callback |
| Actualizaciones | Gestionadas por GitHub | Tú descargas la imagen |
| GitHub Enterprise Server | No compatible | Compatible mediante GITHUB_HOST |
| Ideal para | La mayoría de desarrolladores individuales | Versiones fijadas y Enterprise Server |
Todos los fragmentos de código de abajo vienen del README del proyecto. Pega uno, reinicia el cliente y pide al agente que liste tus pull requests abiertas como prueba rápida. Si aparece la lista, la conexión funciona y todo lo que venga después es ajuste fino.
La vía más corta. No hay que crear ningún token ni guardar ningún secreto.
{
"servers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/"
}
}
}
VS Code abre una pestaña del navegador, apruebas el acceso y la credencial se guarda en memoria en lugar de acabar en un archivo.
Usa esta vía si tu cliente no admite el flujo de OAuth o si quieres un token limitado a permisos concretos.
{
"servers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer ${input:github_mcp_pat}"
}
}
},
"inputs": [
{
"type": "promptString",
"id": "github_mcp_pat",
"description": "GitHub Personal Access Token",
"password": true
}
]
}
La marca password: true oculta el valor cuando VS Code lo pide, así que el token nunca queda escrito en el archivo que podrías subir a un repositorio.
Claude Desktop inicia el servidor local de Docker y le pasa el token mediante una variable de entorno:
{
"mcpServers": {
"github": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"],
"env": {"GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here"}
}
}
}
Sustituye your_token_here por un token real y mantén este archivo fuera del control de versiones. Cursor acepta una estructura parecida a la de los ejemplos de VS Code.
💡 Si hay configurados un token y OAuth a la vez, gana el token. La documentación del proyecto indica que
GITHUB_PERSONAL_ACCESS_TOKENtiene prioridad sobre OAuth.
El token es la única parte de esta configuración que puede perjudicarte. Un agente con un token amplio puede hacer todo lo que ese token permita, incluidos errores que nunca cometerías a mano.
El README recomienda tres scopes:
| Scope | Lo que permite |
|---|---|
repo | Operaciones con repositorios |
read:packages | Acceso a imágenes de Docker |
read:org | Acceso a equipos de la organización |
Empieza con repo y añade los demás solo cuando una herramienta falle con un error de permisos. Si solo trabajas con unos pocos repositorios, un token de grano fino limitado a esos repositorios es todavía más estricto. Usa un token distinto para cada proyecto, así revocar uno no rompe los demás.
Tres hábitos evitan la mayoría de las filtraciones:
chmod 600 ~/.your-app/config.json.
Un cliente MCP carga en el contexto del modelo las definiciones de todos los servidores conectados para que el modelo sepa qué puede llamar. Esa carga cuenta contra tu ventana de contexto en cada solicitud, use el agente una herramienta o no. Las estimaciones de la comunidad sitúan una sola definición entre 300 y 600 tokens cuando sumas el nombre, la descripción y el esquema de parámetros.
El servidor de GitHub tiene muchas herramientas, por eso aparece en todas las conversaciones sobre el exceso de contexto.
Estas son mediciones de la comunidad publicadas en dev.to en 2026, no cifras de GitHub:
| Medición | Tokens | Herramientas | Fuente |
|---|---|---|---|
| Superficie completa de herramientas | unos 55.000 | 93 | Piotr Hajdas |
| Superficie completa de herramientas, recuento más bajo | unos 42.000 | no indicado | The Daily Agent |
| Solo los toolsets predeterminados | unos 4.200 | 26 | Ken Imoto |
Con una ventana de 200.000 tokens, la cifra de 55.000 supone más de una cuarta parte del espacio ocupado antes de que escribas una palabra. Los toolsets predeterminados suponen alrededor del 2%. Las cifras difieren porque la gente midió versiones distintas del servidor y configuraciones de toolsets distintas.
Tu cliente también importa. Según un artículo de 2026, Claude Code aplaza los esquemas de herramientas MCP tras un paso de búsqueda de herramientas por defecto, y una medición registró una reducción del 46,9% gracias a ello. Cursor, Windsurf y Gemini CLI cargan las definiciones desde el principio, así que pagan el precio completo.
Los toolsets activan o desactivan grupos enteros de herramientas. Sin ninguna configuración, el servidor habilita context, issues, pull_requests, repos y users. El resto de la lista son actions, code_quality, code_security, copilot, dependabot, discussions, gists, git, governance, labels, notifications, orgs, projects, secret_protection, security_advisories y stargazers. Los valores especiales all y default hacen lo que indica su nombre.
Para el servidor local, define GITHUB_TOOLSETS:
docker run -e GITHUB_PERSONAL_ACCESS_TOKEN=<token> \
-e GITHUB_TOOLSETS="repos,issues,pull_requests" \
ghcr.io/github/github-mcp-server
Para el servidor remoto, envía la cabecera X-MCP-Toolsets con la misma lista separada por comas:
{
"servers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer ${input:github_mcp_pat}",
"X-MCP-Toolsets": "repos,issues,pull_requests"
}
}
}
}
Dos controles más afinan el resultado. GITHUB_TOOLS (o la cabecera X-MCP-Tools) añade herramientas concretas por encima de tus toolsets, por ejemplo get_gist sin activar todas las de gists. X-MCP-Exclude-Tools elimina herramientas, y la documentación indica que las herramientas excluidas tienen prioridad sobre los toolsets y las herramientas individuales.
💡 Resiste la tentación de
all. Pasar de unos 4.200 tokens de definiciones a unos 55.000 te da herramientas que probablemente nunca usarás, y pagas por ellas en cada solicitud.
Dos interruptores reducen el radio de daño sin tocar tus toolsets:
| Modo | Servidor local | Servidor remoto | Efecto |
|---|---|---|---|
| Solo lectura | --read-only o GITHUB_READ_ONLY | X-MCP-Readonly: true, o la ruta /mcp/x/all/readonly | Desactiva todas las herramientas de escritura, incluso las que hayas pedido |
| Bloqueo | --lockdown-mode o GITHUB_LOCKDOWN_MODE | Cabecera X-MCP-Lockdown | Muestra solo contenido de repositorios públicos de usuarios con acceso de escritura |
El modo de solo lectura actúa como un filtro estricto que tiene prioridad sobre el resto de tu configuración, y las herramientas desactivadas también significan menos definiciones que cargar. El bloqueo importa cuando un agente lee incidencias o comentarios escritos por desconocidos, porque el texto de personas sin acceso de escritura es precisamente donde se esconden las instrucciones hostiles. En modo HTTP, una vez que un operador activa el bloqueo en el servidor, la cabecera X-MCP-Lockdown ya no puede desactivarlo para una sola solicitud.
El servidor llama a la API de GitHub con tu identidad, así que los límites que importan son los que GitHub documenta para su API REST. Se aplican dos niveles: un límite principal por hora y límites secundarios por minuto.
| Cliente | Límite |
|---|---|
| Sin autenticar | 60 solicitudes por hora |
| Usuario autenticado (token, aplicación OAuth o GitHub App) | 5.000 por hora |
| Aplicaciones propias o aprobadas por organizaciones de Enterprise Cloud | 15.000 por hora |
| Instalaciones de GitHub App fuera de Enterprise | 5.000, con escalado hasta 12.500 |
GITHUB_TOKEN dentro de Actions | 1.000 por hora y por repositorio (15.000 en Enterprise Cloud) |
A 5.000 por hora, son unas 83 llamadas por minuto de media. Un agente que lista las incidencias de un repositorio, abre cada una y luego lee todos los comentarios puede gastar cientos de llamadas en pocos minutos, así que el presupuesto por hora es una restricción real durante las grandes sesiones de triaje de incidencias.
Los límites secundarios existen para frenar las ráfagas, y los agentes generan ráfagas. GitHub documenta estos:
Las llamadas a herramientas en paralelo se acumulan contra el límite de concurrencia. Un agente que comenta decenas de incidencias en un bucle alcanza el tope de 80 solicitudes de contenido por minuto mucho antes de tocar el presupuesto por hora.
Cuando se activa un límite, GitHub responde con 403 o 429. Lee las cabeceras de la respuesta antes de cambiar nada:
| Cabecera | Significado |
|---|---|
x-ratelimit-limit | Máximo de solicitudes por hora |
x-ratelimit-remaining | Solicitudes restantes en la ventana actual |
x-ratelimit-used | Solicitudes realizadas en la ventana actual |
x-ratelimit-reset | Momento en que se reinicia la ventana, en segundos epoch UTC |
x-ratelimit-resource | Recurso al que se contabilizó la solicitud |
retry-after, espera esa cantidad de segundos.x-ratelimit-reset.Incluye también esta regla en las instrucciones de tu agente: cuando GitHub devuelva 403 o 429, debe detenerse e informar en lugar de reintentar. Un agente que reintenta de inmediato solo gasta más solicitudes contra un límite que aún no se ha reiniciado.
El servidor MCP de GitHub devuelve material en bruto: listas de incidencias, diffs e hilos de comentarios. Un modelo de lenguaje convierte eso en decisiones. Claude Sonnet 5 en PicassoIA maneja tareas de programación de varios pasos y de uso de herramientas, lee capturas de pantalla y te deja elegir cuánto esfuerzo dedica a pensar, lo que lo convierte en un buen segundo par de ojos sobre lo que devuelve tu agente de GitHub.
low es el predeterminado y el más rápido, mientras que high o max encaja mejor con un error que afecta a varios archivos.PicassoIA también ofrece su propia API para desarrolladores y un conector MCP, y se aplica la misma lógica de límites. La API está en https://api.picassoia.com/v1, acepta credenciales Bearer que empiezan por pia_sk_ y ejecuta los trabajos de forma asíncrona: creas una predicción, la consultas y luego obtienes el resultado. Se puede acceder a cuatro modelos mediante la API y MCP: PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video y Seedance 2.5 Lite. Una cuenta puede ejecutar 5 predicciones simultáneas, compartidas entre credenciales y conexiones MCP. Es la misma lección que las 100 solicitudes simultáneas de GitHub: el límite de concurrencia es el primer muro con el que choca un agente en paralelo.
Tu README, las notas de versión y las plantillas de incidencias se leen mejor con una imagen real arriba. Genera una cabecera fotorrealista con PicassoIA Image y luego ajusta el encuadre o corrige un detalle con PicassoIA Image Editor Pro.
Tres prompts que vale la pena probar hoy:
Elige uno, genera unas cuantas variaciones y mira cuál hace que la página de tu próximo repositorio destaque. Empieza a crear tus propias imágenes con Picasso IA y experimenta hasta que el resultado parezca tu proyecto.
Elige tu idioma
