Sam Morrow y sus colegas empezaron a construir el servidor MCP de GitHub como un proyecto paralelo interno. Un año después, con un inicio accidentado, es el servidor MCP remoto más usado del mundo. Sam tiene mucho que enseñarnos sobre escalar el diseño de herramientas, auth, y lo que los agentes realmente necesitan de un servidor empresarial.

Este artículo es una adaptación de MCP MVP, una serie de videos que destaca a las personas construyendo el futuro agéntico. Este episodio presenta a Sam Morrow, Lead Developer del GitHub MCP Server.

A principios de 2025, un product manager llamado Toby Padilla, fundador de Charm (la herramienta que hace bellos los CLIs de Go) publicó un mensaje en un canal interno de Go en GitHub: “¿A alguien le interesa hacer un servidor MCP?”

Sam Morrow era ingeniero de software en el equipo de Code Scanning. Él y dos colegas, William y Javier, se ofrecieron voluntarios en su tiempo libre. Tomaron el MCP-Go SDK no oficial (que después migraron a el SDK oficial de Go cuando se lanzó) y empezaron a construir. Javier incluso vibe-codeó las primeras herramientas.

Por esa misma época, GitHub organizó un “mobility march” interno que permitía a los ingenieros unirse a equipos de Copilot. Sam aplicó a Agent Services, un equipo que trabajaba en partes de lo que se convertiría en GitHub Copilot coding agent.

Luego, por un accidente de agendas cambiantes, el repositorio open-source del servidor MCP de GitHub se lanzó el mismo día que VS Code lanzó el modo Agente, un lanzamiento originalmente programado para el día anterior. ¡Cada blog post de “esto es lo que puedes hacer con el modo Agente” apuntaba al servidor MCP de GitHub como ejemplo!

El CEO de GitHub publicó al respecto. Satya Nadella reposteó la noticia. ¡El repo del servidor MCP de GitHub se convirtió en el repositorio con más estrellas en GitHub durante esa semana! Pero los problemas llegaron pisándole los talones al éxito.

Cuando adopción ≠ éxito

El lanzamiento viral generó visibilidad, pero la visibilidad no siempre es la mejor medida del éxito. El equipo no había planeado para tanta atención. Desarrolladores e ingenieros pusieron en entredicho los supuestos del equipo sobre cómo los usuarios interactuarían con el servidor, y los comentarios llegaron a raudales.

El equipo había adoptado un enfoque granular para cubrir la superficie de la API de GitHub, y el servidor se lanzó con más de 100 herramientas para issues, PRs, repos, Actions, code scanning, gists y más. A principios de 2025, la mayoría de los modelos de los agentes tenían dificultades con apenas 20 herramientas en contexto. Los usuarios no seleccionaron las herramientas del servidor como se esperaba; las cargaban todas en el contexto de su agente y se frustraban cuando el agente fallaba.

El equipo descubrió que mapear herramientas demasiado cerca de los endpoints de la API REST obligaría a un agente a encadenar múltiples operaciones atómicas de CRUD (Crear-Leer-Actualizar-Eliminar) para flujos de trabajo comunes, algo con lo que los agentes aún batallan. Sam reconoció el trade-off: “El mapeo uno a uno con APIs era un mal objetivo. Tratábamos de capturar intención.” Pero consolidar herramientas limita lo posible, y los usuarios de GitHub van desde quienes solo usan repos y PRs hasta quienes ejecutan flujos de trabajo complejos de múltiples proyectos con GitHub Projects.

El problema no era que el servidor MCP de GitHub tuviera demasiadas herramientas. Era que necesitaban mejores formas para que usuarios y agentes seleccionaran las herramientas correctas según sus intenciones.

Consejos para quienes construyen servidores MCP empresariales

Durante el último año, el equipo de Sam construyó y reconstruyó el servidor a través de adopción real a escala masiva. En una entrevista reciente con RL Nabors para la serie MCP MVP de Arcade.dev, Sam compartió los siguientes consejos para construir servidores MCP empresariales hoy.

Empieza por los prompts

Al diseñar herramientas MCP, empieza identificando los prompts que los usuarios ya están usando.

