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

> Entenda como o Agent Plugins 1.0.0 empacota Skills e servidores MCP, quais agentes já são compatíveis e por que ele não é um plugin do Claude.

Source: https://agentify.ia.br/blog/agent-plugins-padrao-aberto/

**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](https://claude.com/plugins).

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](https://agent-plugins.org/) 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](https://code.visualstudio.com/), [Cursor](https://www.cursor.com/), [GitHub Copilot](https://github.com/features/copilot), [ChatGPT/Codex](https://openai.com/codex/) e [Kiro](https://kiro.dev/) 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](https://agent-plugins.org/specification), 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](https://agent-plugins.org/plugin-authors/manifest) é 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:

- O cliente recebe ou encontra o diretório do plugin.

- Ele valida `plugin.json` e a versão indicada em `$schema`.

- Se suporta Skills, examina os filhos imediatos de `skills/` em busca de `SKILL.md`.

- Se suporta MCP, valida os servidores declarados em `mcp.json`.

- 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](https://agent-plugins.org/compatible-clients) 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](/blog/ferramentas-tools-e-mcp-servers) explica a camada de execução em detalhes.

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

 Camada
 Responsabilidade
 Exemplo

 Skill
 Conhecimento e procedimento
 Checklist de revisão de segurança

 MCP
 Ferramentas e dados
 Consultar alertas no GitHub

 Agent Plugin
 Embalagem portável
 Distribuir a Skill e o servidor juntos

 Marketplace
 Descoberta e instalação
 Catálogo mantido por um fornecedor ou equipe

 Cliente
 Execução, permissões e interface
 Cursor, Codex ou Kiro

### 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](https://vercel.com/blog/introducing-agent-plugins) e a [AWS](https://aws.amazon.com/pt/blogs/opensource/aws-supports-agent-plugins-an-open-standard-for-portable-agent-extensions/) 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](https://support.claude.com/en/articles/13837440-use-plugins-in-claude), 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](https://code.claude.com/docs/en/plugins), 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.

 Dimensão
 Agent Plugins 1.0.0
 Plugins do Claude Code

 Objetivo
 Portabilidade entre clientes
 Extensibilidade do Claude Code

 Manifesto
 plugin.json obrigatório na raiz
 .claude-plugin/plugin.json opcional

 Núcleo
 Skills e MCP
 Skills, agentes, hooks, MCP, LSP e mais

 Distribuição
 Fora do escopo
 Marketplaces nativos

 Variáveis
 PLUGIN_ROOT e PLUGIN_DATA
 CLAUDE_PLUGIN_ROOT e CLAUDE_PLUGIN_DATA

 Compatibilidade declarada
 Clientes conformes ao padrão
 Ecossistema Claude e Agent SDK

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.

 Cliente
 Agent Skills
 MCP stdio
 Streamable HTTP
 SSE legado

 VS Code
 Sim
 Sim
 Sim
 Sim

 Cursor
 Sim
 Sim
 Sim
 Sim

 GitHub Copilot
 Sim
 Sim
 Sim
 Sim

 ChatGPT e Codex
 Sim
 Sim
 Sim
 Não listado

 Kiro
 Sim
 Sim
 Sim
 Sim

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](https://github.com/agentplugins/agent-plugins-spec).

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](https://code.claude.com/docs/en/discover-plugins) 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:

- Leia [o que são Skills](/blog/o-que-sao-skills-e-como-especializar-agentes) e crie um `SKILL.md` pequeno.

- Teste a Skill em pelo menos um cliente compatível.

- Adicione `plugin.json` na raiz seguindo o schema 1.0.0.

- Inclua `mcp.json` apenas se o workflow realmente precisar de ferramentas externas.

- Valide em dois clientes e documente diferenças de transporte, instalação e permissão.

- 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](https://skilldev.pro) reúne ferramentas e práticas para construir esse catálogo com qualidade profissional.

-->
