Skills, MCP y repos: la nueva pila para construir con agentes

Me he encontrado con una de esas listas virales de “las 90 herramientas de IA que importan ahora mismo”. En concreto, un hilo de @zodchiii en X que mezcla Claude Skills, MCP servers y repos de GitHub en una sola recopilación.

Y aunque la lista está bien como punto de partida, creo que la lectura útil no es copiar 90 enlaces en favoritos.

La lectura útil es otra:

Ya tenemos una nueva pila de trabajo para agentes.
Y no está formada por “un modelo muy bueno”, sino por tres capas que se combinan.

La idea importante no es la lista: es la pila

Si tuviera que explicarlo rápido, hoy el trabajo con agentes se está ordenando en tres niveles:

Skills: enseñan al agente cómo resolver mejor una clase de problema.
MCP: le dan acceso a herramientas, datos y sistemas externos.
Repos / frameworks: ponen la infraestructura para orquestar todo eso en flujos reales.

Dicho de forma menos marketiniana:

las skills encapsulan criterio,
el MCP conecta con el mundo,
los repos convierten el experimento en sistema.

Ese es el patrón que sí merece atención.

1. Skills: menos prompt suelto, más comportamiento reutilizable

Lo que más me interesa del ecosistema de skills no es que haya decenas de miles. Eso, por sí solo, no significa demasiado.

Lo importante es que empiezan a actuar como una capa reusable de know-how. No como un prompt bonito, sino como una forma de empaquetar:

pasos,
criterios,
buenas prácticas,
formato de salida,
y a veces hasta herramientas o flujos asociados.

Eso cambia bastante el juego, porque reduce uno de los grandes problemas de trabajar con LLMs en equipos: cada persona acaba redescubriendo su propio ritual de prompting.

Algunas de las skills que aparecen en el hilo y que sí me parecen interesantes por utilidad real son estas:

PDF Processing: porque el mundo sigue funcionando con PDFs, nos guste o no.
DOCX / XLSX / PPTX: poco glamour, mucha utilidad en entornos reales.
Frontend Design: interesante cuando quieres escapar del UI genérico que producen muchos agentes.
Skill Creator: meta-herramienta útil para convertir un flujo repetitivo en algo reutilizable.
Brand Guidelines: especialmente valiosa si publicas contenido o generas piezas con un tono y estilo reconocibles.
Systematic Debugging y Context Optimization: dos ejemplos claros de skills que no venden “magia”, sino disciplina.

Mi impresión aquí es bastante simple: las mejores skills no son las más espectaculares; son las que eliminan fricción recurrente.

2. MCP: cuando el agente deja de opinar y empieza a operar

Para mí, la capa más importante no son las skills. Es el MCP.

Porque una skill puede mejorar el razonamiento o la estructura de trabajo del agente, pero el valor cambia de nivel cuando ese agente puede:

buscar documentación actualizada,
consultar una base de conocimiento,
navegar una web,
leer un sistema externo,
modificar archivos,
o ejecutar una tarea dentro de un entorno controlado.

Ahí deja de ser un generador de texto mejorado y empieza a parecerse a un operador software.

De la selección del hilo, hay tres piezas que me parecen especialmente representativas:

Context7

Me gusta mucho la propuesta de inyectar documentación actualizada de librerías y frameworks dentro del contexto del modelo.

No porque sea una idea nueva, sino porque ataca una de las fuentes más tontas de error en agentes de código: trabajar con APIs antiguas, ejemplos obsoletos o recuerdos difusos del modelo.

Si una herramienta me reduce alucinaciones sobre Next.js, React, Supabase o cualquier SDK vivo, ya me está devolviendo tiempo.

Tavily

La búsqueda para agentes tiene que ser distinta a la búsqueda para humanos. Un agente no necesita diez pestañas bonitas: necesita resultado utilizable, limpio y estructurado.

Por eso tiene sentido que existan herramientas como Tavily. No resuelven todo, pero encajan mejor en un flujo automatizado que un buscador genérico pensado para clics humanos.

Task Master AI

Este tipo de piezas me interesan porque atacan un problema muy real: la tendencia de los agentes a dispersarse.

Darles un PRD y convertirlo en tareas con dependencias no es “más IA”; es más gestión del trabajo. Y eso, en la práctica, suele tener más impacto que cambiar de modelo cada dos semanas.

3. Repos y frameworks: donde empieza la parte seria

La tercera capa es la de repos, frameworks y herramientas open source que convierten estas capacidades en algo operativo.

Aquí ya no hablamos sólo de “qué sabe hacer el agente”, sino de cosas bastante más terrenales:

persistencia,
memoria,
sandboxing,
automatización,
observabilidad,
seguridad,
multiagente,
ejecución local o remota.

De todo lo que aparecía en la recopilación, yo separaría varias categorías.

