Vou ser sincero: a primeira vez que eu vi MCP e Skills no mesmo projeto, eu tratei os dois como se fossem a mesma coisa. “Ah, é jeito de dar ferramenta pro modelo.” Errado. Um diz o que o agente consegue tocar. O outro diz como ele deveria trabalhar. Confundir isso custa token, custa tempo e, no pior caso, custa um agente que autentica em tudo e ainda assim faz o fluxo errado.
Se você está construindo agente em 2026, essa distinção não é filosofia. É decisão de arquitetura. Eu uso a metáfora que grudou na minha cabeça: MCP são as ferramentas da caixa. Skills são as receitas. Uma sem a outra até funciona. As duas juntas, no lugar certo, é o que separa agente de brinquedo de agente que aguenta o tranco no dia a dia.
O que o MCP é de fato
MCP, o Model Context Protocol, é um protocolo aberto. Ele não ensina o modelo a cozinhar. Ele conecta o agente a ferramentas e sistemas externos. Banco, rastreador de ticket, drive da empresa, API de pagamento: o MCP é o cabo que liga a conversa ao mundo lá fora.
Na prática, cada ferramenta chega com um schema no contexto. O modelo vê o nome, os parâmetros, o que aquela chamada faz. Tem autenticação OAuth embutida, e isso muda o jogo quando o destino é um SaaS de verdade, com conta de gente, com permissão, com token que expira. Em ambiente corporativo isso não é detalhe. É o motivo de o MCP existir com cara de produto sério, não de script solto no canto da máquina.
O lado feio também é simples: schema demais incha o contexto. Você pluga dez, quinze ferramentas “porque pode” e de repente o modelo gasta uma fatia absurda só pra lembrar que existe create_issue, list_files e mais um monte de verbo que ele talvez nem use naquela conversa. MCP responde bem a pergunta “o que o agente pode acessar?”. Ele não responde “em que ordem eu faço isso sem fazer caca”.
Eu penso em MCP como a gaveta de chaves da oficina. Cada chave abre uma porta. Nenhuma chave te ensina a montar o motor. Se a sua dor é autenticação, permissão e acesso a sistema que não é seu, o protocolo está no lugar certo. Se a sua dor é o agente improvisar o procedimento, chave nova não resolve. Só aumenta a gaveta.
O que Skills são de fato
Agent Skills são outra história. Não é protocolo. É pasta. Dentro dela, um SKILL.md: markdown com frontmatter YAML. Ali você descreve um fluxo de trabalho completo. Não um verbo isolado. O caminho inteiro: quando começar, o que checar, que arquivo olhar, que decisão tomar se der ruim.
O truque que eu gosto é o jeito de carregar o conteúdo. O modelo, no começo, vê só o nome e uma descrição curta. O miolo da receita só entra no contexto quando ele realmente precisa. Isso é economia de token na veia. Contexto enxuto por padrão, detalhe quando a tarefa pede. Você não despeja o manual inteiro na mesa pra fritar um ovo.
O que Skills não têm: autenticação nativa. Elas não abrem a porta do sistema de mensagens por você. Elas não negociam OAuth. Se o fluxo precisa de um sistema externo de verdade, a Skill aponta o caminho; alguém — em geral o MCP — segura a chave. Skills brilham quando o trabalho se repete e o jeito certo cabe num texto. Elas respondem “como o agente deve trabalhar?”, não “o que ele pode acessar?”.
Se MCP é a gaveta de chaves, Skill é aquele caderno sujo de óleo com o passo a passo que o sênior da oficina escreveu depois de errar três vezes. Eu leio aquele caderno. Eu não finjo que a chave de fenda já sabe o torque.
A diferença prática: ferramentas versus receitas
Vamos cravar a metáfora, porque é ela que eu uso quando alguém me pede pra “só plugar mais uma ferramenta” e acha que o agente vai ficar mais esperto.
MCP são os verbos. As capacidades. Listar, criar, buscar, autenticar, ler um arquivo remoto. Cada ferramenta é uma ação possível. O modelo escolhe o verbo. Se você só entrega verbo, ele improvisa a coreografia. Às vezes acerta. Às vezes comenta no ticket antes de ler o diff. Às vezes chama três APIs quando uma bastava. Capacidade sem ofício vira agente ansioso.
Skills são as receitas. Elas dizem a ordem, o critério, o atalho. É o procedimento. Não substitui a ferramenta. Ensina a usá-la sem reinventar a roda a cada prompt. O valor não está em mais um schema. Está no “a gente sempre faz assim, e tem motivo”.
Resumo que eu escrevo no quadro quando alguém mistura as duas coisas:
- MCP responde: o que o agente pode acessar?
- Skills respondem: como o agente deve trabalhar?
- MCP traz OAuth, schema e porta de entrada pra sistema externo.
- Skills trazem fluxo completo, texto, e contexto que só engorda quando precisa.
- MCP sem Skill é caixa cheia e serviço torto. Skill sem MCP, quando a tarefa exige SaaS, é receita sem ingrediente.
Quando usar cada um
Não existe regra esculpida em pedra, mas existe o meu critério depois de quebrar a cara. Eu não escolho tecnologia. Eu escolho a pergunta que está sem resposta.
Eu vou de MCP quando:
- Preciso autenticar de verdade, com OAuth, em conta que não é a minha máquina.
- O agente mora em ambiente corporativo e vai falar com SaaS externo.
- A capacidade é um verbo claro: buscar ticket, ler planilha, mandar mensagem, consultar API.
- Várias pessoas e vários agentes precisam da mesma porta, não do mesmo jeito de trabalhar.
- O risco real é acesso errado, token expirado, permissão, não é “o modelo não leu o runbook”.
Eu vou de Skills quando:
- O fluxo se repete. Review, triagem, publicar post, montar relatório semanal.
- O valor está no procedimento, não na tomada da porta.
- Eu quero contexto enxuto: nome e descrição curta no começo, miolo só na hora H.
- Token está caro ou o contexto já está lotado de schema de ferramenta.
- O time já sabe o caminho certo e esse caminho cabe num
SKILL.md, não numa dezena de verbos soltos.
E eu fujo de dois erros clássicos. Primeiro: empilhar MCP até o schema comer o contexto inteiro. Segundo: escrever Skill como se ela fosse um conector. Skill sem ferramenta, quando a tarefa exige sistema externo, vira receita de bolo sem farinha. Bonita. Inútil. Do outro lado, MCP demais vira aquela caixa de ferramentas que você não fecha e ainda assim nunca acha a chave Phillips.
Como os dois se combinam na prática
O desenho que eu curto é chato de tão óbvio. MCP abre as portas. Skill ensina a caminhada. Eu não quero que a receita carregue a chave. Eu não quero que a chave invente o passo a passo.
Exemplo do meu dia: o agente precisa atualizar um ticket, puxar o diff e escrever um resumo no canal da equipe. O MCP segura o acesso — OAuth, schema da ferramenta, chamada autenticada. A Skill descreve a receita: leia o ticket, não comente se o diff for só formatação, use este tom, só então poste. O modelo vê a Skill pelo nome. Quando a tarefa casa com a descrição, ele puxa o SKILL.md. Aí sim os verbos do MCP entram na dança, na ordem certa, sem despejar o manual no contexto antes da hora.
Outro jeito de ver: se amanhã o SaaS mudar o OAuth, eu mexo no MCP. Se amanhã o time mudar o critério de “pronto pra revisar”, eu mexo no SKILL.md. Separar o cabo da receita me deixa dormir melhor. Cada peça quebra no lugar certo. Cada conserto fica pequeno.
Dá pra viver só com um dos dois? Dá. Agente interno, sem auth, fluxo único, Skill pura resolve. Agente que só consulta um sistema e o usuário já sabe o que pedir, MCP puro resolve. O ponto em que a coisa fica boa é quando a caixa de ferramentas está conectada e o caderno de receitas está ao lado, sem misturar as páginas. Eu quero verbo quando preciso agir. Eu quero receita quando preciso acertar o ofício.
Minha opinião, sem rodeio
Se você me perguntar no corredor o que priorizar, eu não começo pelo protocolo da moda. Eu pergunto: o agente está perdido porque não alcança o sistema, ou porque alcança e ainda assim trabalha torto? Porta fechada é MCP. Porta aberta e serviço ruim é Skill. Se as duas dores existem, os dois entram. Sem drama. Sem bandeira.
Em 2026 os dois convivem. Tratar MCP e Skills como time que se completa, não como briga de padrão, é o que tem funcionado pra mim. Ferramenta sem receita vira agente ansioso, chamando API à toa. Receita sem ferramenta vira texto bonito que não mexe em nada. Eu quero os dois. Na dose certa. Com o contexto magro. Com a chave na porta certa. E com o caderno aberto só quando a comida está no fogo.