Detalles de Agent Plugins 1.0: El Estándar Portable para Habilidades y Servidores MCP entre Agentes de IA

Nombre: Saludo
Descripción: Saluda al usuario y ofrece ayuda.

Saluda brevemente al usuario y pregunta cómo puedes ayudarle.

### Paso 4: Agrega MCP solo cuando sea necesario

Si el complemento necesita herramientas, agrega:

```Plaintext
mcp.json

No es necesario que un complemento configure un MCP vacío solo para ser válido.

La ausencia de componentes opcionales no se considera un error.

Paso 5: Prueba en clientes compatibles

Prueba el núcleo portátil en cada cliente que planees soportar.

No asumas que "compatible con agentes" significa que cada componente y método de transporte ya está implementado.

Los clientes pueden adoptar componentes de forma incremental.

Un paquete más útil podría verse así:

reporting-plugin/
├── plugin.json
├── skills/
│   └── weekly-report/
│       └── SKILL.md
├── mcp.json
└── bin/
└── reporting-server

Manifiesto:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "reporting-plugin",
"version": "1.0.0",
"description": "Flujos de trabajo y herramientas portátiles para informes."
}

Configuración de MCP:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
"mcpServers": {
"reporting": {
"type": "stdio",
"command": "./bin/reporting-server",
"cwd": "${PLUGIN_ROOT}"
}
}
}

Un cliente compatible puede descubrir:

• La identidad del complemento.
• La habilidad de informe semanal.
• El servidor MCP de informes.

Sin necesidad de que el autor coloque estos componentes portátiles en estructuras completamente diferentes para cada cliente.

El aislamiento de errores hace que los complementos sean más resistentes

Una parte bien diseñada de la especificación es que muchos fallos de componentes son locales, no catastróficos.

Por ejemplo:

• Una habilidad no válida puede omitirse mientras otras habilidades continúan cargándose.
• Una entrada de servidor MCP no válida no necesariamente deshabilita todos los servidores.
• Una conexión MCP fallida no debería impedir la carga de habilidades independientes.
• Los clientes pueden ignorar tipos de componentes no compatibles.

Esto es crucial en un ecosistema real con múltiples clientes.

Un complemento puede ofrecer:

Habilidad A
Habilidad B
Servidor MCP A
Servidor MCP B
Extensión de cliente

Si un cliente no admite un método de transporte específico, el resto útil y portátil debería seguir funcionando cuando sea posible.

De lo contrario, la interoperabilidad se vuelve frágil: una función opcional no compatible deshabilitaría todo el complemento.

Los clientes compatibles pueden adoptar el estándar de forma incremental

Los clientes no necesitan implementar cada función de la v1.

Un cliente que solo admite habilidades aún puede cumplir con el estándar si carga correctamente el manifiesto e implementa los comportamientos de habilidades relevantes.

Un cliente compatible con MCP debe cumplir con las reglas de transporte aplicables.

Este modelo incremental reduce la barrera de adopción.

Los clientes más pequeños pueden comenzar con:

plugin.json
+
skills/

y agregar MCP más adelante.

Los clientes más grandes pueden implementar el núcleo portátil completo y sus propios espacios de nombres de extensiones.

El proyecto se gobierna por la comunidad, no por un solo proveedor

El titular de AIBase describe la introducción de complementos de agente por parte de OpenAI.

OpenAI es claramente un actor importante.

El documento oficial de gobernanza amplía el modelo de propiedad.

Los complementos de agente se presentan a sí mismos como

un proyecto gobernado por la comunidad y neutral respecto a proveedores.

Su comité técnico de dirección está compuesto por mantenedores principales independientes, no por asientos reservados para empresas.

El estatuto establece:

• Ningún proveedor individual puede controlar la mayoría de los asientos de mantenedores principales.
• Las propuestas técnicas y discusiones son públicas.
• La participación en el proyecto está abierta según reglas claras.
• Los materiales de especificación y documentación usan CC BY 4.0 por defecto.
• Los patrones, código y materiales de software usan Apache 2.0 por defecto.

La página del proyecto actualmente lista a los mantenedores principales iniciales que representan a:

• Amazon
• Cursor
• Microsoft
• OpenAI
• Vercel

Esta estructura multi-proveedor es importante porque los estándares de interoperabilidad tienen más credibilidad cuando los clientes competidores tienen una vía de participación.

El estándar ya tiene múltiples clientes compatibles

La página oficial de compatibilidad actualmente lista:

• VS Code
• Cursor
• GitHub Copilot
• ChatGPT con Codex
• Kiro

Esto es un punto de partida más sólido que un estándar respaldado solo por su creador original.

La matriz de soporte aún no es completamente uniforme.

Por ejemplo, varios clientes en la página actual soportan SSE tradicional, mientras que ChatGPT con Codex actualmente lista stdio y Streamable HTTP.

El resultado importante es que el formato de paquete ya cruza fronteras de proveedores.

Los autores de complementos ahora pueden apuntar a un núcleo compartido sin asumir que cada entorno de agente es un ecosistema completamente independiente.

Por qué esto es más importante a medida que los agentes se convierten en sistemas de larga duración

Cuando los agentes realizan trabajo real, el problema de la fragmentación de complementos es más evidente.

Un chatbot simple puede funcionar con una pequeña lista fija de herramientas.

Un agente serio podría necesitar:

• Procesos específicos de la empresa.
• Acceso a bases de datos.
• Automatización de navegador.
• Herramientas de despliegue.
• Comprobaciones de seguridad.
• Flujos de trabajo de documentación.
• Instrucciones de dominio reutilizables.
• Scripts especializados.
• Múltiples servicios MCP.

A medida que estos componentes se multiplican, la portabilidad se convierte en infraestructura.

Sin un mecanismo de empaquetado compartido, cada empresa corre el riesgo de mantener una matriz así:

capacidad × cliente de agente × versión × plataforma

Un formato de paquete portátil reduce una dimensión de esa matriz.

No elimina el trabajo específico del cliente.

Pero puede reducir la duplicación de esfuerzo necesaria para mantener consistente el núcleo reutilizable.

Complementos de agente, MCP y habilidades de agente resuelven problemas diferentes

Estos tres conceptos están relacionados, pero no deben confundirse.

Un modelo mental útil es:

Habilidades
= lo que el agente debería saber o cómo debería trabajar

MCP
= cómo el agente se conecta a capacidades externas

Complementos de agente
= cómo se empaquetan esas partes reutilizables para adaptarse a clientes compatibles

Por lo tanto, el complemento de agente es una capa que se sitúa sobre los estándares de componentes existentes, no un reemplazo de estos.

Qué no resuelven los complementos de agente

El alcance del estándar es deliberadamente reducido.

No resuelve todos los problemas de compatibilidad entre agentes.

No estandariza los modelos

El mismo complemento puede comportarse de manera diferente al cargarse con distintos modelos.

No unifica las interfaces de permisos

Un cliente puede pedir confirmación antes de ejecutar una acción, mientras que otro usa políticas a nivel de espacio de trabajo.

No unifica la autenticación

OAuth y el almacenamiento de credenciales siguen gestionados por el cliente.

No garantiza el soporte de todos los métodos de transporte MCP

Los clientes pueden implementar diferentes subconjuntos.

No unifica enlaces ni comandos en v1

Estos siguen siendo definidos por cada cliente.

No crea una tienda de aplicaciones unificada

La distribución sigue fuera del alcance de la especificación central.

No aísla en sandbox los procesos MCP

La inclusión de rutas de paquete no equivale a aislamiento en tiempo de ejecución.

No garantiza un comportamiento idéntico

Portabilidad significa que los clientes pueden descubrir y cargar componentes según un contrato compartido. No significa que cada runtime de agente razonará o llamará al componente exactamente de la misma manera.

Consideraciones de seguridad para autores de complementos

Los complementos portátiles pueden ampliar el alcance de distribución.

Esto también aumenta la importancia de configuraciones seguras por defecto.

No incrustes información confidencial

Evita almacenar credenciales en los siguientes lugares:

plugin.json
encabezado de mcp.json
valores de variables de entorno en mcp.json
archivos empaquetados

Utiliza autenticación gestionada por el cliente.

Mantén restringidas las rutas del paquete

No dependas de escapar del directorio raíz del plugin para acceder a archivos arbitrarios del host.

Trata los servidores MCP locales como código ejecutable

Los servidores stdio pueden iniciar procesos.

Los usuarios y administradores empresariales deben comprender qué están instalando.

Minimiza los permisos requeridos

Un plugin que solo necesite permisos de lectura no debería solicitar operaciones de escritura.

Documenta los servicios externos

Los servidores MCP remotos deben tener políticas claras de propiedad, privacidad y uso de datos.

Ten precaución con el control de versiones

Incluso si la estructura de directorios sigue siendo válida, los cambios en el comportamiento del servidor pueden constituir cambios disruptivos.

Qué deben hacer ahora los desarrolladores

Paso 1: Distingue las partes portables de las específicas del cliente

Determina qué partes de tu plugin actual son realmente reutilizables:

Habilidades
Servidores MCP
Metadatos compartidos

Migra los comportamientos exclusivos del cliente a los espacios de nombres de extensión correspondientes.

Paso 2: Añade el esquema con número de versión

Declara explícitamente Agent Plugins 1.0.0 en plugin.json.

Paso 3: Estandariza la ubicación de las habilidades

Coloca las habilidades de agente portables en:

skills//SKILL.md

Paso 4: Estandariza la configuración de MCP

Utiliza un archivo de nivel raíz:

mcp.json

en lugar de depender únicamente de archivos de configuración nativos del cliente.

Paso 5: Elimina los secretos portables

Migra las credenciales al sistema de autenticación de cada cliente.

Paso 6: Prueba el paquete en múltiples clientes

La interoperabilidad debe verificarse mediante demostraciones reales, no darse por sentada.

Paso 7: Realiza un seguimiento de las actualizaciones de la especificación

Dado que la especificación actual sigue marcada como borrador de trabajo, presta atención a los cambios en el repositorio del proyecto, debates, esquemas y páginas de compatibilidad.

Contenido confirmado y lo que requiere aclaración adicional

Preguntas frecuentes

¿Qué es Agent Plugins 1.0?

Agent Plugins 1.0 es un formato de paquete abierto y neutral respecto a proveedores para extensiones reutilizables de agentes de IA. Estandariza cómo se colocan las habilidades de agente y las configuraciones de servidores MCP en un directorio de plugin portable.

¿Es Agent Plugins un estándar exclusivo de OpenAI?

No. OpenAI participa en el proyecto y soporta el formato en ChatGPT y Codex, pero el proyecto oficial está gobernado por la comunidad y es neutral respecto a proveedores. Su equipo inicial de mantenedores principales incluye personas vinculadas a Amazon, Cursor, Microsoft, OpenAI y Vercel.

¿Qué archivos requiere un Agent Plugin?

Cada plugin requiere un plugin.json raíz. Las habilidades pueden almacenarse en skills/, mientras que los servidores MCP pueden describirse en el mcp.json raíz; las funciones específicas del cliente pueden utilizar extensiones de espacio de nombres.

¿Agent Plugins reemplaza a MCP?

No. MCP sigue definiendo el protocolo utilizado entre los clientes y los servidores MCP. Agent Plugins define una forma portable de empaquetar la configuración de servidores MCP junto con otros componentes de agente reutilizables.

¿Los hooks son parte de Agent Plugins 1.0?

No como componentes portables del núcleo. La versión 1 estandariza las Habilidades y los servidores MCP; los hooks pueden implementarse en lugares que los admitan mediante espacios de nombres de extensión específicos del cliente.

¿Qué clientes soportan Agent Plugins?

La página de compatibilidad oficial enumera actualmente VS Code, Cursor, GitHub Copilot, ChatGPT y Codex, y Kiro. Los transportes MCP que admiten son diferentes, por lo que los autores deben consultar la matriz en vivo.

¿Un Agent Plugin se comporta igual en cada cliente?

No. El estándar cubre el descubrimiento de paquetes y los componentes portables, pero no los modelos, interfaces de permisos, flujos de autenticación, mercados o comportamientos de ejecución específicos del cliente. Un plugin puede ser portable, pero no necesariamente produce el mismo comportamiento de ejecución.

¿Agent Plugins 1.0 se considera una versión final?

1.0.0 es la versión publicada actualmente y proporciona el esquema estándar. La página de la especificación actualmente marca el estado del proyecto como "borrador de trabajo", por lo que los desarrolladores deben continuar siguiendo los procesos públicos de gobernanza y control de versiones.

Herramientas relacionadas

• Agent Plugins: Sitio oficial de documentación para el empaquetado portable de Agent Plugins.
• Agent Skills: Especificación abierta para componentes de habilidades reutilizables en Agent Plugins.
• Model Context Protocol: Protocolo utilizado por clientes y servidores MCP empaquetados mediante mcp.json.
• Plugins de ChatGPT: Sistema de plugins actual de OpenAI para los flujos de trabajo de ChatGPT y Codex.
• Plugins de agente en VS Code: Documentación de Microsoft sobre cómo cargar Agent Plugins en VS Code.
• Plugins de GitHub Copilot: Documentación de GitHub sobre paquetes de plugins y soporte de la especificación de plugins abierta.

Enlaces relacionados

• Especificación de Agent Plugins 1.0.0: Restricciones normativas completas del formato portable actual.
• Cómo construir Agent Plugins: Tutorial oficial de plugins mínimos y guía de estructura del paquete.
• Clientes compatibles: Lista de clientes compatibles y transporte MCP.

org/compatible-clients): la matriz de soporte actual para VS Code, Cursor, GitHub Copilot, ChatGPT y Codex, y Kiro.

• Repositorio de especificación de complementos de agente: patrones públicos, gobernanza, problemas, discusiones y código fuente de la especificación.
• Gobernanza de complementos de agente: estatutos de gobernanza comunitaria y reglas de neutralidad del proveedor.
• Licencia de complementos de agente: términos de licencia para la especificación, documentación, patrones y código.
• Complementos de OpenAI en ChatGPT y Codex: instrucciones a nivel de producto de OpenAI sobre complementos, aplicaciones, habilidades y control del espacio de trabajo.

Resumen

Agent Plugins 1.0 resuelve un problema real en el creciente ecosistema de agentes: los desarrolladores empaquetan repetidamente las mismas habilidades e integraciones MCP de diferentes maneras para cada cliente.

La especificación define un núcleo pequeño y portátil: el plugin.json requerido, habilidades en el directorio skills/, configuración MCP en mcp.json, reglas de empaquetado, esquemas versionados y extensiones de cliente con espacio de nombres. La distribución, los mercados, los permisos, la autenticación y la interfaz de usuario permanecen bajo el control del cliente.

El proyecto ya enumera soporte para múltiples clientes de agente importantes, incluidos VS Code, Cursor, GitHub Copilot, ChatGPT y Codex, y Kiro. Esto lo convierte en algo más que un formato de complemento exclusivo de OpenAI, aunque OpenAI es uno de los mantenedores participantes.

La versión 1.0.0 es el contrato publicado actualmente, aunque la página de especificaciones aún lo marca como borrador de trabajo. Los desarrolladores pueden adoptarlo ahora, pero deben realizar un seguimiento de los procesos públicos de gobernanza y control de versiones.

El cambio principal es simple: en lugar de reescribir las mismas extensiones de agente para cada plataforma, los desarrolladores pueden tratar las habilidades y las integraciones MCP como componentes portátiles con una estructura de paquete unificada.