O Agent Plugins 1.0.0 tenta resolver um problema específico do ecossistema de agentes: um mesmo conjunto de capacidades pode precisar ser reorganizado ou adaptado para funcionar em clientes diferentes. A proposta é estabelecer um núcleo comum para empacotar essas capacidades, de forma que clientes compatíveis saibam onde encontrá-las e como interpretar a configuração básica.
Esse núcleo, porém, é deliberadamente limitado. O formato não cria um sistema universal de instalação, não define em quem confiar, não estabelece permissões nem determina como um plugin deve ser isolado durante a execução. Essas decisões continuam sob responsabilidade de cada produto que implementa a especificação.
Há também uma nuance importante na cronologia. O histórico oficial do repositório registra a publicação da especificação 1.0.0 em 24 de julho de 2026. Em 6 de agosto de 2026, uma nova alteração passou a descrever explicitamente o Agent Plugins como um “open standard”. Portanto, 6 de agosto funciona como um marco público dessa caracterização, mas não foi a primeira publicação da versão 1.0.0.
A documentação consultada em 7 de agosto apresenta o 1.0.0 como a versão publicada atual, enquanto o próprio texto normativo ainda traz o status Working Draft. Isso não impede que a versão seja usada como contrato de interoperabilidade: a especificação determina que identificadores de schemas já publicados não podem ser reaproveitados com conteúdo diferente, e mudanças nesses schemas exigem uma nova versão da especificação.
O que o Agent Plugins 1.0.0 realmente padroniza
A unidade básica é simples: um plugin é um diretório autocontido, com um arquivo plugin.json obrigatório na raiz. A versão 1 define somente dois tipos de componentes portáveis: Agent Skills e servidores MCP. Skills ficam em um diretório skills/; a configuração de MCP fica em mcp.json.
O plugin.json funciona como manifesto do pacote. Entre outras informações, identifica o schema da especificação e o nome do plugin. O formato usa um schema fechado: extensões específicas de um cliente não devem criar campos arbitrários no nível principal, mas podem viver dentro de um espaço de nomes próprio em extensions. Também é possível reservar um diretório de nível superior para esses recursos particulares.
Essa escolha cria uma separação útil entre o que pretende ser portátil e o que continua pertencendo a cada plataforma.
| Camada | O 1.0.0 padroniza? | Tratamento |
|---|---|---|
| Manifesto do plugin | Sim | plugin.json na raiz |
| Agent Skills | Sim | Descoberta em skills/, usando a especificação de Agent Skills |
| Configuração de servidores MCP | Sim | mcp.json com formato comum |
| Transportes MCP | Parcialmente | stdio, Streamable HTTP e SSE legado são descritos |
| Extensões específicas de um cliente | Apenas o isolamento | Namespace próprio; comportamento é definido pelo cliente |
| Instalação e marketplaces | Não | Responsabilidade do cliente |
| Permissões, confiança e sandbox | Não | Responsabilidade do cliente |
| Interface e experiência de uso | Não | Responsabilidade do cliente |
A padronização de MCP merece atenção porque o Agent Plugins não substitui o Model Context Protocol. O MCP continua definindo o protocolo e seu ciclo de vida; o Agent Plugins define como a configuração de um servidor MCP é empacotada dentro de um plugin portátil.
No 1.0.0, uma entrada MCP pode declarar stdio, streamable-http ou o transporte SSE legado. Um cliente com suporte a MCP precisa implementar pelo menos um entre stdio e Streamable HTTP, e não é obrigado a suportar todos os transportes. Isso já mostra um limite importante para a promessa de portabilidade: dois clientes podem ser compatíveis com Agent Plugins e, ainda assim, oferecer conjuntos diferentes de capacidades.
Portabilidade não significa execução idêntica em qualquer cliente
A especificação permite adoção incremental. Um cliente pode ser considerado compatível oferecendo apenas suporte a Skills, sem implementar servidores MCP. Componentes que ele não entende devem ser ignorados, sem necessariamente invalidar o restante do plugin. Falhas em um servidor MCP também não devem inutilizar componentes independentes que continuam válidos.
Em 7 de agosto de 2026, a página oficial de compatibilidade lista VS Code, Cursor, GitHub Copilot, ChatGPT & Codex e Kiro. Todos aparecem com suporte a Agent Skills, mas há diferença no conjunto de transportes MCP informado: ChatGPT & Codex, por exemplo, aparecem com stdio e Streamable HTTP, enquanto outros clientes listados também indicam suporte ao SSE legado. Essa relação é mutável e deve ser conferida antes de assumir compatibilidade em produção.
Assim, “empacotar uma vez” não equivale automaticamente a “ter exatamente o mesmo comportamento em qualquer ferramenta”. O ganho está em eliminar parte da adaptação estrutural: o cliente sabe procurar o manifesto, Skills e configuração MCP em locais previsíveis e pode reutilizar aquilo que suporta.
Recursos como comandos próprios, hooks, agentes personalizados, regras e servidores LSP continuam fora dos tipos de componentes portáveis do v1. A própria justificativa do projeto diz que esses formatos ainda são específicos demais de cada cliente para integrar o núcleo estável.
A fronteira de segurança é especialmente importante
O Agent Plugins 1.0.0 inclui algumas regras defensivas de empacotamento. Caminhos fornecidos pelo pacote devem permanecer dentro da raiz do plugin, e clientes precisam rejeitar determinadas tentativas de escapar desse limite. A configuração de um processo MCP local também separa o diretório do pacote de uma área persistente administrada pelo cliente, por meio de PLUGIN_ROOT e PLUGIN_DATA.
Isso, porém, não é um sandbox de execução. A própria especificação esclarece que suas regras de contenção de caminhos não restringem tudo o que um subprocesso executado pelo plugin pode acessar durante sua operação.
O projeto é igualmente explícito sobre o que permanece sem uma solução portátil no 1.0.0. O documento de considerações futuras registra que a versão não define:
- modelo de confiança, sistema de permissões ou requisitos de sandboxing;
- verificação criptográfica de origem e integridade dos plugins;
- mecanismo comum para armazenar, fornecer ou limitar segredos;
- políticas corporativas de allowlist, blocklist e aprovação;
- formato padronizado para eventos de auditoria;
- dependências entre plugins;
- ferramenta comum de teste ou validação de plugins.
Há limitações até dentro da configuração MCP. Credenciais não devem ser embutidas em campos como headers ou env, mas o 1.0.0 também não fornece um mecanismo portátil de referência a credenciais nem uma configuração universal de OAuth. Descoberta de autorização, interação com o usuário e armazenamento de credenciais ficam sob controle do cliente.
Essa distinção evita uma leitura perigosa do anúncio: um plugin que obedece ao formato não é, por isso, um plugin confiável ou seguro para executar. Conformidade de empacotamento e decisão de confiança são problemas diferentes.
Por que um padrão tão pequeno pode ser útil
O Agent Plugins tenta estabelecer um “piso” de interoperabilidade, não transformar todos os agentes em uma única plataforma. O site oficial parte da constatação de que clientes criaram formatos próprios mesmo quando carregam componentes semelhantes. O efeito para autores é duplicar estrutura e adaptação entre ferramentas.
A solução escolhida é manter o núcleo reduzido: diretórios previsíveis, manifesto versionado, Skills, configuração MCP, regras de carregamento, algumas garantias sobre caminhos e um mecanismo para isolar extensões particulares.
Isso também explica por que o padrão não tenta decidir como um marketplace deve funcionar ou qual janela de aprovação deve aparecer antes da execução. Se incorporasse essas decisões ao núcleo, teria de conciliar modelos de produto, segurança e distribuição bastante diferentes.
Para uma equipe que produz plugins, o benefício potencial é poder manter a parte comum uma única vez e adicionar extensões somente onde um cliente exige comportamento específico. Para quem implementa um cliente, existe um contrato mínimo de descoberta e validação em vez de depender de convenções particulares de cada fornecedor.
“Aberto e neutro” também diz respeito à governança
O projeto se apresenta oficialmente como um padrão aberto e neutro em relação a fornecedores. A documentação e o texto da especificação são desenvolvidos publicamente, e o charter estabelece que o projeto existe para favorecer portabilidade, competição e estabilidade entre plataformas.
A governança determina ainda que cargos são ocupados por indivíduos e que nenhum fornecedor pode controlar a maioria das posições de Core Maintainer. Na composição publicada em 7 de agosto, os integrantes do Technical Steering Committee têm afiliações com Amazon, Cursor, Microsoft, OpenAI e Vercel.
O texto da especificação e a documentação são licenciados por padrão sob CC BY 4.0, enquanto o código usa Apache 2.0, salvo decisões futuras previstas no charter.
Esse modelo reduz a associação do formato a um único produto, mas não garante, sozinho, adoção ampla ou compatibilidade completa. O resultado dependerá de quantos clientes implementarem o núcleo, quais componentes suportarem e quanto comportamento continuar preso às extensões específicas de cada plataforma.
O que verificar antes de adotar Agent Plugins
Para avaliar a portabilidade de um plugin real, a pergunta mais útil não é apenas “o cliente suporta Agent Plugins?”. É preciso conferir quais partes ele implementa.
Antes de depender do formato, faz sentido verificar:
- se o fluxo usa apenas Agent Skills ou também exige servidores MCP;
- quais transportes MCP estão disponíveis no cliente de destino;
- se existem hooks, comandos, agentes ou outras funções fora do núcleo portátil;
- como o cliente instala, atualiza e desinstala plugins;
- quais permissões, aprovações e mecanismos de isolamento ele aplica;
- como origem, integridade e credenciais são verificadas;
- quais controles administrativos existem no ambiente em que o plugin será executado.
O Agent Plugins 1.0.0 reduz uma camada real de fragmentação, mas não elimina as diferenças entre runtimes. Seu papel é mais preciso: definir como capacidades compartilháveis são empacotadas e descobertas, deixando deliberadamente segurança operacional, distribuição e experiência de execução para as plataformas que carregam o pacote.
Para acompanhar mudanças, a referência mais segura é a especificação oficial, o histórico versionado do repositório e a página de clientes compatíveis — especialmente enquanto o documento normativo permanece marcado como Working Draft.
