Skills, plugins e MCP no Codex: diferenças e como usar

Entenda o papel de skills, plugins e servidores MCP no Codex, quando usar cada extensão e como avaliar permissões, manutenção e risco.

13 min de leitura Atualizado em 29/08/2026

Conforme o Codex entra na rotina, a equipe repete instruções: como publicar uma prévia, consultar uma fonte, revisar um documento ou testar um fluxo. Skills, plugins e MCP existem para transformar parte dessa repetição em capacidade reutilizável.

Eles não são sinônimos. Uma skill ensina um processo. Um servidor MCP conecta ferramentas e dados. Um plugin distribui uma combinação instalável de skills, conectores e, quando necessário, interface.

Em uma frase: skill define como trabalhar; MCP oferece com o que trabalhar; plugin empacota capacidades para instalar e compartilhar.

O que é uma skill

O guia oficial de skills define skill como um pacote de instruções, recursos e scripts opcionais para que ChatGPT ou Codex sigam um fluxo especializado de forma consistente.

Uma skill pode conter:

  • instruções principais em SKILL.md;
  • referências e modelos;
  • scripts auxiliares;
  • critérios de entrada e saída;
  • verificações e exemplos.

Exemplos para uma agência:

  • publicar artigo em preview sem indexar;
  • revisar uma landing page em desktop e mobile;
  • preparar proposta a partir de um modelo;
  • validar pacote antes de enviar a cliente;
  • converter dados em relatório padronizado.

Crie uma skill quando o processo se repete, tem começo e fim claros e pode ser testado.

O que é MCP

MCP, ou Model Context Protocol, é um protocolo para conectar o agente a ferramentas e fontes externas. A documentação oficial de MCP explica como configurar servidores que expõem capacidades ao Codex.

Um servidor pode oferecer ações como:

  • consultar uma base;
  • ler documentos autorizados;
  • abrir tickets;
  • acessar uma API interna;
  • listar projetos;
  • executar uma operação específica.

MCP não é automaticamente “acesso à empresa inteira”. O servidor define ferramentas, autenticação e escopo. A política da equipe determina quem pode instalar e usar.

O que é um plugin

O guia de plugins apresenta plugins como forma de distribuir capacidades reutilizáveis no diretório compartilhado por ChatGPT e Codex.

Um plugin pode combinar:

  • uma ou mais skills;
  • servidores MCP ou conectores;
  • metadados de instalação;
  • componentes opcionais de interface;
  • configuração e autenticação.

Se a equipe escreveu uma skill para o próprio repositório, talvez não precise de plugin. O plugin ganha valor quando outras pessoas precisam instalar e receber o pacote de forma organizada.

Tabela de decisão

Necessidade Escolha inicial
Ensinar um processo repetível Skill
Acessar ferramenta ou fonte externa MCP
Distribuir skills e integrações Plugin
Definir regra de um repositório AGENTS.md
Descrever objetivo atual Briefing

É comum usar mais de um. Uma skill de atendimento pode orientar o procedimento e chamar uma ferramenta MCP para consultar o CRM. Um plugin pode empacotar ambos.

Quando criar uma skill interna

Faça cinco perguntas:

  1. A tarefa ocorre com frequência?
  2. O processo já foi validado por pessoas?
  3. Existe entrada e saída definida?
  4. Há regras que precisam ser sempre lembradas?
  5. É possível conferir se a execução ficou correta?

Se o processo muda toda semana e ninguém concorda com a sequência, documentá-lo como skill apenas cristaliza confusão.

Comece com uma versão pequena:

skill/
├── SKILL.md
├── references/
│   └── checklist.md
└── scripts/
    └── validar.py

O SKILL.md deve dizer quando usar, quais dados precisa, passos, proibições e como verificar.

Como escolher um servidor MCP

Antes de instalar, avalie:

Origem

Quem mantém? O código ou a documentação podem ser auditados? Há histórico de atualização?

Ferramentas expostas

O servidor só lê ou também escreve, apaga e envia? Ações destrutivas precisam de controles mais fortes.

Autenticação

Onde ficam tokens? Eles têm escopo mínimo? Podem ser revogados sem afetar outros sistemas?

Dados

Que informação sai do sistema e chega ao agente? Há dados pessoais, financeiros ou de cliente?

Rede

O servidor acessa a internet ou apenas uma fonte interna? Quais domínios são permitidos?

