Agent Plugins 1.0: padrão aberto para Skills e MCP

TL;DR: Agent Plugins 1.0.0 é um padrão aberto para reunir Agent Skills e servidores MCP em um pacote portável. Ele padroniza a embalagem, não a instalação, as permissões nem os recursos exclusivos de cada agente — e não deve ser confundido com o sistema de plugins do Claude.

Uma Skill ensina o agente a seguir um processo. Um servidor MCP entrega ferramentas e dados externos. Até agora, porém, empacotar os dois para diferentes agentes ainda exigia adaptar pastas, manifestos e configurações para cada produto.

O Agent Plugins tenta resolver exatamente essa última milha. Sua versão 1.0.0, anunciada em 6 de agosto de 2026, define uma estrutura mínima que clientes como VS Code, Cursor, GitHub Copilot, ChatGPT/Codex e Kiro conseguem descobrir e carregar.

A ideia parece simples — e é de propósito. Pense no padrão como uma mala com divisórias identificadas. Uma divisória guarda Skills, outra guarda configurações MCP, e a etiqueta externa identifica o pacote. Cada companhia aérea ainda decide como despachar, inspecionar e entregar a mala. O formato organiza o conteúdo; não substitui o aeroporto inteiro.

O que é Agent Plugins?

Agent Plugins é um formato aberto e neutro para empacotar componentes reutilizáveis que estendem agentes de IA. A versão 1.0.0 define um diretório autocontido, um manifesto obrigatório e dois tipos de componentes portáveis: Agent Skills e servidores MCP.

O padrão não cria um novo formato de Skill e não altera o Model Context Protocol. Ele combina especificações que já existiam e determina onde cada componente deve ficar. Com isso, um cliente compatível não precisa adivinhar onde procurar.

Segundo a especificação oficial, o pacote mínimo tem apenas um manifesto:

meu-plugin/
└── plugin.json

Um pacote útil pode combinar conhecimento e ferramentas:

meu-plugin/
├── plugin.json
├── skills/
│   └── revisar-api/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
└── mcp.json

O SKILL.md explica ao agente como executar uma tarefa. O mcp.json descreve os servidores que disponibilizam ferramentas. O plugin.json identifica o conjunto e informa qual versão da especificação ele segue.

O manifesto mínimo

Todo Agent Plugin precisa de plugin.json na raiz. Na versão 1.0.0, os únicos campos obrigatórios são $schema e name:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "revisao-de-api"
}

O manifesto também pode declarar versão, descrição, autor, homepage, repositório, licença, palavras-chave e extensões específicas de clientes. O schema oficial do manifesto é fechado: campos portáveis novos não podem ser inventados livremente no topo.

Essa rigidez reduz ambiguidades. Um cliente sabe quais campos interpretar e consegue relatar configurações desconhecidas sem executar algo por acidente.

Como Agent Plugins funciona?

Um cliente compatível valida o manifesto, procura componentes em locais fixos e carrega apenas aquilo que suporta. A adoção é incremental: um cliente pode implementar Skills, MCP ou ambos e ainda ser compatível com a especificação.

O fluxo básico tem cinco etapas:

1. O cliente recebe ou encontra o diretório do plugin.
2. Ele valida plugin.json e a versão indicada em $schema.
3. Se suporta Skills, examina os filhos imediatos de skills/ em busca de SKILL.md.
4. Se suporta MCP, valida os servidores declarados em mcp.json.
5. Componentes não suportados ou extensões de outros clientes são ignorados.

Essa última regra é essencial. Agent Plugins não exige que todo agente implemente tudo. A lista de clientes compatíveis mostra, por componente, o que cada produto consegue carregar e quais transportes MCP aceita.

Skills são conhecimento; MCP é capacidade

Uma Skill contém instruções, referências, scripts e recursos que orientam o raciocínio e o processo do agente. Ela pode ensinar como revisar uma API, criar uma migração segura ou seguir o checklist de deploy de uma empresa.

