El Problema de Empaquetado que Nadie Hablaba
Construiste una skill brillante. Escribiste un script o un servidor MCP para acompañarla. Juntos hacen una cosa útil muy bien: consultan tu base de datos de reportes y convierten los resultados en el resumen semanal que tu equipo realmente lee.
Luego intentas enviarlo a un segundo cliente.
La skill está bien. El servidor MCP está bien. Pero el wrapper alrededor de ellos no: la estructura de directorios es diferente, el manifest quiere metadatos diferentes, la configuración de MCP usa una forma distinta e infiere transportes de manera diferente. Así que haces fork del paquete, mantienes dos copias de componentes que nunca fueron diferentes en primer lugar, y los ves divergir.
El problema central no son los componentes. Es el manifest.
Agent Skills ya da a los agentes instrucciones y recursos reutilizables. MCP ya conecta agentes a herramientas y servicios. Ambos son portátiles por sí solos. Lo que no era portátil es la caja en la que los pones – y esa caja es lo que cada cliente tuvo que inventar por sí mismo.
Los autores de plugins no deberían tener que elegir entre llegar a todos los clientes y usar lo que hace bueno a cada cliente. Deberían tener ambos: una estructura predecible para las partes que son genuinamente las mismas, y espacio para que cada cliente siga innovando en las partes que no lo son.
Por eso Google se une al proyecto Agent Plugins como core maintainer y comienza a integrar el formato en nuestros productos.
Qué es Realmente Agent Plugins
Un plugin es un directorio. Esa es toda la idea, y la moderación es el punto.
reports-plugin/
├── plugin.json
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json
└── com.example.client/
El manifest tiene dos líneas de sustancia:
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "reports-plugin"
}
Todo lo demás se encuentra en una ubicación fija. Las skills viven en skills/, un subdirectorio cada una, en el formato que la especificación Agent Skills ya define. Los servidores MCP se declaran en mcp.json, con un tipo explícito en cada entrada. Un cliente nunca tiene que adivinar el transporte a partir de la forma del objeto de configuración – funcionará en stdio, Streamable HTTP o legacy HTTP+SSE.
Nota lo que plugin.json no puede hacer. No puede reubicar componentes ni declararlos inline. No hay ruta de descubrimiento para configurar ni orden de precedencia que aprender. Si skills/ no está, el cliente carga lo que está y sigue adelante. Un servidor mcp.json que falla al iniciar no derriba las skills del plugin con él – el cliente salta esa entrada, sigue cargando y reporta la falla. Componentes independientes fallan independientemente.
Ese último directorio de dominio inverso es la válvula de escape. com.example.client/ es un namespace de extensión propiedad de un solo cliente, para hooks, agentes, comandos o cualquier otra cosa que ese cliente quiera agregar. Los clientes que no lo reconocen lo ignoran. El núcleo portátil se mantiene pequeño porque las partes no portátiles tienen un lugar legítimo a donde ir.
Dónde Encaja Agent Plugins (y Dónde No)
Antes de usar un plugin, pregúntate si necesitas uno. Si estás enviando un solo servidor MCP a un solo cliente, mcp.json por sí solo sigue siendo la respuesta más simple. Si tienes una sola skill, no necesitas un plugin. Agent Plugins vale la pena cuando tienes componentes que pertenecen juntos y necesitan viajar juntos.
Agent Plugins v1 es un formato de paquete y nada más. No define mecanismo de instalación, protocolo de distribución, modelo de permisos, requisitos de sandboxing, verificación de confianza o procedencia, ni experiencia de usuario. Esos se nombran abiertamente en las consideraciones futuras del proyecto, no se omiten silenciosamente.
Esta es la decisión correcta. Instalación, políticas, controles empresariales y UX de aprobación son bastante diferentes entre clientes como un IDE, un CLI y una plataforma empresarial gestionada. Cada aplicación agéntica tiene obligaciones genuinamente diferentes con sus usuarios.
Empaquetar es un trabajo. Descubrir y llevar un plugin al usuario es un trabajo diferente, y vale la pena ser preciso sobre qué capa hace qué.
Por ejemplo, un catálogo podría registrar application/agent-plugins+json como un tipo conocido, para que una entrada de catálogo pueda apuntar a un plugin.json de la misma manera que una entrada existente apunta a un agent card o mcp.json. Cada capa es independientemente útil y adoptable. Puedes publicar un plugin sin entrada de catálogo, catalogar un recurso que no es un plugin y ejecutar skills sin plugin alguno. Adoptar uno nunca te obliga al siguiente.
Limitaciones y Precauciones
- Sin mecanismo de distribución: Aún necesitas alojar y compartir el directorio del plugin.
- Sin modelo de seguridad: Los plugins pueden incluir código arbitrario; debes confiar en la fuente.
- Soporte del cliente aún emergente: No todos los clientes soportan la spec todavía, así que prueba antes de confiar.
- Casos de uso simples pueden no necesitarlo: Una skill o servidor MCP único se puede compartir directamente sin el wrapper de plugin.
Adopción de Google y Qué Sigue
Dos productos de Google soportan el formato a partir de hoy.
Agents CLI empaqueta las skills expertas de Google para construcción, evaluación, deploy, observabilidad y publicación de agentes, convirtiendo cualquier agente de codificación de IA – Antigravity, Gemini CLI, Claude Code o Cursor – en un experto en construcción y operación de agentes. Esas skills ya eran distribuibles. Ahora son distribuibles en un formato que no es solo nuestro.
Data Agent Kit proporciona una colección de plugins que traen el poder de Google Data Cloud directamente a tu agente de codificación de IA o IDE preferido. Diseñado para ingenieros de datos y desarrolladores, permite que los agentes gestionen activos de datos, ejecuten consultas y hagan deploy de pipelines de datos. Al adoptar el estándar Agent Plugins, el Data Agent Kit asegura que su rico conjunto de skills agénticas y servidores MCP – conectándose a BigQuery, Spanner, Cloud SQL y más – esté disponible de forma portátil en cualquier cliente compatible.
Esperamos llevar soporte de Agent Plugins a más de nuestros productos que ya trabajan con Skills y servidores MCP.
Pruébalo Tú Mismo
Crea un directorio con un plugin.json con un nombre, escribe una instrucción rápida "hello world" en skills/greet/SKILL.md. Eso es un plugin válido, y toma alrededor de un minuto.
Reflexiones Finales
Empaquetar es infraestructura sin glamour, y la infraestructura sin glamour es exactamente el tipo de cosa que debería compartirse en lugar de reinventarse cinco veces. Agent Plugins es deliberadamente pequeño en alcance, hace una cosa bien, y es abierto e interoperable; por eso Google lo apoya.
Mientras exploras este nuevo estándar, también puede ser útil entender cómo se están resolviendo otros desafíos de infraestructura, como construir un exchange soberano de huella de carbono multi-tenant en Catena-X con AWS. Y si te interesa cómo cambios aparentemente pequeños de UI pueden tener un impacto masivo, revisa este deep dive en el rediseño del Turnstile de Cloudflare.