Operação

Há logs, limites, timeout e comportamento claro de erro?

Uma integração útil e ampla demais pode aumentar mais risco do que produtividade.

Menor privilégio na prática

Em vez de fornecer uma chave administrativa do CRM, crie uma credencial que apenas consulte contatos necessários. Em vez de expor SQL livre, ofereça ferramentas específicas com parâmetros validados.

Prefira:

buscar_cliente_por_id(id)
listar_pedidos_abertos(data_inicio, data_fim)

em vez de:

executar_sql(query)

Ferramentas estreitas são mais fáceis de autorizar, testar e auditar.

Instalação não é aprovação eterna

Depois de instalar:

  • teste com conta e dados controlados;
  • confirme o que o agente consegue ver;
  • provoque erros esperados;
  • verifique ações que pedem aprovação;
  • confira logs;
  • registre responsável e finalidade;
  • defina data de revisão;
  • remova o que deixou de ser usado.

Como escrever uma skill confiável

Gatilho claro

Explique quando deve e quando não deve ser usada.

Entrada mínima

Liste informações obrigatórias. Se faltar cliente, arquivo ou aprovação, a skill deve parar ou seguir uma regra segura.

Passos observáveis

Cada etapa precisa produzir evidência: arquivo, teste, tabela, screenshot ou validação.

Limites

Registre proibições, ações que exigem confirmação e dados que não podem aparecer.

Saída

Defina formato, local e checklist final.

Uma skill não deve depender de memória informal do autor. Outra pessoa precisa conseguir entendê-la.

Plugins: instalar ou construir

Instale quando existe um plugin confiável que resolve a necessidade com permissões aceitáveis. Construa quando o processo é específico, a integração é interna ou a equipe precisa controlar manutenção e dados.

Antes de publicar para terceiros, remova credenciais, nomes de cliente, caminhos pessoais e documentação interna. Um pacote distribuído deve nascer com separação clara entre código público e configuração privada.

Erros comuns

  • criar skill para uma tarefa que ocorreu uma vez;
  • copiar instruções antigas sem validar;
  • instalar MCP porque “pode ser útil”;
  • conceder permissão administrativa por conveniência;
  • guardar token em arquivo versionado;
  • não testar ações de escrita;
  • misturar regra do projeto e workflow global;
  • manter plugins sem responsável;
  • assumir que uma integração importada continua autenticada.

Na migração de outro agente, use Como migrar do Claude Code para o Codex e revise cada integração depois da importação.

Arquitetura simples para uma agência

AGENTS.md
└── regras do projeto e comandos

skills/
├── publicar_preview
├── revisar_blog
└── validar_pacote

MCPs
├── Drive com pasta limitada
├── sistema de tarefas com escopo do time
└── API interna com ferramentas específicas

plugins
└── capacidades aprovadas para distribuição

O agente recebe só o necessário para a tarefa. Processos ficam reutilizáveis; acessos continuam separados.

Mantenha um inventário com:

  • nome e versão;
  • origem;
  • finalidade;
  • proprietário;
  • permissões;
  • dados acessados;
  • data do último teste;
  • usuários ou equipes;
  • plano de remoção.

Leia Segurança e governança no Codex para transformar esse inventário em política de adoção.

Checklist de aprovação

  • O problema exige skill, MCP ou plugin?
  • A origem é confiável?
  • Permissões são mínimas?
  • Credenciais podem ser revogadas?
  • Ações de escrita foram testadas?
  • Dados sensíveis estão protegidos?
  • Há logs e responsável?
  • Existe revisão periódica?
  • O recurso pode ser removido sem paralisar o processo?

Estender o Codex faz sentido quando reduz repetição sem esconder responsabilidade. A melhor integração não é a que faz mais; é a que faz exatamente o necessário com limites que a empresa consegue explicar.

Ciclo de vida de uma extensão

Descoberta

Registre o problema e verifique se uma capacidade existente já resolve. Evite duplicar skills com nomes diferentes.

Avaliação

Leia instruções, permissões, código disponível e política de dados. Monte um cenário de teste e critérios de rejeição.

Piloto

Use conta, projeto e dados controlados. Teste sucesso, erro, indisponibilidade e tentativa de ação não autorizada.

Aprovação

Documente versão, responsável, usuários, ambientes e limites. Uma aprovação deve ser rastreável.

Operação