Los agentes van a buscar herramientas que “suenen como una solución” antes de encadenar varias juntas. Por ejemplo, un agente de redes sociales con la tarea de dejar de seguir a los mutuos de una cuenta tendrá más éxito con una herramienta “unfollow-users-followers” que orquestando “get-followers-by-user” dos veces y llamando a “unfollow-user” en cada miembro del cruce. (Y aunque esa operación podría ejecutarse fácilmente con Code Mode, para acciones que requieren autorización, las herramientas MCP autorizables son una de las opciones más seguras para un servidor remoto.)

El equipo de Sam intentó prototipar selección dinámica de herramientas usando embeddings para hacer coincidir la intención del agente con los toolsets relevantes en tiempo de ejecución. Funcionó, pero lo archivaron: “Decidimos que no éramos el nivel correcto en el stack para resolver ese problema.” El costo en tokens de expandir dinámicamente de 3 herramientas a 21 era real, y se sentía como algo que el agente harness o una solución de búsqueda de herramientas como la búsqueda de herramientas de Anthropic debería manejar.

Agrupa tus herramientas semánticamente y hazlas componibles

El servidor MCP de GitHub introdujo toolsets, agrupaciones semánticas como issues , repos , pull_requests , actions, y code_securityLos toolsets mapean cómo la gente realmente piensa sobre los productos de GitHub. Con algo de configuración JSON, los ingenieros pueden elegir exactamente el subconjunto de 108 herramientas que usan sus flujos de trabajo.

Los toolsets son componibles. ¿Quieres acceso de solo lectura a issues? Configura issues más read-onlyel modo para obtener la intersección exacta.

Los toolsets son robustos. Si la superficie del servidor MCP cambia, como que cuatro herramientas se consoliden en dos, el toolset sigue funcionando.

En lugar de crear una herramienta por cada endpoint de tu API, crea toolsets significativos y componibles que correspondan a patrones comunes de flujo de trabajo.

Escribe mensajes de error para agentes, no para terminales

La mayoría de los servidores MCP heredan mensajes de error de estilo CLI: escuetos, técnicos y difíciles de interpretar incluso para personas que conocen bien el sistema. Un agente ve fatal: could not sign commity de inmediato intenta deshabilitar la firma de commits porque no queda claro cuáles son los siguientes pasos.

Piensa en el agente como un ingeniero junior que se encuentra con estos problemas por primera vez. Si los mensajes de error asumen un depurador sin experiencia y están escritos para que un humano los entienda, el modelo del agente tiene mucho más fácil seguir el camino correcto.

Sam recomienda explicar qué pasó en lenguaje sencillo y sugerir los siguientes pasos. En lugar de “403 Forbidden”, usa “Intenté hacer commit, pero el usuario necesita autorizar la firma de commits. Pide al usuario que apruebe el prompt del agente SSH.” Si es un fallo terminal, dilo explícitamente, explica por qué y dile al agente que continúe en lugar de reintentar.

“Realmente toman el timón”, dijo Sam sobre los modelos que leen las respuestas de error.

Un agente que recibe un mensaje de error útil suele autocorregirse. Uno que recibe un mensaje críptico empieza a “atacar el problema” probando soluciones creativas que lo alejan cada vez más de la intención del usuario.

Filtra las herramientas según lo que el token de auth realmente puede hacer

Una de las innovaciones más interesantes del servidor MCP de GitHub es filtrar herramientas según los scopes reales del token de autenticación, algo que el newsletter de Pulse MCP destacó recientemente.

Si te conectas con un token de acceso personal clásico sin scopes de escritura, el servidor muestra solo 20 herramientas de solo lectura. Con un token con más privilegios obtienes 40, incluyendo operaciones de escritura. Si a un token le falta solo el scope gistpierdes las herramientas de gist pero conservas todo lo demás. Para los tokens de GitHub Actions, que no tienen identidad de usuario, el servidor elimina las herramientas específicas de usuario porque nunca funcionarán en ese contexto.

“Sabes exactamente qué herramientas van a funcionar porque son las que tienes”, dijo Sam. “Y al contrario, no vas a obtener herramientas que nunca funcionarán.”

