MCP, Skills, Tools e Subagents: o que muda e como a stack de agentes de IA evolui em 2026

Conclusão primeiro: Tools, MCP, Skills e Subagents não são quatro nomes de produto intercambiáveis — são quatro camadas distintas na pilha de agentes de 2026. Tools são os contratos invocáveis que o modelo vê (nome + JSON Schema). MCP é o protocolo de descoberta e invocação entre um Host e processos de ferramentas externos. Skills são playbooks procedimentais sob demanda (como fazer o trabalho). Subagents são agentes delegados com contexto próprio. Colapsá-los numa única palavra da moda significa depurar a camada errada.

Escrito em 11 de setembro de 2026. Já cobrimos o que é MCP, o fluxo de dados JSON do Agent e JSON Schema como contrato. Este texto só responde: o que cada camada controla, como se empilham e para onde a pilha de 2026 está convergindo.

Quatro camadas em um relance

Quando alguém diz «adicionar uma ferramenta ao agente», muitas vezes quer dizer quatro coisas diferentes. Encaixe a frase nesta tabela:

Em uma frase: Tools são «o que pode ser chamado»; MCP é «de onde vêm as ferramentas»; Skills são «como este trabalho é feito»; Subagents são «quem faz, em qual contexto». JSON Schema atravessa Tools e MCP; Skills e Subagents governam sobretudo prompts, política e limites de sessão.

Tools: o contrato de chamada diante do modelo

Um Tool (ou Function) é a menor unidade invocável que o modelo vê. Os nomes dos fornecedores diferem — OpenAI Tools / Function Calling, Anthropic Tool Use, Gemini Function Declarations — mas o formato é o mesmo: você declara ferramentas; o modelo devolve tool_calls estruturados; o Host executa e grava os resultados de volta no chat.

Uma definição de ferramenta costuma ficar assim:

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

O que de fato restringe o comportamento é JSON Schema: nomes de campos, tipos, required, additionalProperties. Modelos podem mudar; o Schema não deveria derivar com eles. Veja por que Tool Calling depende de JSON Schema para a disciplina de validação. Aqui o ponto é simples: um blurb de ferramenta em linguagem natural sem Schema já não é contrato de produção em 2026.

O limite da camada Tools é nítido: ela não decide se a implementação roda no mesmo processo ou remotamente, e não decide como o trabalho de vários passos é dividido. Isso pertence a MCP e a Skills / Subagents.

MCP: o soquete de ferramentas entre processos

MCP (Model Context Protocol) responde como ferramentas e contexto são descobertos e invocados fora do processo Host. As mensagens são JSON-RPC 2.0; métodos comuns incluem tools/list, tools/call, além de Resources / Prompts. Um MCP Client dentro do Host (Cursor, VS Code, Claude Desktop, …) conecta-se a um MCP Server e traduz as ferramentas expostas no array Tools que o modelo entende.

A pilha correta é:

1. O MCP Server descreve cada tool com inputSchema (ainda JSON Schema);
2. O Host chama tools/list e mapeia o resultado para declarações Tool do modelo;
3. O modelo emite tool_calls;
4. O Host emite tools/call ao Server e grava result de volta no diálogo.

Chamar MCP de «outro Function Calling» é o equívoco mais comum de 2025–2026. Function Calling fica no limite da API do modelo; MCP fica no limite Host ↔ Server. A especificação atual é 2026-07-28: sem handshake de sessão; as requisições carregam _meta. Detalhes: guia MCP e guia de migração.

Quando você não precisa de MCP: um processo só, ferramentas embutidas no Host, sem reutilização entre apps — Tool Calling sozinho basta. Quando precisa: reutilizar o mesmo Server entre IDEs / desktops, isolamento de processo, descoberta dinâmica de ferramentas.

Skills: playbooks reutilizáveis de como fazer

Um Skill não é outra ferramenta — é conhecimento procedimental que o agente pode carregar sob demanda: quando ativar, quais passos seguir, o que checar, quais ferramentas podem ser usadas. Na forma de engenharia costuma ser um SKILL.md do repositório (ou pacote de regras equivalente): título, condições de disparo, checklist, proibições, caminhos de scripts relacionados.

Em relação a Tools / MCP:

Em 2026, agentes de IDE tratam Skills como cidadãos de primeira classe: tarefas curtas usam capacidades embutidas; fluxos longos, normas de equipe e playbooks de ops vivem em Skills para você não colar o manual inteiro no system prompt toda vez. Um Skill pode dirigir quais Tools chamar e impor gates como «validar JSON antes de enviar» — mas normalmente não é um método JSON-RPC.

Uma confusão comum: um script shell empacotado rotulado ao mesmo tempo como Skill e Tool. Regra prática — se o modelo chama uma vez via Schema e recebe resultado estruturado, é Tool; se um documento diz ao agente «siga estes cinco passos, chame ferramentas quando precisar», é Skill.