Monitore falhas, alterações de permissão e valor entregue. Atualizações importantes merecem novo teste.

Remoção

Revogue credenciais, desinstale, remova configurações e confirme que não restaram jobs ou dados.

Teste de uma ferramenta MCP

Crie um roteiro com entradas conhecidas:

1. Consultar registro existente e comparar campos.
2. Consultar registro inexistente e esperar resposta controlada.
3. Tentar campo inválido e confirmar validação.
4. Simular timeout sem duplicar ação.
5. Tentar operação fora do escopo e confirmar bloqueio.
6. Verificar que logs não contêm credencial.

Para ação de escrita, execute em ambiente de teste e confira o sistema de destino. Não aceite apenas a resposta textual do agente.

Versionamento de skills

Trate uma skill como código operacional. Registre mudanças, teste exemplos e mantenha compatibilidade ou uma migração clara. Alterar um passo pode afetar vários projetos.

Uma revisão deve perguntar:

  • o gatilho mudou?
  • entradas antigas continuam válidas?
  • scripts usam dependências seguras?
  • caminhos ainda existem?
  • controles foram preservados?
  • a documentação acompanha a execução?

Como evitar dependência invisível

Toda rotina crítica precisa de uma alternativa: procedimento manual, exportação de dados e responsável capaz de operar sem o plugin. Integrações podem mudar, falhar ou ser descontinuadas.

O objetivo de um plugin é reduzir trabalho, não tornar a empresa incapaz de entender o próprio processo. Documente o fluxo fora da ferramenta e faça um teste periódico de recuperação.

Exemplo integrado: publicação de artigo

Uma agência quer produzir prévias com consistência.

O AGENTS.md do blog registra que produção não pode ser sobrescrita e informa comandos do projeto. A skill descreve pesquisa, escrita, SEO, geração de preview e QA. Um MCP pode consultar o catálogo do blog ou o sistema de tarefas com permissões limitadas. Um plugin pode empacotar a skill e o conector para instalar no workspace da equipe.

O briefing continua necessário para cada artigo: palavra-chave, público, fontes, título e data. Nenhuma extensão decide sozinha que o conteúdo pode ser publicado.

Esse exemplo mostra por que as camadas não competem. Cada uma resolve uma duração diferente:

  • briefing: esta tarefa;
  • AGENTS.md: este projeto;
  • skill: este processo;
  • MCP: esta conexão;
  • plugin: esta distribuição.

Avaliação de custo total

Além do preço da ferramenta, conte:

  • configuração inicial;
  • autenticação e aprovação;
  • treinamento da equipe;
  • testes e monitoramento;
  • atualizações;
  • suporte;
  • investigação de falhas;
  • troca futura de fornecedor.

Uma integração gratuita pode ser cara se exigir manutenção semanal. Uma skill simples em texto pode gerar alto retorno quando elimina explicações repetidas e erros previsíveis.

Critérios para publicar um plugin

Antes de distribuir, confirme que o pacote não contém credenciais, dados de cliente, caminhos pessoais, dependências não declaradas ou instruções internas. Escreva descrição, permissões, fluxo de autenticação, exemplos, limitações e canal de suporte.

Teste instalação limpa, atualização e desinstalação. Quem recebe o plugin precisa entender o que será acessado antes de autorizar. Transparência de capacidade e dados faz parte do produto, não é apenas documentação complementar.

Perguntas frequentes

O que é uma skill no Codex? +

É um pacote de instruções e recursos reutilizáveis para orientar tarefas especializadas, reduzindo a necessidade de repetir um processo inteiro em cada pedido.

O que é MCP? +

MCP é um protocolo para conectar o agente a ferramentas e fontes externas por servidores que expõem capacidades controladas.

Plugin e skill são a mesma coisa? +

Não. Uma skill descreve um procedimento reutilizável; um plugin pode empacotar skills, servidores MCP e componentes opcionais de interface ou integração.

Toda integração MCP é segura? +

Não. Avalie origem, código, autenticação, escopos, dados acessados, ações disponíveis e manutenção. Conceda apenas o mínimo necessário.

Quando criar uma skill interna? +

Quando existe um processo recorrente, documentado e testável que a equipe executa com frequência e precisa manter consistente.

Artigos Relacionados

Felipe Zanoni

Fundador da Agência Café Online. Implementa agentes de IA, automações e ferramentas digitais em operações reais de empresas brasileiras.

Falar com Felipe