Um servidor MCP oferece ações e acesso externo. Ele pode consultar um banco, abrir uma issue, ler métricas ou acionar um serviço. Se essa distinção ainda parece abstrata, o guia sobre ferramentas e servidores MCP explica a camada de execução em detalhes.

O plugin é o envelope que reúne esses componentes. Ele não substitui nenhum deles:

Quais transportes MCP são portáveis?

O mcp.json da versão 1.0.0 aceita servidores locais por stdio, servidores remotos por Streamable HTTP e o transporte HTTP+SSE legado. Um cliente que implementa MCP precisa suportar ao menos stdio ou Streamable HTTP, mas não é obrigado a aceitar todos.

Também não existe OAuth portável no formato atual. Autenticação, consentimento, armazenamento de credenciais e experiência de login continuam sob responsabilidade de cada cliente. Cabeçalhos e variáveis presentes no pacote são dados visíveis e não devem carregar segredos.

Portabilidade, portanto, não significa configuração idêntica em qualquer lugar. Significa que há um contrato comum para descoberta e validação.

O que o padrão não tenta padronizar?

Agent Plugins 1.0.0 não define marketplace, instalador, sistema de permissões, runtime ou interface. Também deixa agentes, hooks, comandos, regras e servidores LSP fora do núcleo portável.

Essa escolha evita transformar a primeira versão em uma união apressada de recursos parecidos apenas no nome. Um hook do Claude Code e um hook de outro cliente podem disparar em eventos diferentes, receber dados diferentes e executar sob políticas distintas. Chamar ambos de hooks/ não criaria interoperabilidade real.

Recursos específicos podem viver em namespaces de domínio reverso:

meu-plugin/
├── plugin.json
├── skills/
└── com.exemplo.cliente/
    └── hooks/

O cliente dono de com.exemplo.cliente interpreta essa pasta. Os demais a ignoram. Assim, uma extensão proprietária pode coexistir com o núcleo portável sem fingir que funciona em todos os lugares.

A Vercel e a AWS citam hooks e subagentes como possíveis candidatos para versões futuras. Isso é direção de evolução, não promessa da versão 1.0.0.

Agent Plugins é a mesma coisa que plugin do Claude?

Não. O padrão Agent Plugins e os plugins do Claude compartilham componentes subjacentes, mas usam contratos diferentes. O formato da Anthropic é mais amplo e específico de seus produtos; o novo padrão busca apenas a parte que já pode ser portátil entre vários clientes.

Há ainda duas experiências da Anthropic que merecem ser separadas.

Plugins no Claude, Chat e Cowork

No Claude para trabalho geral, um plugin agrupa Skills, connectors e subagentes para uma função ou equipe. Segundo a Central de Ajuda da Anthropic, as Skills funcionam no chat web, no Chat do Claude Desktop e no Cowork; hooks e subagentes executam apenas no Cowork.

Essa experiência é orientada a funções como marketing, vendas, finanças e jurídico. O catálogo, o upload de pacotes e os controles organizacionais fazem parte do produto Claude. Não há alegação oficial de que esses pacotes sigam Agent Plugins 1.0.0.

Plugins no Claude Code

No Claude Code, plugin é a camada nativa de empacotamento e distribuição. Um pacote pode incluir Skills, comandos, subagentes, hooks, MCP, servidores LSP, estilos de saída, temas, monitores, binários e configurações.

O layout também difere:

plugin-claude-code/
├── .claude-plugin/
│   └── plugin.json
├── skills/
├── agents/
├── hooks/
└── .mcp.json

No Agent Plugins aberto, plugin.json é obrigatório na raiz e a configuração MCP se chama mcp.json. No Claude Code, o manifesto fica em .claude-plugin/plugin.json, é opcional em vários cenários, e MCP usa .mcp.json ou configuração inline nativa.

Em 6 de agosto de 2026, Claude e Anthropic não aparecem na lista oficial de clientes compatíveis nem no comitê técnico inicial do Agent Plugins. Isso não prova oposição ou incompatibilidade futura. Significa apenas que você não deve prometer instalação direta no Claude sem um anúncio ou adaptador oficial.