Subagents: delegação com contexto isolado

Um Subagent é uma sessão filha para a qual o pai delega: em geral tem sua própria janela de contexto, um system prompt mais estreito, uma allowlist de ferramentas mais restrita e um resumo devolvido ao pai. Não adiciona «mais uma função»; combate poluição de contexto e permite exploração em paralelo.

Usos típicos:

• Recuperação isolada — o filho vasculha o repositório ou os logs; o pai guarda só a conclusão.
• Trabalho em paralelo — mudanças de frontend, testes e tradução de textos rodam sem disputar um único contexto.
• Papéis estreitos — revisão de segurança, exploração de código, diagnóstico de CI, cada um com seu prompt e ferramentas.

Na prática, um Subagent costuma ser exposto ao pai como um Tool especial (p. ex. Task / spawn_agent): os argumentos são a descrição e o tipo da tarefa; o retorno é a resposta final do filho. Isso não significa Subagent = Tool. O Tool é a superfície de chamada; o Subagent é outro loop de raciocínio com estado.

Em relação a Skills: um Skill diz «como»; um Subagent decide «abrir outra sessão para fazer». Um Skill pode exigir «triagem complexa deve lançar o Subagent de CI»; esse Subagent então carrega seus próprios Skills e Tools.

Como as quatro camadas se empilham

Uma tarefa real muitas vezes usa as quatro. Exemplo: «escrever um post do blog e fazer o deploy» (ilustrativo, não o protocolo privado deste site):

1. O pai carrega um Skill — «checklist de publicação do blog»: corpo, locales, sitemap, IndexNow.
2. O pai chama um Subagent para explorar templates históricos de artigos, para que dezenas de HTMLs não entrem no contexto principal.
3. A sessão principal edita o frontend via Tools (ler/escrever arquivos, shell); se as ferramentas vivem fora do processo, descoberta e chamadas passam por MCP.
4. Onde aparecerem parâmetros estruturados, JSON Schema ainda fixa os campos — sobretudo para o que sai da máquina.

Fluxo de dados em uma linha:

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

Cola de depuração: modelo chama a ferramenta errada → Tools / Schema; processo de ferramenta não conecta → MCP; passos ficam sendo pulados → Skill; contexto explode ou se contamina → Subagent.

O que está mudando na pilha de agentes de 2026

Comparado com o «enfiar funções no prompt» de 2024, 2026 se comprime em cinco mudanças:

Outro fio é a fusão de saídas estruturadas com argumentos de ferramentas: JSON de negócio, argumentos de ferramentas e inputSchema do MCP compartilham a mesma disciplina de Schema. Veja o que é saída estruturada e a comparação OpenAI vs Gemini.

No lado do produto, agentes de IDE não são mais só «chat + autocomplete»: a pilha padrão inclui tool calling, conectores MCP, um diretório de Skills e subagentes geráveis. Para quem constrói, isso significa entregar mais do que uma API — ferramentas descobíveis (MCP/Tools) + fluxos seguíveis (Skills) + papéis que você pode delegar quando precisar (Subagents).

O que escolher e escrever agora

• Escreva o Schema antes de expor a ferramenta. Defina additionalProperties: false, preencha required; valide argumentos de exemplo no navegador com as ferramentas deste site.
• Empacote um MCP Server só quando as ferramentas precisarem ser reutilizadas entre apps. Um script único embutido em um Host não precisa de MCP.
• Codifique fluxos repetidos da equipe como Skills. Publicar, migrar, triagem, revisão de segurança — se os passos são estáveis, pare de depender de «lembrar de lembrar o modelo».
• Separe um Subagent quando o contexto alongar. Prefira delegar trabalho exploratório, somente leitura e de alto ruído; mantenha decisões e patches finais no pai.
• Não substitua Schema por um Skill, nem MCP por um Subagent. Processo ≠ contrato ≠ transporte. Misturá-los produz «o doc diz validar» enquanto a produção nunca roda a checagem.

Para checagens JSON locais, salve inputSchema, amostras de argumentos do modelo e amostras de resultado de MCP tools/call, e use o validador JSON e o JSON Diff. Nada sai do navegador — o mesmo instinto de privacidade que prioriza o dispositivo.

FAQ

Resumo

Tools definem o que o modelo pode chamar; MCP define como ferramentas são descobertas e invocadas a partir de processos externos; Skills definem como o trabalho é feito conforme o manual; Subagents definem como o contexto é isolado e delegado. A pilha de agentes de 2026 está convergindo de «uma caixa de chat + funções ad hoc» para essas quatro camadas mais um cinturão de contrato JSON Schema.

Cresça a pilha de dentro para fora. Acerte Schema e Tools primeiro; depois adicione MCP, Skills ou Subagents sob pressão de reutilização, processo ou contexto. Valide amostras localmente antes de publicar — modelos podem mudar; nomes de campo e required não deveriam.