Vercel abre la API de skills.sh con OIDC del proyecto: menos secretos y mejor descubrimiento para agentes
Vercel lanzó el 5 de junio de 2026 la API de skills.sh autenticada con el OIDC del proyecto. Lo importante para builders no es solo buscar skills: es poder descubrir, auditar y traer contexto reusable sin repartir otro token largo entre agentes, CI y herramientas.

Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Los agentes ya no fallan solo por no tener tools. También fallan por no saber qué skill existe, cuál está auditada, cuál sigue viva y cuál conviene instalar sin meter otra credencial permanente en el flujo. Ahí está el valor del anuncio de Vercel del 5 de junio de 2026: la API de skills.sh ya se puede consultar usando el OIDC token del proyecto.
La noticia útil no es “hay otra API”. La noticia útil es otra: descubrimiento de skills, metadatos y señales de seguridad ahora pueden entrar al runtime de tu agente sin repartir un secreto largo adicional.

Por qué esto sí importa
Vercel dice tres cosas que, juntas, cambian el flujo:
- la API arranca con más de 600,000 skills del ecosistema open source;
- el acceso usa un token OIDC corto, atado a equipo y proyecto;
- y el límite es 600 requests por minuto por equipo y proyecto.
Eso se parece menos a “busca algo en un directorio” y más a una pieza operativa para agentes que necesitan:
- buscar skills por tema;
- leer detalles finos de una skill;
- revisar auditoría o señales de confianza;
- decidir si vale la pena instalarla o referenciarla.
En otras palabras, el discovery deja de vivir solo en un navegador humano o en una CLI manual. Puede pasar a formar parte del propio loop del agente.
El cambió más valioso está en la autenticación
La línea importante del changelog no es el volumen del catálogo. Es que el token es short-lived, con rotación automática, y que no te exige crear otra credencial estática para el agente.
Ese detalle hace una diferencia grande en equipos reales:
- CI no necesita guardar otra API key de larga vida;
- un agente que corre dentro del proyecto puede consultar la API con el contexto correcto;
- y el borde de seguridad se vuelve más fácil de gobernar que un token pegado en un secreto genérico.
Para un builder pequeño esto ahorra fricción. Para un equipo con varios agentes, entornos y automatizaciones, ahorra una deuda fea: la proliferación de credenciales secundarias que nadie rota a tiempo.

La pregunta correcta no es “si hay skills”, sino “cómo las eliges”
Vercel ya venía empujando skills como contexto reusable, separado de tu árbol de dependencias. Esta API mueve la conversación un paso más:
- ya no solo instalas una skill;
- también puedes consultar el mercado de skills programáticamente.
Eso habilita flujos como estos:
- el agente detecta que le falta contexto sobre una librería o plataforma;
- consulta skills relacionadas;
- revisa metadata y auditoría;
- sugiere o ejecuta una instalación con más criterio.
Para búsquedas con intención fuerte, eso es bastante más interesante que otro “prompt pack”:
skills para agentesdescubrir skills mcpoidc para agentes vercelauditar skills antes de instalar
La gente que busca eso no quiere entretenimiento. Quiere bajar fricción al momento de darle contexto nuevo a un agente sin abrir otro agujero de seguridad.
Lo que todavía no resuelve
Hay que ser precisos: esta API no convierte cualquier skill en una buena idea. Sigue habiendo tres problemas humanos:
- una skill puede estar bien empaquetada pero mal pensada;
- puede describir un flujo ya obsoleto;
- o puede ser técnicamente correcta pero irrelevante para tu stack real.
Por eso me parece importante que el uso práctico no sea “deja que el agente instale cualquier cosa que encuentre”. El uso práctico es:
- discovery más rápido;
- verificación más razonable;
- y mejor filtro antes de sumar contexto.
La nota de Vercel sobre skills versus TanStack Intent también ayuda a aterrizar esa frontera: una cosa es una intención/flujo centrado en tu producto; otra es un paquete de conocimiento reusable que el agente puede traer desde fuera.
Cómo lo probaría yo
Si tu stack ya usa agentes con shell, MCP o CLI, probaría algo así durante una semana:
- limitaría la consulta a proyectos concretos;
- registraría qué búsquedas de skills sí terminan en instalación útil;
- separaría skills sugeridas de skills autoaplicadas;
- y revisaría cuáles de verdad reducen preguntas repetidas o contexto desperdiciado.
Ese enfoque conversa bien con la nota sobre skills compartidas en Linear, porque ambas apuntan a lo mismo desde lados distintos: el valor ya no está solo en el modelo, sino en cómo empaquetas y distribuyes conocimiento operativo. Si todavía estás armando la base antes de formalizar skills, empieza por Instala tu propio agente.
Mi lectura final es simple: Vercel no abrió solo una API de búsqueda; abrió una forma más gobernable de meter discovery de skills dentro del propio loop del agente. Para builders que ya sienten el costo de repetir contexto o repartir secretos de más, eso sí es una mejora real.