Quais agentes já são compatíveis?

No lançamento, a documentação oficial lista VS Code, Cursor, GitHub Copilot, ChatGPT/Codex e Kiro. Todos declaram suporte a Agent Skills e a pelo menos dois transportes MCP; o suporte exato deve ser consultado novamente antes de instalar ou publicar um pacote.

Compatibilidade parcial é uma característica do padrão, não uma falha. Um pacote que depende apenas de uma Skill pode funcionar em mais ambientes do que outro que exige um transporte MCP específico.

Por que Agent Plugins importa?

O ganho principal é separar o investimento no conteúdo do plugin da escolha do cliente. Uma equipe pode manter a parte portável uma vez e limitar adaptações aos recursos realmente exclusivos de cada agente.

Para autores, isso reduz cópias divergentes do mesmo pacote. Para clientes, oferece uma estrutura pequena o suficiente para implementar sem adotar o produto de outro fornecedor. Para empresas, melhora a possibilidade de auditar o que é compartilhado e trocar de ferramenta sem reconstruir todo o conhecimento procedural.

A governança reforça essa intenção. O comitê técnico inicial reúne mantenedores ligados a AWS, Cursor, Microsoft, OpenAI e Vercel, e o desenvolvimento ocorre publicamente no repositório da especificação.

Existe, porém, uma ressalva importante: a especificação 1.0.0 ainda se identifica como Working Draft. O número parece estável, mas o status pede cautela. Antes de publicar um tutorial definitivo ou automatizar a distribuição em larga escala, confirme schemas, clientes e transportes na documentação atual.

Segurança: portátil não significa confiável

Um Agent Plugin pode incluir instruções e iniciar subprocessos MCP; por isso, precisa ser tratado como software executável. Padronizar pastas facilita inspeção, mas não transforma código desconhecido em código seguro.

A especificação exige que caminhos fornecidos pelo pacote permaneçam dentro da raiz resolvida do plugin, inclusive após resolver links simbólicos. Ela também separa estado persistente em PLUGIN_DATA e orienta que segredos não sejam embutidos em headers ou variáveis do pacote.

Essas medidas contêm referências de arquivo e definem responsabilidades. Elas não são um sandbox completo. O cliente ainda precisa controlar permissões, aprovações, credenciais e isolamento de processos.

Antes de instalar:

• leia plugin.json, mcp.json e cada SKILL.md;
• confira scripts e binários incluídos;
• verifique quais comandos e endpoints MCP serão usados;
• instale somente de uma origem confiável;
• aplique o menor conjunto possível de credenciais e permissões;
• fixe versões quando o canal de distribuição permitir.

O mesmo princípio vale para plugins nativos. A própria documentação do Claude Code alerta que plugins e marketplaces podem executar código com os privilégios do usuário.

Próximos passos

Comece pelo componente mais simples e adicione portabilidade somente onde ela gera valor. Se você tem apenas um procedimento reutilizável, crie uma Skill. Se precisa acessar um sistema externo, avalie MCP. Empacote os dois quando houver uma unidade real de distribuição.

Um caminho prático:

1. Leia o que são Skills e crie um SKILL.md pequeno.
2. Teste a Skill em pelo menos um cliente compatível.
3. Adicione plugin.json na raiz seguindo o schema 1.0.0.
4. Inclua mcp.json apenas se o workflow realmente precisar de ferramentas externas.
5. Valide em dois clientes e documente diferenças de transporte, instalação e permissão.
6. Mantenha recursos proprietários em uma extensão com namespace, sem chamá-los de portáveis.

Se você distribui conhecimento para vários agentes, a mudança conceitual é esta: Skill é o conteúdo, MCP é a capacidade, plugin é o pacote e marketplace é o canal. Separar essas camadas evita lock-in por acidente e deixa sua arquitetura muito mais fácil de explicar, testar e evoluir.

Se o próximo passo é transformar processos internos em Skills testáveis e distribuí-las com governança, a skilldev.pro reúne ferramentas e práticas para construir esse catálogo com qualidade profissional.