Para el servidor remoto, el equipo fue más allá con los scope challenges de OAuthscope challengessi a tu token le falta un scope necesario, el servidor devuelve un payload especial que le indica al Agent Harness que te pida autorizarlo. Apruebas el scope y la llamada original a la herramienta tiene éxito sin necesidad de reintentar. Es autorización progresiva: empieza con scopes mínimos y escala según el agente los necesite.

Usa la propiedad annotationsde las herramientas MCP

Sam es enfático sobre una parte infrautilizada de la especificación MCP: annotations. Son metadatos en las herramientas MCP que le indican al agente harness cosas como “esta herramienta es de solo lectura”, “esta herramienta es destructiva”, “el output de esta herramienta viene de internet abierto y podría contener prompt injection”.

“Es bueno que tu sistema agéntico sepa cuándo va a ocurrir algo destructivo”, dijo Sam. En VS Code y el Copilot CLI, las annotations activan diálogos de confirmación para operaciones de escritura y destructivas, creando un momento entre que el modelo decide llamar a una herramienta y que la llamada se ejecuta, manteniendo al humano en el loop.

Sam está co-redactando una propuesta de mejora de la especificación con un colega de OpenAI para mejorar el sistema de annotations. El vocabulario actual no es lo suficientemente granular para casos de uso emergentes como MCP Apps, donde saber si una acción es reversible importa tanto como saber si es destructiva.

Diseña para el loop, no para el modelo

Sam quiere que más builders interioricen que el modelo no es el agente. El software no es el agente. El servidor MCP definitivamente no es el agente. El agente es el loop.

“En realidad solo estás ejecutando cosas en un loop”, dijo. “Y el modelo decide qué hacer a continuación.” Dentro de ese loop, antes de que el modelo decida y antes de que esa decisión se ejecute, hay momentos donde el harness puede interceptar una llamada a una herramienta, revisar sus annotations, pedirle confirmación al usuario, inspeccionar la respuesta en busca de contenido de internet abierto y decidir si inyectarla en el contexto.

Esos momentos “no tienen nada que ver con los modelos, pero son muy importantes para proteger al usuario”. Entenderlos te ayuda a diseñar un servidor MCP de forma integral, incorporando el modelo, el Agent Harness, el usuario y el conjunto de límites de confianza entre ellos.

Esto también significa que el diseño de herramientas “correcto” depende del contexto de ejecución. El Copilot CLI puede escribir respuestas grandes de herramientas en archivos temporales y luego dejar que el agente haga grep sobre ellos. Esto le permite al agente buscar una aguja en un pajar sin saturar su contexto. Un agente basado en chat no puede hacer eso.

“Todas estas mejores prácticas que van y vienen se cuestionan cada día según el contexto de ejecución”, dijo Sam. “Revisa las funciones avanzadas de los agentes que realmente estás usando.”

Qué viene después

El servidor MCP de GitHub lanza nuevas funciones detrás de un flag de insiders. Solo agrega /insiders a la URL del servidor remoto o configura el header. Es fácil unirse y fácil salir. Reporta issues o inicia discusiones en github.com/github/github-mcp-server.

Sam también está proponiendo un nuevo grupo de trabajo AAIF para desarrollar mejores annotations de herramientas. Si te interesa dar forma a los estándares, el repositorio de la especificación MCP y su Discord son donde ocurre ese trabajo. La comunidad es lo suficientemente pequeña como para que tu opinión se lea, y lo suficientemente receptiva como para que recibas retroalimentación.

“Si publicas un comentario, la gente lo leerá y te responderá”, dijo sobre la comunidad MCP. “Incluso David”, uno de los co-creadores de MCP, “lo ves en el Discord todo el tiempo.”

MCP MVP es una serie de videos de Arcade que destaca a los builders que dan forma al ecosistema agéntico. Mira la entrevista completa con Sam Morrow →

¿Construyes servidores MCP empresariales y quieres manejar auth sin tokens PAT en archivos JSON? Mira las herramientas de GitHub de Arcade para integración MCP nativa con OAuth.