Las skills de agentes pasan a una biblioteca compartida en MCP. El hash prueba el archivo, no el consejo

¿Dónde debería vivir una skill?

Para la mayoría de los equipos empresariales, la respuesta honesta hoy es “en varios sitios”. Una skill, el paquete de instrucciones y archivos de referencia que enseña a un agente a hacer una tarea a la manera de la empresa, nace en la carpeta de un agente. Funciona. Otro equipo la copia. Seis meses después hay cinco versiones, cada una un poco distinta, y nadie sabe cuál usa el agente de siniestros.

Dos lanzamientos del 12 de octubre apuntan a otra organización.

Un estándar, una versión preliminar y una beta

Microsoft publicó una guía técnica sobre la Skills extension de MCP, identificada como io.modelcontextprotocol/skills. Su propuesta, SEP-2640, ha alcanzado el estado Final. La extensión permite que un servidor declare que ofrece skills, las liste con skills/list y publique un manifiesto de cada una: dirección, tamaño y resumen SHA-256 de cada archivo. El host, es decir, la aplicación que ejecuta el agente, lee las instrucciones y los archivos de apoyo solo cuando los necesita y compara cada uno con el manifiesto antes de usarlo.

Microsoft Foundry ofrece skills en versión preliminar. Los equipos suben una skill para crear una versión fija y luego la referencian desde un toolbox que expone herramientas y skills a través de un único endpoint MCP. Un toolbox puede fijar una versión de la skill o seguir la versión por defecto. La versión preliminar no tiene acuerdo de nivel de servicio y Microsoft no la recomienda para producción.

El mismo día, Databricks lanzó en beta una Skills API en Unity Gateway, con operaciones para crear, leer, actualizar, listar, eliminar y finalizar skills desde su CLI y sus SDK.

Lo que garantiza la extensión y lo que deja en sus manos

Lo más útil del texto de Microsoft es el cuidado con que separa lo que el protocolo comprueba de lo que no puede comprobar.

Quién responde a cada pregunta sobre una skill compartida

El servidor y el protocolo

• Qué skills existen
• Bytes exactos de cada archivo, por tamaño y resumen
• Qué versión se sirve
• De qué servidor viene

Integridad y procedencia

El host y la empresa

• Si el consejo es correcto
• Si puede cargarse
• Si pueden ejecutarse scripts
• Qué herramientas puede usar el agente

Confianza, aprobación y permisos

La especificación es estricta del lado del host. Debe saber qué servidor aportó cada skill, porque dos servidores pueden ofrecer skills con el mismo nombre y “no deben sustituirse en silencio”. Debe rechazar un archivo cuyo tamaño o resumen ya no coincida. La aprobación guardada queda ligada a las huellas de los archivos, de modo que si un manifiesto actualizado cambia, añade o elimina un archivo, “esa aprobación queda revocada y el host debe volver a preguntar”. Leer un script no da permiso para ejecutarlo; la ejecución en el host exige la aprobación explícita del usuario. Y si las instrucciones de una skill piden al agente que use otra herramienta, “esa petición no es un permiso para usarla”.

Después llega el límite, dicho con claridad: “Estas comprobaciones le dicen que el contenido coincide con lo que ofreció el servidor. No le dicen si el contenido es seguro ni si las instrucciones son buenas.”

Por qué una biblioteca compartida cambia el riesgo

Centralizar las skills resuelve la divergencia entre copias, y es una ganancia real. También concentra influencia. Una skill que enseña a un agente de compras a evaluar proveedores, servida desde una biblioteca a cuarenta agentes, se convierte en un procedimiento con cuarenta ejecutores. Si es errónea, o se edita sin avisar, el error se propaga a la velocidad de la siguiente actualización de caché.

Eso convierte la biblioteca de skills en un repositorio de documentos controlados, aunque nadie lo llame así:

• Autoría y revisión. ¿Quién puede publicar una nueva versión de una skill y quién debe aprobarla? Los procedimientos regulados ya tienen responsables; las skills que los codifican necesitan los mismos.
• Fijación según el riesgo. Los agentes que hacen trabajo con consecuencias deben fijar una versión revisada. Seguir “la versión por defecto” sirve para skills de bajo riesgo y es peligroso para todo aquello por lo que preguntaría un auditor.
• Contenido dinámico. Los servidores pueden marcar las skills generadas como dinámicas cuando no hay huellas estables. Los hosts pueden rechazarlas; para trabajo con consecuencias, deberían.
• Portabilidad. Las skills guardadas en el runtime de un proveedor forman parte del costo de cambio que describimos en la memoria y las habilidades del agente como el nuevo lock-in. Un estándar solo lo reduce si su propio repositorio sigue siendo la fuente y la biblioteca del proveedor, una réplica.

Compruebe el cliente antes de planificar

Las pruebas de Microsoft son una advertencia útil sobre la madurez. Su endpoint de Foundry negoció una revisión anterior del protocolo (2025-11-25), aceptó skills/list en ella y rechazó como no compatible una petición en la revisión más reciente. “Poder llamar a una herramienta MCP no basta para descubrir y cargar skills remotas.” Antes de diseñar sobre skills compartidas, revise la matriz de compatibilidad de la extensión para cada host en el que se ejecuten sus agentes.

MCP estandarizó cómo llegan los agentes a las herramientas sin gobernarlas, el hueco que describimos en MCP conecta, pero no gobierna. Las skills siguen el mismo camino. El protocolo ya entrega instrucciones con integridad. Decidir qué instrucciones merecen entregarse sigue siendo trabajo de la empresa.