[MCP·Skill #3] MCP, Skill e subagentes: qual usar e quando?

Há cada vez mais formas de ampliar ferramentas de programação com IA: conectar ferramentas com MCP, registrar procedimentos com Skills e delegar tarefas a subagentes.

SeokWoo LeeEngenheiro de software iOS sêniorPublicado 14 de julho de 2026Atualizado 26 de agosto de 20264 min de leitura

Imagem de capa de [MCP·Skill #3] MCP, Skill e subagentes: qual usar e quando?

Há cada vez mais formas de ampliar ferramentas de programação com IA: conectar ferramentas com MCP, registrar procedimentos com Skills e delegar tarefas a subagentes.

O problema é que os três são descritos como formas de “ampliar as capacidades do modelo”, o que dificulta escolher qual usar.

Em uma frase: MCP é uma mão, Skill é um manual e um subagente é um colega.

Este artigo explica o que cada um amplia, quais critérios usar na escolha e como fica a arquitetura quando eles são combinados.

Vamos começar pelo resumo dos pontos principais.

MCP amplia o que o modelo consegue fazer (acesso a ferramentas e dados)
Skill amplia como o modelo sabe trabalhar (procedimentos e conhecimento de domínio)
O subagente amplia a força de trabalho (um agente de execução com contexto separado)
Eles não competem; são complementares. É natural que um subagente leia um Skill e use ferramentas MCP

O que cada um amplia

Primeiro, vamos compará-los em uma tabela e depois analisar cada um.

Categoria	MCP	Skill	Subagente
Alvo da extensão	Capacidade (ferramentas·dados)	Conhecimento (procedimentos·know-how)	Agente de execução
Forma	Processo de protocolo·servidor	Pasta Markdown	Sessão de contexto separada
Analogia	Mão	Manual	Colega

MCP é o canal que alcança sistemas externos ao modelo. Ele torna possíveis tarefas que o modelo não consegue executar fisicamente sozinho, como consultar um banco de dados, chamar uma API interna ou controlar um navegador. Sua característica principal é a existência de um servidor separado onde o código é executado.

Skill não fornece uma capacidade nova; ele ajuda o modelo a fazer bem algo que já consegue fazer. Ele armazena em arquivos conhecimentos sobre “como”, como formatos de notas de versão, checklists de revisão e regras de documentação interna. Na prática, é apenas Markdown.

Um subagente é outra instância do modelo com uma janela de contexto independente. Ele pode assumir tarefas como exploração e pesquisa sem poluir o histórico da conversa principal. Mesmo ao vasculhar muitos arquivos, apenas a conclusão volta para o contexto principal.

Três perguntas para escolher o que usar

Quando a escolha estiver confusa, faça estas três perguntas em ordem.

Primeiro: é algo que o modelo não consegue fazer fisicamente agora? Se o acesso for impossível, como ao consultar um banco de dados interno, a resposta é MCP. Por mais conhecimento que você forneça, uma mão inexistente não vai surgir.

Segundo: ele consegue fazer, mas você precisa explicar o método todas as vezes? Então é Skill. Todo prompt repetido é candidato a um Skill.

Terceiro: o volume de trabalho está poluindo o contexto? Se pesquisa e exploração transformam a conversa em uma mistura de informações, é hora de isolá-las em um subagente.

Em outras palavras: sem acesso, MCP; sem know-how, Skill; sem contexto (ou com contexto insuficiente), subagente.

Faça estas três perguntas em ordem e a escolha estará feita

Na prática, combine os três

Os três não são mutuamente exclusivos. Uma automação bem projetada geralmente tem esta forma.

Na automação de revisão de código, por exemplo, você define um subagente revisor (quem), faz com que ele siga o Skill de checklist de revisão da equipe (como) e deixe comentários em PRs por meio de um servidor MCP do GitHub (com qual capacidade).

Os papéis não se sobrepõem; eles pertencem a camadas diferentes. Cada um responde a uma de três perguntas: quem, como e com o quê.

O design da combinação começa dividindo as três camadas em um quadro branco

Duas escolhas erradas comuns

Quando os limites ficam claros, os antipadrões também aparecem.

Um erro é criar um servidor MCP para algo que um Skill resolveria. Por exemplo, aplicar convenções de mensagens de commit é um problema de conhecimento que termina com algumas linhas de Markdown; escrever um servidor para isso é exagero. Servidores também trazem custos de manutenção e de revisão de segurança.

O outro é processar tudo em uma única sessão principal. Se você explora uma base de código grande diretamente na sessão principal, despejos de arquivos preenchem o contexto e eliminam o espaço necessário para implementar. O padrão é delegar a exploração a um subagente e receber apenas a conclusão na sessão principal.

Resumo

Em resumo: sem capacidade, MCP; sem know-how, Skill; sem mão de obra, subagente.

Os artigos sobre MCP e Skill tratam cada tema em detalhes. Use o critério deste artigo para decidir primeiro a qual camada pertence a automação que você quer criar.