Infraestructura de agentes

OpenClaw
LangGraph
CrewAI
Dify
pydantic-ai

No las metería en el mismo saco, pero sí dentro de la misma conversación: cómo diseñas sistemas agentic que no dependan de una única sesión efímera.

Personalmente, cada vez me interesan más las herramientas que resuelven bien dos cosas:

estado y continuidad,
orquestación clara sin magia innecesaria.

Automatización y workflows

n8n
Langflow
Huginn

Aquí el punto no es sólo “hacer automatizaciones con IA”, sino conectar IA con procesos existentes sin reinventar media empresa.

Si una startup ya tiene formularios, CRMs, Slack, correo, dashboards y procesos manuales, probablemente gane antes valor con una automatización razonable que con un agente espectacular en una demo.

Datos, búsqueda y extracción

Firecrawl
GPT Researcher
Vanna AI
dlt

Esta capa me parece crítica porque muchísimos casos de uso “de IA” son en realidad problemas de acceso, limpieza y transformación de datos. El modelo ayuda, sí, pero la ventaja competitiva suele estar en cómo alimentas ese sistema.

Seguridad y gobierno

promptfoo
agent-governance-toolkit
claude-code-security-review
entornos aislados tipo e2b/desktop o similares

Esto es lo que más echo de menos en muchas listas virales: se habla muchísimo de capacidad y poquísimo de control.

Y en cuanto empiezas a dar permisos de lectura, escritura, navegación o ejecución a un agente, la conversación deja de ser “qué productivo es” y pasa a ser también:

qué puede romper,
qué puede filtrar,
cómo auditamos lo que hace,
y qué límites tiene el entorno.

Mi lectura práctica: qué instalaría primero

Si hoy tuviera que montar un stack sensato para un builder individual o un equipo pequeño, no empezaría por 90 herramientas.

Empezaría por una combinación bastante más corta:

Capa 1: comportamiento

una skill de debugging,
una skill de context engineering,
una skill propia para estilo editorial o estándares del equipo,
y, si el trabajo lo requiere, skills de documentos como PDF/DOCX/XLSX.

Capa 2: acceso

un conector de documentación viva tipo Context7,
una herramienta de búsqueda/extracción,
acceso seguro al repositorio,
y navegación o ejecución en entorno controlado.

Capa 3: sistema

una pieza de orquestación,
una de automatización,
una de memoria o persistencia,
y una capa mínima de evaluación / seguridad.

Eso ya te da mucho más valor que una colección infinita de enlaces guardados para “ya probaré”.

Cinco observaciones que me parecen más importantes que la lista en sí

1. El futuro no va de un agente, sino de composición

Cada vez veo menos sentido a pensar en “la herramienta ganadora” y más en composiciones concretas:

skill correcta,
contexto correcto,
permisos correctos,
entorno correcto.

La ventaja no suele estar en una pieza aislada, sino en cómo encajan.

2. Las skills se van a parecer al middleware del conocimiento

Muchas organizaciones todavía están metiendo criterio en prompts sueltos, notas internas o documentación dispersa.

Las skills apuntan a otra cosa: convertir una forma de trabajar en una interfaz reutilizable.

Eso me parece más importante de lo que parece.

3. MCP es probablemente el estándar más relevante que ha aparecido en este espacio

No porque sea perfecto, sino porque ordena algo que estaba muy roto: cómo conectar agentes con herramientas externas de una manera relativamente uniforme.

Si esto cuaja, veremos menos demos cerradas y más ecosistemas interoperables.

4. Las listas virales sobre IA envejecen rápido

Una lista así sirve para descubrir piezas, pero no para tomar decisiones finales.

En este espacio hay que mirar, como mínimo:

mantenimiento reciente,
calidad de la documentación,
modelo de permisos,
facilidad de integración,
señales de adopción real,
y coste operativo.

Más estrellas no siempre significa mejor herramienta para tu caso.

5. El stack bueno suele ser el más aburrido

Mi intuición es que los stacks que mejor van a funcionar no serán los más exóticos.

Serán los que combinen:

una capa de instrucciones reusable,
una capa de acceso bien limitada,
automatización sobria,
memoria útil,
y observabilidad suficiente.

Es decir: menos circo, más sistema.

Si sólo me quedara con una idea

La parte interesante del hilo de @zodchiii no es la promesa de “la única lista que necesitas”.

Es que deja ver con bastante claridad cómo se está estructurando el ecosistema:

skills para empaquetar criterio,
MCP para conectar con herramientas,
repos para construir sistemas agentic reales.

Y eso sí me parece una señal importante.

Porque cuando una tecnología empieza a generar capas reconocibles, patrones repetibles y piezas intercambiables, deja de ser sólo novedad.

Empieza a convertirse en infraestructura.

Y ahí es donde de verdad merece la pena prestar atención.