Agent Plugins: o padrão que empacota skills e MCP para agentes serem portáveis

Quem já tentou distribuir um agente para mais de um cliente conhece a dor: a skill funciona, o servidor MCP funciona, mas o "pacote" ao redor deles não. Cada cliente inventou seu próprio layout de diretório, seu manifesto com metadados diferentes e sua forma de configurar transporte MCP. O resultado, como descreve o post do Google Developers Blog, é o clássico fork: você mantém duas cópias de componentes que nunca foram diferentes e assiste elas divergirem.

O Agent Plugins 1.0.0 ataca exatamente esse ponto. É uma especificação aberta e vendor-neutral, publicada por um comitê técnico com mantenedores de Amazon, Cursor, Microsoft, OpenAI e Vercel, ao qual o Google agora se junta como Core Maintainer (representado por Kevin Hou). A frase que resume a filosofia do projeto é honesta: "o problema não são os componentes, é o manifesto".

Um plugin é só um diretório

A ideia central, e a contenção é proposital, é que um plugin é um diretório com locais fixos. A estrutura é previsível:

reports-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/

O manifesto tem literalmente duas linhas de substância:

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

Todo o resto vive em local fixo. Skills ficam em skills/, uma por subdiretório, no formato que a spec de Agent Skills já define. Servidores MCP são declarados em mcp.json, com um type explícito em cada entrada, o que elimina a adivinhação de transporte: funciona em stdio, Streamable HTTP ou o legado HTTP+SSE.

O detalhe arquitetural mais interessante é o que o plugin.json não pode fazer. Ele não realoca componentes nem os declara inline. Não há caminho de descoberta para configurar nem ordem de precedência para aprender. Se skills/ não existe, o cliente carrega o que existe e segue em frente. E um servidor de mcp.json que falha ao iniciar não derruba as skills do plugin: o cliente pula aquela entrada, continua carregando e reporta a falha. Componentes independentes falham de forma independente, o que é uma decisão de resiliência que vale copiar em qualquer arquitetura de agentes.

O último diretório, com nome de domínio reverso (com.example.client/), é a válvula de escape: um namespace de extensão de propriedade de um único cliente, para hooks, agents, commands ou o que ele quiser. Clientes que não reconhecem, ignoram. O núcleo portável fica pequeno porque as partes não portáveis têm onde morar.

O que a spec deliberadamente deixa de fora

Aqui está o ponto que separa hype de engenharia madura. O Agent Plugins v1 é um formato de pacote e nada mais. Não define mecanismo de instalação, protocolo de distribuição, modelo de permissão, sandboxing, verificação de proveniência nem experiência de usuário. E isso está listado abertamente nas future considerations do projeto, não escondido.

É a decisão certa. Instalação, política, controles corporativos e UX↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX → de aprovação são genuinamente diferentes entre um IDE, uma CLI e uma plataforma enterprise gerenciada. Empurrar tudo isso para dentro do formato de pacote só criaria mais uma spec que ninguém adota inteira.

Onde o plugin se encaixa no ecossistema

O post separa bem as camadas, e vale a pena reter esse modelo mental:

• Encontrar: Agentic Resource Discovery (ARD), protocolo aberto que responde "o que existe para esta tarefa?" e já trata plugin como tipo de recurso de primeira classe.
• Descrever: AI Catalog, o formato de entrada que o ARD indexa.
• Empacotar: Agent Plugins, o diretório portável.
• Executar: MCP e Agent Skills, os contratos que já eram portáveis.

Cada camada é adotável de forma independente. Dá para publicar um plugin sem entrada de catálogo, catalogar algo que não é plugin, e rodar skills sem plugin nenhum.

Quando não usar

O próprio Google avisa: nem toda skill deveria virar plugin. Se você está entregando um único servidor MCP para um único cliente, mcp.json sozinho continua sendo a resposta mais simples. Se tem uma skill só, também não precisa. O formato ganha sentido quando há componentes que pertencem juntos e precisam viajar juntos.

Já rodando hoje

Dois produtos Google já suportam o formato: o Agents CLI, que empacota skills de construção, avaliação, deploy e observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → de agentes para clientes como Antigravity, Gemini CLI, Claude Code e Cursor; e o Data Agent Kit, que traz MCP servers conectados a BigQuery, Spanner e Cloud SQL↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data → de forma portável.

Para quem constrói agentes no Brasil, o recado prático é direto: pare de forkar wrapper. Criar um diretório, um plugin.json com name e um skills/greet/SKILL.md de "hello world" já é um plugin válido, e leva cerca de um minuto. Como resume o post, empacotamento é "infraestrutura sem glamour", e é exatamente esse tipo de coisa que deveria ser compartilhada em vez de reinventada cinco vezes.

Fonte: Google Developers Blog