Mi setup de MCPs para programar con IA
Seguramente te ha pasado: le pides a tu IA que te implemente una feature, empieza a escribir código, parece que lo está pillando todo, y de repente… usa una API que ya no existe. O hace algo completamente distinto a lo que tenías en mente. O empieza a repetir las mismas preguntas que ya le contestaste hace cinco mensajes.
¿Por qué pasa eso? Muy sencillo: la IA trabaja a ciegas. No sabe cómo está estructurado tu proyecto. No sabe qué has decidido usar y qué no. No sabe que esa librería cambió su API en la versión 4. Tú lo sabes, pero ella no.
Y eso tiene solución. De hecho, tiene varias. En este post te cuento las herramientas y MCPs que uso para que la IA tenga todo ese contexto desde el principio y el resultado sea mucho, mucho mejor.
Planifica antes de picar código: Spec-Kit + Grill-with-Docs
Lo primero no es un MCP, pero va antes que todo lo demás. El problema del vibe coding - ese de “venga, hazme una app de gestión de tareas” y a ver qué sale - es que la IA improvisa. Y la IA improvisa bien, pero no tiene ni idea de tus restricciones, de tus decisiones de arquitectura ni de qué stack quieres usar. Al final acabas corrigiéndola constantemente.
La solución se llama Spec-Kit, de GitHub. Tiene más de 114.000 estrellas, así que no es precisamente una herramienta underground, pero mucha gente aún no la usa porque no entiende bien qué es.
Spec-Kit te da un flujo de trabajo estructurado para que tú y la IA estéis siempre en la misma página. Lo instalas con un comando, inicializas tu proyecto y te quedan disponibles una serie de slash commands o skills, según el agente que uses.
El flujo es este:
- Creas una constitución: un fichero con las reglas no negociables de tu proyecto - stack, estándares de código, lo que sea.
- Usas
/speckit.specifypara describir qué quieres construir. - Usas
/speckit.planpara el plan técnico. - Usas
/speckit.taskspara desglosar en tareas. - Cuando todo eso está validado,
/speckit.implementpara que la IA se ponga a implementar.
La diferencia con hacer el prompt directamente es enorme. La IA no inventa: ejecuta una especificación que tú has revisado. Es la respuesta seria al vibe coding.
Y aquí viene lo que combina perfectamente con Spec-Kit: Grill-with-Docs, de Matt Pocock. Esta no es una herramienta que instalas, es una skill, una técnica. La idea es que antes de escribir ni una línea de especificación, la IA te entrevista sobre tu proyecto. Te hace preguntas para que defináis juntos el lenguaje del proyecto - qué es un “usuario”, qué es una “sesión”, qué significa “publicar” en tu contexto concreto. Y mientras lo hacéis, va construyendo un fichero CONTEXT.md con todo ese vocabulario compartido.
¿Por qué importa eso? Porque a partir de ese momento la IA no tiene que reinventar los conceptos cada vez. Sabe exactamente de qué le estás hablando. Y el código que genera va a reflejar exactamente esa terminología. Si buscas “pitches” en tu codebase, aparece todo lo relacionado. Sin ambigüedades, sin que tenga que adivinar.
Mi recomendación: primero Grill-with-Docs para definir el lenguaje y el dominio, y luego Spec-Kit para el flujo de desarrollo. Van de la mano.
Dale contexto de tu código: CocoIndex-Code y CodeGraph
Ya tenemos la planificación. Ahora el problema de en medio: la IA tampoco conoce tu codebase. Cuando le pides que modifique algo, tiene que ir leyendo fichero a fichero, haciendo greps, buscando… y eso come tokens a espuertas y tarda un montón.
Hay dos herramientas que resuelven esto. Son parecidas pero no iguales, así que te las cuento a las dos y eliges la que más te convenga.
La primera es CocoIndex-Code. Es un motor de búsqueda semántica de código basado en AST - es decir, en el árbol de sintaxis de tu código, no en simple texto. Lo instalas en un minuto, cero configuración, y a partir de ahí funciona como MCP o como skill en tu agente. Lo que hace es indexar tu proyecto y permitir que la IA encuentre código por concepto, no por nombre exacto. Por ejemplo: “¿dónde se gestiona la autenticación de usuarios?” Y lo encuentra. Sus propios benchmarks dicen que ahorra un 70% de tokens. Y es completamente local, sin servicios externos.
La segunda es CodeGraph. Esta va un paso más allá: construye un grafo de conocimiento de tu código. No solo busca, sino que entiende relaciones. ¿Qué funciones llaman a esta otra función? ¿Qué se ve afectado si cambio esto? Sus benchmarks con Claude Code son bastante flipantes: 94% menos de tool calls y un 77% más rápido en exploración de código. También 100% local, usa SQLite. Lo instalas con un npx y configuras el MCP en Claude Code.
Entonces, ¿cuál usar?
- Si tu proyecto no es enorme y quieres algo que simplemente funcione desde el primer minuto → CocoIndex-Code.
- Si tienes un proyecto grande con mogollón de dependencias entre módulos y quieres que la IA entienda el impacto de cada cambio → CodeGraph.
No tiene mucho sentido tener los dos a la vez. Elige uno.
Docs actualizadas de librerías: Context7
Tercer problema: la IA usa la versión de la librería que tenía en su entrenamiento. Y eso puede ser de hace un año o más. ¿Te ha pasado que te genera código con una API que ya no existe? Pues eso es exactamente esto.
Context7 lo resuelve de manera muy elegante. Es un MCP que, cuando le pides algo de una librería, va a buscar la documentación oficial actualizada y la mete directamente en el contexto de la IA. Solo con añadir “use context7” a tu prompt, ya tiene las docs de la versión correcta.
Se instala con npx ctx7 setup, se autentica por OAuth y ya está. Tiene un tier gratuito más que suficiente para uso personal.
Gestiona tu repo sin salir del editor: GitHub MCP
Este ya es más conocido, pero lo incluyo porque lo uso a diario y es un antes y un después. El MCP oficial de GitHub te permite gestionar todo tu repositorio desde Claude Code sin abrir el navegador. Crear issues, revisar PRs, ver el estado de Actions, hacer commits… todo por lenguaje natural desde el terminal.
Lo mejor es que tiene un endpoint remoto ya preparado, así que no tienes que instalar nada en local. OAuth y listo. Y al ser oficial de GitHub, está bien mantenido y actualizado.
Automatización de navegador: Playwright MCP
Para cerrar el bloque principal, el MCP de Playwright, de Microsoft. Si alguna vez has querido que la IA interactúe con un navegador real - que navegue por una web, rellene un formulario, compruebe que tu app funciona - esto es lo que necesitas.
Lo interesante es que no usa capturas de pantalla. Trabaja con snapshots de accesibilidad, es decir, que lee la estructura de la página igual que lo haría un lector de pantalla. Es mucho más eficiente en tokens y más robusto que las soluciones basadas en imágenes.
Es perfecto para testing end-to-end, para automatizar tareas repetitivas en webs o para hacer scraping de forma fiable.
Bonus 1: Oh My OpenAgent (para usuarios de OpenCode)
Primer bonus, y antes de nada tengo que aclarar algo importante: esta herramienta no es para Claude Code. Es para OpenCode, que es otro agente de programación en terminal, el rival directo de Claude Code. Si no sabes qué es OpenCode, te lo explico en otro vídeo, pero básicamente es lo mismo pero agnóstico al modelo: puedes usar Claude, GPT, Gemini…
Si usas OpenCode, existe Oh My OpenAgent. Es un plugin que transforma completamente la experiencia: añade agentes especializados que trabajan en paralelo, herramientas de refactoring a nivel de AST, bucles de trabajo automáticos… es como convertir OpenCode en un equipo entero de IAs. Tiene más de 62.000 estrellas en GitHub, así que no es poca cosa.
Y aquí viene el dato clave: Oh My OpenAgent ya incluye Context7 por dentro. Así que si usas este plugin, no necesitas instalar Context7 por separado. Ya viene integrado.
Bonus 2: Coolify MCP (si tienes servidor propio)
El segundo bonus es para los que tengáis un servidor con Coolify. Coolify, por si no lo sabes, es una plataforma de self-hosting open source - como un Heroku pero tuyo, en tu VPS. Tengo vídeo en el canal sobre esto.
Pues existe el MCP de Coolify, que aunque no es oficial del proyecto sí está muy bien mantenido. Tiene 42 herramientas para gestionar todo tu servidor: desplegar aplicaciones, gestionar bases de datos, ver logs, manejar proyectos… todo desde Claude Code, por lenguaje natural. Si ya usas Coolify, instaladlo directamente.
Resumen: mi setup paso a paso
Vamos con un repaso rápido de lo que te llevas:
| Para qué | Qué uso |
|---|---|
| Planificar y especificar | Spec-Kit + Grill-with-Docs |
| Contexto del código | CocoIndex-Code o CodeGraph |
| Documentación actualizada de librerías | Context7 |
| Gestión del repo | GitHub MCP |
| Automatización de navegador | Playwright MCP |
| Si usas OpenCode | Oh My OpenAgent |
| Si usas Coolify | Coolify MCP |
Ojito con una cosa: no instales todo a la vez. Más de cinco o seis MCPs activos al mismo tiempo y el agente empieza a confundirse eligiendo herramientas. Empieza por los que más encajen con tu día a día y ve añadiendo.
Conclusión
La IA no tiene por qué trabajar a ciegas. Con el setup correcto de MCPs puedes darle el contexto que necesita para que deje de improvisar y empiece a ejecutar sobre especificaciones claras, código indexado y documentación actualizada.
No se trata de tener más herramientas, se trata de tener las que realmente usas. Empieza por uno o dos, intégralos en tu flujo y ve escalando desde ahí. La diferencia en la calidad del código que genera la IA es abismal.
Si has llegado hasta aquí y te ha sido útil, comparte el post con alguien que esté peleándose con la IA a diario. Y si tienes alguna herramienta que no haya mencionado, déjala en los comentarios del vídeo - me interesa muchísimo.
Referencias
- Spec-Kit en GitHub
- Grill-with-Docs de Matt Pocock
- CocoIndex-Code
- CodeGraph
- Context7
- GitHub MCP Server
- Playwright MCP
- Oh My OpenAgent
- Coolify MCP


¿Qué te ha parecido?
Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .