O Problema de Empacotamento Que Ninguém Falava

Você criou uma skill brilhante. Escreveu um script ou um servidor MCP para acompanhá-la. Juntos, eles fazem uma coisa útil muito bem – consultam seu banco de dados de relatórios e transformam os resultados no resumo semanal que seu time realmente lê.

Então você tenta enviar isso para um segundo cliente.

A skill está ok. O servidor MCP está ok. Mas o wrapper ao redor deles não está: a estrutura de diretórios é diferente, o manifest quer metadados diferentes, a configuração do MCP usa uma forma diferente e infere transportes de maneira distinta. Então você faz um fork do pacote, mantém duas cópias de componentes que nunca foram diferentes em primeiro lugar, e vê eles divergirem.

O problema central não são os componentes. É o manifest.

Agent Skills já dá aos agentes instruções e recursos reutilizáveis. MCP já conecta agentes a ferramentas e serviços. Ambos são portáveis por si só. O que não era portátil é a caixa em que você os coloca – e essa caixa é o que cada cliente teve que inventar para si.

Autores de plugins não deveriam ter que escolher entre alcançar todos os clientes e usar o que torna cada cliente bom. Eles deveriam ter ambos: uma estrutura previsível para as partes que são genuinamente as mesmas, e espaço para cada cliente continuar inovando nas partes que não são.

É por isso que o Google está se juntando ao projeto Agent Plugins como core maintainer e começando a integrar o formato em nossos produtos.

Abstract illustration of AI agent connecting to multiple tools via plugin manifest Dev Environment Setup

O Que Agent Plugins Realmente É

Um plugin é um diretório. Essa é a ideia toda, e a moderação é o ponto.

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

O manifest tem duas linhas de substância:

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

Todo o resto é encontrado em um local fixo. Skills ficam em skills/, um subdiretório cada, no formato que a especificação Agent Skills já define. Servidores MCP são declarados em mcp.json, com um tipo explícito em cada entrada. Um cliente nunca precisa adivinhar o transporte a partir da forma do objeto de configuração – funcionará em stdio, Streamable HTTP ou legacy HTTP+SSE.

Note o que plugin.json não pode fazer. Ele não pode realocar componentes, nem declará-los inline. Não há caminho de descoberta para configurar nem ordem de precedência para aprender. Se skills/ não estiver lá, o cliente carrega o que está lá e segue em frente. Um servidor mcp.json que falha ao iniciar não derruba as skills do plugin com ele – o cliente pula a entrada, continua carregando e reporta a falha. Componentes independentes falham independentemente.

Aquele último diretório com domínio reverso é a válvula de escape. com.example.client/ é um namespace de extensão pertencente inteiramente a um cliente, para hooks, agentes, comandos ou qualquer outra coisa que esse cliente queira adicionar. Clientes que não o reconhecem o ignoram. O núcleo portátil permanece pequeno porque as partes não portáteis têm um lugar legítimo para ir.

Developer hands typing on laptop with terminal showing plugin.json and MCP configuration System Abstract Visual

Onde Agent Plugins Se Encaita (e Onde Não Se Encaita)

Antes de partir para um plugin, pergunte-se se você precisa de um. Se você está enviando um único servidor MCP para um único cliente, mcp.json sozinho ainda é a resposta mais simples. Se você tem uma única skill, não precisa de um plugin. Agent Plugins vale a pena quando você tem componentes que pertencem juntos e precisam viajar juntos.

Agent Plugins v1 é um formato de pacote e nada mais. Ele não define mecanismo de instalação, protocolo de distribuição, modelo de permissão, requisitos de sandboxing, verificação de confiança ou proveniência, nem experiência do usuário. Esses são nomeados abertamente nas considerações futuras do projeto, não omitidos silenciosamente.

Essa é a decisão certa. Instalação, políticas, controles empresariais e UX de aprovação são bem diferentes entre clientes como um IDE, um CLI e uma plataforma empresarial gerenciada. Cada aplicação agêntica tem obrigações genuinamente diferentes com seus usuários.

Empacotamento é um trabalho. Descobrir e levar um plugin ao usuário é um trabalho diferente, e vale a pena ser preciso sobre qual camada faz o quê.

Por exemplo, um catálogo poderia registrar application/agent-plugins+json como um tipo conhecido, para que uma entrada de catálogo possa apontar para um plugin.json da mesma forma que uma entrada existente aponta para um agent card ou mcp.json. Cada camada é independentemente útil e adotável. Você pode publicar um plugin sem entrada de catálogo, catalogar um recurso que não é um plugin e executar skills sem plugin algum. Adotar um nunca obriga você ao próximo.

Limitações e Cuidados

  • Sem mecanismo de distribuição: Você ainda precisa hospedar e compartilhar o diretório do plugin.
  • Sem modelo de segurança: Plugins podem incluir código arbitrário; você precisa confiar na fonte.
  • Suporte do cliente ainda emergente: Nem todos os clientes suportam a spec ainda, então teste antes de confiar.
  • Casos de uso simples podem não precisar: Uma skill ou servidor MCP único pode ser compartilhado diretamente sem o wrapper de plugin.

Visual representation of portable plugin directory structure with skills and mcp files Technical Structure Concept

Adoção do Google e o Que Vem a Seguir

Dois produtos do Google suportam o formato a partir de hoje.

Agents CLI empacota as skills especialistas do Google para construção, avaliação, deploy, observabilidade e publicação de agentes, transformando qualquer agente de codificação de IA – Antigravity, Gemini CLI, Claude Code ou Cursor – em um especialista em construção e operação de agentes. Essas skills já eram distribuíveis. Agora são distribuíveis em um formato que não é só nosso.

Data Agent Kit fornece uma coleção de plugins que trazem o poder do Google Data Cloud diretamente para seu agente de codificação de IA ou IDE preferido. Projetado para engenheiros de dados e desenvolvedores, permite que agentes gerenciem ativos de dados, executem consultas e façam deploy de pipelines de dados. Ao adotar o padrão Agent Plugins, o Data Agent Kit garante que seu rico conjunto de skills agênticas e servidores MCP – conectando-se a BigQuery, Spanner, Cloud SQL e mais – esteja disponível de forma portátil em qualquer cliente compatível.

Esperamos trazer suporte a Agent Plugins para mais de nossos produtos que já funcionam com Skills e servidores MCP.

Teste Você Mesmo

Crie um diretório com um plugin.json com um nome, escreva uma instrução rápida "hello world" para skills/greet/SKILL.md. Isso é um plugin válido, e leva cerca de um minuto.

Considerações Finais

Empacotamento é infraestrutura sem glamour, e infraestrutura sem glamour é exatamente o tipo de coisa que deveria ser compartilhada em vez de reinventada cinco vezes. Agent Plugins é deliberadamente pequeno em escopo, faz uma coisa bem, e é aberto e interoperável; é por isso que o Google está apoiando.

Ao explorar esse novo padrão, você pode também achar útil entender como outros desafios de infraestrutura estão sendo resolvidos, como construir um exchange soberano de pegada de carbono multi-tenant na Catena-X com AWS. E se você se interessa em como mudanças aparentemente pequenas de UI podem ter impacto massivo, confira este deep dive no redesign do Turnstile da Cloudflare.

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.