Em poucas palavras
MCP (Model Context Protocol, ou protocolo de contexto de modelo) é um padrão aberto que define como aplicações de IA se conectam a sistemas externos, como fontes de dados e ferramentas. Uma skill é uma pasta com um arquivo de instruções que ensina um agente a fazer um tipo específico de tarefa, seguindo uma especificação aberta. Os dois se complementam: o MCP padroniza as conexões, e as skills padronizam os manuais.

Apresentação

Dando continuidade à série IA na prática, é hora de resolver as últimas pendências de vocabulário. No artigo anterior, expliquei as palavras mais usadas nesse cenário de IA: modelo, harness, contexto, ferramentas, loop e agente.

Mas duas palavras ficaram de fora de propósito, porque explicá-las exige muitos detalhes. Ao fazer o rascunho, percebi que era melhor escrever um artigo só para elas.

Elas apareceram lá no primeiro artigo da série, quando descrevi o grupo de pessoas entusiastas que sabe o que são harness, MCP, engenharia de prompt, agentes e skills. O harness e os agentes já foram explicados. Hoje é a vez do MCP e das skills.

Antes de qualquer coisa, quero deixar claro o recorte deste artigo. MCP e skills não são recursos exclusivos de uma empresa nem de um modelo só.

Esses recursos são padrões abertos: regras publicadas, discutidas em público, que funcionam com Claude, com GPT, com Gemini e com dezenas de outras ferramentas. Os dois nasceram dentro de uma empresa, sim, é verdade, e vou contar essa história. Hoje, o MCP mora em uma fundação neutra, e as skills seguem uma especificação aberta, adotada por dezenas de ferramentas.

E por que você deveria se importar com isso? Porque esses dois padrões respondem a duas perguntas que ficaram abertas no artigo anterior.

Vimos que o modelo usa ferramentas dentro de um loop (repetição). Mas quem fabrica essas ferramentas? Como elas se encaixam no harness? E, melhor ainda, como se ensina um agente a trabalhar do jeito que uma pessoa ou uma equipe trabalha, sem repetir as mesmas instruções toda vez?

Resumindo: o MCP cuida das conexões, e as skills cuidam das instruções. A resposta longa e detalhada é a leitura deste artigo.

Relembrando as palavras que já foram aprendidas

Para ninguém se perder, vamos lembrar em poucas palavras os conceitos já apresentados:

  • O modelo é a parte que gera texto: ele prevê o próximo token com base nos tokens anteriores.

  • O harness é a estrutura de suporte ao redor do modelo: prepara o contexto, aciona as ferramentas e faz cumprir as regras.

  • O produto é a experiência final que você usa: o chat, o aplicativo, a extensão do editor.

  • O contexto é tudo o que o modelo recebe antes de responder, e a janela de contexto é o tamanho da mesa onde esse material é colocado.

  • Uma ferramenta, ou tool, é uma capacidade externa: o modelo pede, e quem põe a ferramenta para funcionar é o harness.

  • O loop é o ciclo de trabalho: o modelo analisa, pede uma ferramenta, recebe o resultado e decide o próximo passo.

  • E o agente, na definição que usei lá: um modelo de linguagem capaz de usar ferramentas dentro de um loop para tentar cumprir um objetivo.

Também não dá para esquecer do context rot (o “apodrecimento do contexto”): quando a mesa de trabalho fica cheia demais, a qualidade da resposta pode cair. Contexto de qualidade vale mais do que contexto em quantidade.

Com o vocabulário no lugar, podemos seguir em frente.

O problema das muitas tomadas

Vamos começar pelo MCP e pelo problema que ele tenta resolver.

Pense nas ferramentas de IA por volta de 2024. Cada produto queria se conectar com coisas úteis do dia a dia digital: agenda, e-mail, planilhas, bancos de dados, GitHub e sistemas internos das empresas. Só que cada um criava o seu próprio jeito de fazer essa comunicação.

O resultado era muito retrabalho. Quem criava um serviço, por exemplo, um sistema de agenda, precisava fazer uma integração diferente para cada produto de IA. E quem criava um produto de IA precisava fazer um conector diferente para cada serviço.

Com dez produtos e dez serviços, podiam existir até cem integrações separadas, cada uma com seus problemas, sua manutenção e sua documentação.

Para quem usava, o problema aparecia de outro jeito, talvez bem familiar: a IA ficava isolada. Para ela analisar um relatório, você copiava o texto e colava no chat. Para usar a resposta, copiava tudo de volta e colava no documento.

A pessoa virava uma ponte entre a IA e o resto do computador, levando informação de um lado para o outro o dia inteiro. O problema não era falta de inteligência do modelo; era falta de conexão.

A versão física desse problema são as tomadas, que mudam de país para país. O plugue que funciona no Brasil não entra na tomada dos Estados Unidos, e o dos Estados Unidos não entra na tomada do Reino Unido.

Se você viaja por vários lugares do mundo, a solução é levar vários adaptadores, um para cada destino. Funciona, mas está longe de ser ideal.

No mundo dos eletrônicos, uma parte desse problema foi resolvida com o USB-C. Se você não conhece pelo nome, é aquele conector pequeno e achatado, de pontas arredondadas, que aparece nos celulares e notebooks mais novos. Ele encaixa dos dois lados, e o mesmo cabo pode carregar celular, fone e notebook, mesmo de marcas diferentes.

A União Europeia chegou a exigir esse conector por lei, justamente para diminuir aquela gaveta cheia de cabos diferentes. A regra vale para celulares novos desde dezembro de 2024 e para notebooks desde abril de 2026.

Até a Apple, que usava um conector próprio no iPhone, passou para o USB-C em setembro de 2023, com o iPhone 15, antes mesmo de a regra começar a valer.

O MCP foi criado para ser algo parecido. A documentação oficial do projeto diz que ele é como “a porta USB-C das aplicações de IA”. Em outras palavras, ele propõe um encaixe único entre as ferramentas de IA e o resto do mundo digital.

A linha do tempo mostra como ele foi adotado. O MCP foi anunciado pela Anthropic em 25 de novembro de 2024, já como um padrão aberto, com o código e a especificação publicados. Em 26 de março de 2025, a OpenAI, principal concorrente da Anthropic, anunciou que também usaria o padrão em seus produtos.

Duas semanas depois, em 9 de abril de 2025, foi a vez do Google DeepMind. Demis Hassabis, que comanda o laboratório, anunciou suporte ao MCP nos modelos Gemini e disse que o MCP é um bom protocolo, que está virando rapidamente um padrão aberto para a era dos agentes de IA.

Hoje, aplicações como Claude, ChatGPT, VS Code, Cursor e muitas outras já são compatíveis com ele.

Não é todo dia que concorrentes diretas adotam a mesma tecnologia. Quando isso acontece, geralmente é sinal de que o problema era grande e de que a solução fazia sentido.

MCP: o nome por partes

MCP é a sigla de Model Context Protocol. Em português, dá para chamar de protocolo de contexto de modelo.

  • Model é o modelo, a mesma ideia do artigo anterior: a parte da IA que tenta prever os próximos tokens.

  • Context é o contexto: tudo aquilo que colocamos diante do modelo antes de ele responder.

  • E protocol, ou protocolo, é a palavra nova aqui. Um protocolo é um combinado de regras para a conversa funcionar.

Pense no trânsito: cada pessoa dirige um carro diferente, mas todo mundo entende que a placa de “pare” e o sinal vermelho mandam parar. Como todos seguem as mesmas regras, carros de pessoas que nunca se viram conseguem circular juntos sem bater.

A internet também funciona assim, cheia de protocolos. Quando você abre um site, o navegador e o servidor seguem um conjunto de regras chamado HTTP. Eles não precisam se conhecer antes; basta falarem do mesmo jeito.

Para saber mais, leia o artigo Computação para Iniciantes: Introdução às Redes de Computadores.

Resumindo: o MCP é um padrão aberto que define como aplicações de IA podem se conectar a sistemas externos, como fontes de dados, ferramentas e fluxos de trabalho. Ele combina, por exemplo, como a aplicação pergunta “o que você oferece?”, como essas opções aparecem em uma lista e como um pedido é feito e respondido.

Quem é quem: host, cliente e servidor

O MCP tem três partes principais. Os nomes vêm do inglês: host, que significa anfitrião; client, que significa cliente; e server, que significa servidor.

O host é o aplicativo de IA que você usa, como Claude, VS Code, Claude Code ou ChatGPT. Nesta série, ele é o produto com o seu harness: a parte que organiza tudo e conversa com você.

O servidor MCP é um programa que oferece coisas úteis para a IA usar, como dados, ferramentas e instruções prontas. Um servidor de agenda mostra a agenda. Um servidor de clima traz a previsão do tempo. Um servidor do GitHub permite trabalhar com repositórios de código.

Aqui existe uma confusão comum por causa do nome. No dia a dia, quando falamos “servidor”, muita gente pensa em um computador grande ligado à internet. No MCP, não precisa ser assim.

Um servidor MCP é só um programa. Ele pode rodar no seu computador, como servidor local, ou em algum lugar da internet, como servidor remoto. Por exemplo, um servidor que lê arquivos da sua máquina roda na sua própria máquina.

O terceiro participante é o cliente. Ele é uma parte que o host cria internamente, uma para cada conexão, e cada cliente conversa com apenas um servidor. Então, se o host estiver ligado a três servidores, ele terá três clientes.

Pense assim: o host é como um escritório, e os servidores são empresas que prestam serviço para esse escritório. Para cada empresa, o escritório escolhe uma pessoa de contato, que fala apenas com aquela empresa.

Essa pessoa de contato é o cliente. O escritório decide o que precisa ser feito, e as pessoas de contato mantêm cada conversa separada e organizada.

O desenho abaixo mostra essa ideia.

As mensagens: um formato só

Depois de entender quem participa, falta entender como eles conversam. No MCP, clientes e servidores trocam mensagens de texto em um formato chamado JSON-RPC.

Cada mensagem é um pedido, uma resposta ou um aviso (que não espera resposta), sempre escrita de um jeito organizado. Cada pedido recebe um identificador, que pode ser um número ou um texto curto, e a resposta volta com esse mesmo identificador. Assim, fica claro qual resposta pertence a qual pedido.

Você já vê isso acontecer no dia a dia. Quando pede comida por aplicativo, o pedido ganha um número, e é por ele que você acompanha tudo: o pedido 42 saiu para entrega, o pedido 42 chegou. Em um cartório, acontece algo parecido com o número de protocolo. No MCP, a lógica é a mesma, só que entre programas.

Outro ponto da versão atual do padrão, a de 28 de julho de 2026, é que cada pedido já vem completo. Ele traz tudo o que o servidor precisa para responder, como uma carta bem explicada, que não depende de o destinatário lembrar das cartas anteriores. Existe um nome para isso: protocolo stateless (sem estado).

Isso facilita a vida de quem cria servidores que atendem muitas pessoas ao mesmo tempo: qualquer cópia do servidor pode responder a qualquer pedido, porque nenhuma delas precisa lembrar da conversa anterior.

E o ponto mais importante é este: como todos usam o mesmo formato, qualquer host que entenda MCP consegue conversar com qualquer servidor que também entenda MCP. É como uma regra de trânsito que vale para todo mundo.

O que um servidor oferece: tools, resources e prompts

Quando o host se conecta a um servidor, a primeira coisa que ele quer saber é: o que você oferece? A resposta vem em um catálogo com até três tipos de item, que o padrão chama de primitivas do servidor.

  • O primeiro tipo são as tools (ferramentas): funções que o modelo pode pedir para executar. Consultar a previsão do tempo, criar um evento na agenda, abrir um chamado no GitHub, buscar um registro no banco de dados. São as mesmas tools do artigo anterior; a novidade é que agora elas vêm de fora, descritas em um formato padronizado.

  • O segundo tipo são os resources (recursos): fontes de dados que podem virar contexto. O conteúdo de um arquivo, a estrutura de um banco de dados, um documento. Um resource não executa nada; ele fornece material de leitura para a mesa do modelo.

  • O terceiro tipo são os prompts: modelos de instrução prontos, escritos por quem criou o servidor. Um servidor de revisão de textos pode oferecer, por exemplo, um roteiro pronto de revisão que você aciona quando quiser.

A documentação oficial mostra um exemplo que mistura os três. Imagine um servidor MCP de banco de dados: ele pode ter tools para fazer consultas, um resource que mostra como as tabelas estão organizadas e um prompt com exemplos de como usar essas ferramentas.

Voltando à comparação com o escritório: a empresa que presta o serviço chega com uma caixa de ferramentas (as tools), uma pasta de documentos (os resources) e alguns modelos prontos de atendimento (os prompts).

Quando o modelo decide usar uma tool, ele não executa nada sozinho. Quem leva o pedido até o servidor é o harness do host, e quem faz o trabalho é o servidor. É o host, também, que pede a sua autorização antes de fazer algo importante ou sensível.

O MCP não muda essa divisão. Ele só cria um jeito padrão de organizar o catálogo e de fazer o pedido.

A própria especificação coloca o consentimento como princípio: os hosts devem obter a permissão explícita da pessoa usuária antes de usar qualquer tool. Só que o protocolo, sozinho, não tem como obrigar ninguém a seguir isso.

Por isso, quem implementa a tela de permissão é o host, e a especificação recomenda que sempre exista uma pessoa no meio do caminho, com poder de negar o uso de uma ferramenta.

O que acontece na volta: quando o servidor pergunta algo a você

Até aqui, a conversa foi em uma direção só: o host pergunta e o servidor responde. Mas o padrão também deixa o servidor pedir algo a você, com um recurso chamado elicitation, algo como “pedido de informação”.

Funciona assim: no meio de uma tarefa, o servidor pode perceber que está faltando uma informação ou uma confirmação. Em vez de dar erro ou tentar adivinhar, ele para e pergunta.

Por exemplo, um servidor de viagens pode parar antes de fechar uma reserva e perguntar: “Posso confirmar a reserva de três mil reais? Você prefere assento na janela ou no corredor?” O host mostra essa pergunta para você, pega a sua resposta e manda de volta para o servidor, que então continua o trabalho.

Aqui tem um detalhe que combina com a carta completa da seção anterior. Na versão atual, o servidor não puxa uma conversa nova por conta própria: ele responde ao pedido dizendo “preciso de mais informação”, e o host repete o pedido, agora com a sua resposta junto.

A elicitation pode funcionar de dois jeitos. No primeiro, o modo formulário, o servidor diz de quais informações precisa, e o host monta uma telinha com perguntas para você responder.

No segundo, o modo URL, o servidor envia um link para você abrir no navegador, e a conversa acontece fora dali. Esse é o jeito certo para informações sensíveis, como senhas e autorizações de pagamento, porque esses dados não passam pelo host e não entram no contexto do modelo.

A especificação, inclusive, proíbe pedir senha, chave de acesso ou dado de pagamento pelo modo formulário.

Por onde as mensagens viajam: stdio e HTTP

Ainda falta uma parte importante para entender a base do MCP: por onde as mensagens passam. O padrão define dois jeitos de fazer essa comunicação, e a escolha costuma depender de onde o servidor está.

Quando o servidor está no mesmo computador que o host, o transporte mais comum é o stdio, abreviação de standard input/output, ou entrada e saída padrão. É uma conversa direta entre dois programas dentro da mesma máquina, sem passar pela internet. Pense no interfone de um prédio: a chamada fica ali dentro, sem sair para a rua.

Quando o servidor está fora do seu computador, na internet, o transporte usado é o HTTP, o mesmo protocolo dos sites, adaptado para esse tipo de conversa.

Como a comunicação sai para a internet, entra a parte de segurança: chaves de API, tokens de acesso e o OAuth, o protocolo de autorização que funciona por trás de botões como “entrar com a conta Google”.

É como fazer uma ligação para fora do prédio, com alguém na recepção conferindo quem está chamando antes de completar a ligação.

O interessante é que as mensagens continuam as mesmas nos dois casos. O que muda é só o caminho por onde elas passam, não a forma como são escritas.

O MCP em ação: do Enter até a resposta

No artigo anterior, contei o que acontece quando você digita uma pergunta e aperta Enter. Agora dá para contar a mesma história de novo, com o MCP participando.

Imagine que o seu aplicativo de IA esteja ligado a um servidor MCP de clima, e você pergunte: “Como está o tempo em Ilhéus, na Bahia?”

Antes mesmo da pergunta, o host já perguntou ao servidor o que ele sabe fazer. O servidor respondeu com uma lista: uma ferramenta de previsão do tempo, com uma descrição de para que ela serve e de quais informações precisa receber. Essas informações entram no contexto, como se fossem colocadas na mesa do modelo.

Então a sua pergunta chega. O modelo lê o contexto, percebe que existe uma ferramenta de clima disponível e decide usá-la, dizendo qual cidade quer consultar. O harness recebe essa decisão.

Antes de chamar a ferramenta, o harness confere se tem a sua autorização. Cada host faz isso do seu jeito: alguns perguntam a cada uso, outros deixam você liberar uma ferramenta para a conversa inteira. Uma consulta de clima costuma ser liberada sem muita cerimônia, mas apagar alguma coisa ou gastar dinheiro merece sempre uma pausa.

Depois disso, o harness envia o pedido ao servidor MCP no formato padrão. Esse pedido tem até um nome técnico: tools/call.

O servidor busca a informação na fonte de dados dele, organiza a resposta e manda de volta. Esse resultado entra no contexto como texto.

O modelo lê tudo, e o ciclo continua. Se precisar de outra ferramenta, o processo se repete; se não precisar, o modelo escreve a resposta final, e o produto mostra isso na sua tela ou no seu leitor de telas.

É o mesmo ciclo do artigo anterior. A única diferença é que a ferramenta não foi criada dentro do produto. Ela veio de fora, por meio de um padrão que qualquer produto compatível consegue entender.

Antes de continuar, um detalhe: no exemplo, só a tool entrou em ação, mas as outras primitivas também podem participar. Se o servidor oferecesse um resource, por exemplo, um documento com as regras de Ilhéus para eventos ao ar livre, o host poderia trazer esse material antes de o modelo responder.

E, se o servidor oferecesse um prompt de “planejar passeio conforme o clima”, você poderia usá-lo direto, como um atalho pronto. A ideia é simples: a tool faz algo, o resource traz informação e o prompt orienta a resposta. Os três chegam pela mesma conexão.

E por que isso ajuda todo mundo? Porque resolve aquele problema de criar uma integração diferente para cada lugar. Quem cria um serviço faz um servidor MCP, e ele pode funcionar em qualquer host compatível: no Claude, no ChatGPT, no VS Code, no Cursor.

Quem usa também ganha: pode trocar de produto de IA e continuar usando as mesmas conexões, porque elas não ficam presas a um produto específico. A integração deixa de ser um acordo separado entre empresas e passa a ser uma base comum.

O catálogo oficial: o MCP Registry

Com tantos servidores MCP aparecendo, surgiu uma pergunta natural: como achar um servidor confiável? Para isso, existe o MCP Registry, o catálogo oficial desse ecossistema. Ele ainda está em fase de testes, chamada pelo projeto de preview.

O Registry é um catálogo de informações. Para cada servidor público, ele mostra o nome, a descrição, onde baixar e como configurar. Ele não guarda o código do servidor, que continua nos lugares de sempre, como npm, PyPI e Docker Hub. É como o catálogo de uma biblioteca: ele mostra onde o livro está, mas não é o livro.

Os nomes no Registry seguem um padrão ligado a domínios e contas verificadas. Ou seja, só quem é dono de um site ou de uma conta do GitHub consegue publicar servidores usando aquele nome. Isso ajuda a impedir que alguém crie um servidor falso se passando por uma empresa conhecida.

Mas atenção: o Registry verifica o nome, não o que o servidor faz. A análise de segurança do código fica por conta dos repositórios de pacotes e dos catálogos que reúnem e filtram esses servidores.

As MCP Apps

Antes de mudar de assunto, vale citar uma novidade: as MCP Apps. Lançadas em 26 de janeiro de 2026, elas são a primeira extensão oficial do padrão e permitem que os servidores mostrem pequenas telas interativas dentro da própria conversa, como gráficos, formulários e painéis.

É um passo além de responder só com texto. Como toda extensão do MCP, ela é opcional, e o suporte ainda varia de host para host. Por enquanto, fica o registro de que isso existe; talvez vire um artigo próprio no futuro.

Skills: manuais que o agente aprende a consultar

Agora vamos à segunda palavra do título. O primeiro ponto é entender que as skills resolvem um problema diferente do que o MCP resolve.

O MCP resolve o problema das conexões: é ele que dá ao agente a capacidade de se comunicar com outros sistemas. Mas pense em uma pessoa muito competente no primeiro dia de trabalho. Ela sabe fazer as coisas, tem acesso aos sistemas e escreve bem. Mesmo assim, ainda falta entender o jeito da casa.

Falta saber qual modelo de relatório a equipe usa, qual é a ordem dos passos para fechar o mês e qual tom usar nos e-mails para clientes. E aquelas regrinhas que só conhece quem já passou por alguns problemas.

Com agentes de IA é parecido. O modelo sabe escrever e raciocinar, e as ferramentas o ajudam a alcançar outros sistemas. O que falta é o conhecimento de procedimento: o passo a passo, o padrão e o critério.

E, como vimos no artigo anterior, o modelo não tem memória permanente das conversas. Sem um lugar para guardar esse jeito de fazer as coisas, você precisa explicar tudo de novo a cada conversa, todo dia, para sempre.

A skill serve para resolver isso. A palavra vem do inglês e significa habilidade. Na prática, uma skill é uma pasta com um arquivo de instruções que ensina um agente a fazer um tipo específico de tarefa.

A comparação de que eu mais gosto é com o caderno de receitas da família. Uma pessoa que cozinha bem sabe fazer muita coisa; isso é como o modelo com o treinamento que recebeu.

Mas o bolo “daquele jeito” só sai com a receita da avó, com os truques anotados ao lado. A skill é essa receita, escrita para o agente consultar quando precisar.

Um pouco de história, bem rápido

As skills foram anunciadas pela Anthropic em 16 de outubro de 2025, primeiro como um recurso do Claude.

Em 18 de dezembro de 2025, a empresa publicou a especificação do formato como um padrão aberto, em um site próprio, o agentskills.io, com o desenvolvimento aberto a contribuições da comunidade. E o mercado adotou o formato bem rápido.

A anatomia de uma skill

Vamos abrir uma skill e ver como ela é por dentro. A estrutura é bem simples:

  • A skill é uma pasta, e o nome da pasta é o nome da skill.

  • Dentro dela existe um arquivo obrigatório, sempre chamado SKILL.md. É ele que carrega as instruções.

  • Opcionalmente, a pasta pode ter uma subpasta scripts, com pequenos programas prontos que o agente pode executar.

  • Também opcional: uma subpasta references, com documentação de apoio para consulta.

  • E uma subpasta assets, com modelos e arquivos de trabalho, como um modelo de documento, imagens ou tabelas de dados.

Só o SKILL.md é obrigatório. As três subpastas são uma convenção recomendada pela especificação, e a pasta pode ter outros arquivos se a skill precisar. Uma skill pode ser apenas uma pasta com um arquivo de texto dentro, e muitas das melhores são exatamente isso.

E o que existe dentro do SKILL.md? Duas partes. A primeira é o cabeçalho, um pequeno bloco em YAML, um formato de texto fácil de ler, organizado em pares de campo e valor. Ele funciona como a ficha do arquivo: mostra o nome da skill e explica o que ela faz.

A segunda parte é o corpo: as instruções de verdade, escritas em Markdown, um jeito simples de formatar texto usando caracteres comuns, como # para títulos e - para listas.

O cabeçalho tem dois campos obrigatórios. O name é o nome da skill e tem regras bem específicas: até 64 caracteres, só letras minúsculas, números e hífens, sem hífen no começo, no fim ou dois seguidos. Ele também precisa ser igual ao nome da pasta.

Já a description é um resumo de até 1.024 caracteres. Ela precisa dizer duas coisas: o que a skill faz e quando ela deve ser usada. Também existem campos opcionais, como license, que indica a licença de uso, e metadata, que guarda informações livres, como autoria e versão.

Isso vai ficar mais claro daqui a pouco, quando a gente ler uma skill de verdade, linha por linha.

Revelação progressiva: três etapas para não lotar a mesa

Lembra do apodrecimento do contexto, o context rot? Se o agente colocasse o conteúdo completo de todas as skills disponíveis em toda conversa, a mesa ficaria sempre cheia demais, e a qualidade cairia.

Uma pessoa com cinquenta skills instaladas gastaria muitos tokens, e muita atenção do modelo, com instruções que não têm nada a ver com a tarefa do momento.

A especificação resolve isso com uma ideia chamada revelação progressiva, ou progressive disclosure. Na prática, o conteúdo aparece aos poucos, em três etapas, e só passa para a próxima etapa se a tarefa realmente precisar.

  • Etapa 1, descoberta. Quando o agente começa, ele coloca no contexto só o name e a description de cada skill instalada. Isso custa cerca de cem tokens por skill, bem pouco, e já basta para o agente saber que aquela skill existe e para que ela serve.

  • Etapa 2, ativação. Quando a sua tarefa combina com a description de uma skill, o agente lê o arquivo SKILL.md inteiro e coloca esse conteúdo no contexto. A recomendação oficial é que as instruções fiquem abaixo de cinco mil tokens e que o SKILL.md tenha menos de quinhentas linhas, justamente para caber bem na mesa.

  • Etapa 3, execução. Seguindo as instruções, o agente abre os arquivos de apoio e roda os scripts da pasta, mas só aqueles que a tarefa pedir.

Para ter uma ideia da economia: cinquenta skills instaladas gastam, na etapa 1, algo perto de cinco mil tokens no total. Em uma janela de contexto de 200 mil tokens, isso é 2,5% da mesa.

Sem a revelação progressiva, a conta muda muito. Se cada uma dessas cinquenta skills chegasse ao limite recomendado de cinco mil tokens, carregar todas de uma vez daria 250 mil tokens, mais do que muitas janelas de contexto comportam.

Imagine uma estante de manuais ao lado da mesa de trabalho. Na mesa, que é o contexto, fica só a lombada de cada manual, com o título e um resumo.

O manual inteiro só sai da estante quando a tarefa precisa dele, e os anexos só aparecem se o próprio manual mandar. Assim, a mesa fica livre para o que realmente importa.

Essa estrutura mostra por que a description é a parte mais importante de uma skill. Ela é o único pedaço que o agente vê o tempo todo, como a lombada do manual na estante.

Uma description vaga é um manual que talvez nunca saia da estante, ou pior, que sai na hora errada. Por isso a regra é escrever nela o que a skill faz e quando ela deve ser usada.

Quem já adotou as skills

A página oficial do padrão mantém uma lista pública de produtos compatíveis. No começo de outubro de 2026, essa lista tem 46 produtos. Veja alguns nomes para ter uma ideia do tamanho disso:

  • Claude e Claude Code, da Anthropic.

  • ChatGPT e Codex, da OpenAI.

  • Gemini CLI, do Google.

  • GitHub Copilot e VS Code, da Microsoft.

  • Cursor, Junie (da JetBrains), Goose (da Block), Vibe (da Mistral AI), TRAE (da ByteDance) e Kiro (da AWS).

  • E mais uma fila de ferramentas de programação e de plataformas de dados, como OpenCode, OpenHands, Roo Code, Tabnine, Spring AI, o Cortex Code, da Snowflake, e o Genie Code, da Databricks.

Ou seja: empresas concorrentes já leem o mesmo formato de arquivo, dentro da mesma estrutura de pasta.

Na prática, isso traz o mesmo benefício do MCP. A skill que você cria hoje para uma ferramenta pode funcionar em outras. E, como uma skill é feita de texto e arquivos, você pode guardar tudo em uma pasta do projeto, versionar no Git junto com o código e compartilhar com a sua equipe ou com qualquer pessoa.

Nossa primeira skill

Vamos criar uma skill de exemplo que ensina o agente a escrever texto alternativo para imagens em português. Texto alternativo, ou alt text, é uma descrição escrita que acompanha a imagem.

Os leitores de tela leem essa descrição em voz alta, ou mostram na linha braille, no lugar da imagem. É o que faz uma foto “existir” para quem não a vê.

Escrever boas descrições é uma habilidade com regras e boas práticas, ou seja, um caso perfeito de conhecimento de procedimento.

A skill é uma pasta chamada descricao-de-imagens, com o arquivo SKILL.md e uma subpasta references, onde fica o arquivo graficos.md, citado na última linha. O SKILL.md completo fica assim:

---
name: descricao-de-imagens
description: Escreve textos alternativos (alt text) em português para imagens de artigos e posts. Use quando a tarefa envolver descrever imagens, revisar a acessibilidade de um post ou preencher o atributo alt de fotos, gráficos e capturas de tela.
license: CC-BY-4.0
metadata:
  autora: louise-suelen
  versao: "1.0"
---

# Descrição de imagens em texto alternativo

Você vai escrever descrições de imagens para pessoas que usam leitores de tela, seguindo o critério 1.1.1 das WCAG 2.2.

## Passo a passo

1. Identifique a função da imagem no texto: informativa, funcional, decorativa, imagem de texto ou imagem complexa (gráfico, diagrama, infográfico).

2. Se a imagem for decorativa, ela precisa ser ignorada pela tecnologia assistiva. Use o atributo alt vazio (alt="") ou, quando possível, coloque a imagem no CSS, como imagem de fundo.

3. Nunca deixe uma imagem sem o atributo alt: sem ele, alguns leitores de tela leem o nome do arquivo.

4. Se for informativa, descreva o conteúdo essencial em até 150 caracteres.

5. Se for funcional (um link ou um botão), descreva a ação, não a aparência: "Buscar", e não "Lupa", por exemplo.

6. Se for imagem de um texto, o alt repete o texto que está na imagem.

7. Comece pelo assunto principal. Não abra com "imagem de" nem "foto de", porque o leitor de telas já avisa que é uma imagem. Só cite o tipo quando ele fizer diferença, como em uma pintura ou uma ilustração.

8. Em gráficos e tabelas, o alt traz a conclusão principal, e os dados completos vão em uma descrição longa, no texto logo abaixo da imagem.

9. Escreva em português claro (PT-BR), no mesmo tom do texto ao redor da imagem.

## Exemplos

Informativa. Bom: "Cachorro-guia de pelo claro conduz uma mulher em uma faixa de pedestres." Ruim: "Imagem de um cachorro."

Funcional, um ícone de lupa em um botão. Bom: "Buscar". Ruim: "Lupa".

Decorativa, uma faixa colorida entre duas seções. Bom: alt vazio, e a imagem é ignorada pela tecnologia assistiva. Ruim: "Faixa roxa decorativa".

Imagem de texto, um banner com a frase "Inscrições abertas". Bom: "Inscrições abertas". Ruim: "Banner do evento".

Complexa, um gráfico de barras. Bom: "Gráfico de barras: as matrículas cresceram todo ano de 2019 a 2024. Dados completos na tabela abaixo." Ruim: "Gráfico".

## Casos especiais

Antes de descrever gráficos complexos, leia o arquivo references/graficos.md.

É isso. Uma skill inteira, válida, pronta para funcionar em qualquer ferramenta compatível com o padrão. Agora vamos ler por partes.

O cabeçalho, linha por linha

O arquivo começa com uma linha de três hífens. Mais abaixo, aparece outra linha igual:

---
name: descricao-de-imagens
description: Escreve textos alternativos (alt text) em português para imagens de artigos e posts. Use quando a tarefa envolver descrever imagens, revisar a acessibilidade de um post ou preencher o atributo alt de fotos, gráficos e capturas de tela.
license: CC-BY-4.0
metadata:
  autora: louise-suelen
  versao: "1.0"
---

Tudo o que fica entre essas duas linhas é o cabeçalho, aquela ficha do arquivo que mencionei antes. Os três hífens servem só para marcar onde essa ficha começa e onde termina.

A primeira linha da ficha é name: descricao-de-imagens. Aqui tem um detalhe que parece erro, mas é regra: “descricao” está sem cedilha e sem til.

Lembra das regras desse campo? A especificação aceita letras minúsculas de “a” a “z”, números e hífens. E faz sentido: esse nome também vira nome de pasta e identificador em muitos sistemas diferentes, e acento ainda causa problema em alguns deles.

O nome técnico fica sem acento; o título bonito, com acento, aparece no corpo do arquivo.

A segunda linha é a description, e ela merece atenção. Pense nela como a lombada de um manual: a primeira frase diz o que a skill faz, “escreve textos alternativos em português”. A segunda diz quando ela deve ser usada, como em tarefas de descrever imagens ou revisar acessibilidade.

É essa segunda parte que ajuda o agente a escolher a skill na hora certa. Uma description que dissesse só “ajuda com imagens” até funcionaria do ponto de vista técnico, mas seria quase inútil na prática.

Depois aparecem dois campos opcionais. O license: CC-BY-4.0 informa a licença de uso. Neste caso, é uma licença Creative Commons que permite reutilizar o conteúdo, desde que a autoria seja indicada. Isso é uma boa prática para skills publicadas para outras pessoas usarem.

Já o metadata guarda informações livres, como autoria e versão, sempre como texto. É por isso que o “1.0” está entre aspas: sem elas, o YAML leria esse valor como número.

A especificação também permite outros dois campos opcionais. O compatibility diz quais requisitos o ambiente precisa cumprir, como um programa instalado ou acesso à internet.

Já o allowed-tools, ainda experimental, lista ferramentas pré-aprovadas, que o agente pode usar sem pedir confirmação enquanto segue a skill. Ele não proíbe as outras ferramentas, e o suporte a esse campo varia de produto para produto.

Eu não usei nenhum dos dois porque, na maioria dos casos, eles não são necessários.

O corpo: as instruções em si

Depois do cabeçalho, começa o corpo da skill. E aqui vem a parte boa: ele é texto livre. A especificação não obriga um formato específico.

Ela só recomenda o que costuma funcionar bem: um passo a passo claro, exemplos de entrada e de resultado, e uma parte separada para casos especiais.

O nosso corpo segue exatamente essa lógica. O passo a passo é numerado e direto, com critérios fáceis de checar: a função da imagem, o limite de 150 caracteres e a orientação para não começar com “imagem de”.

A parte de exemplos mostra um caso bom e um caso ruim, o que ensina mais rápido do que muita teoria. E os casos especiais ficam no final.

Observação: o limite de 150 caracteres é uma escolha da skill, e não uma regra das WCAG, que não fixam número nenhum. Ele aparece em guias de acessibilidade de universidades, como o da Universidade de Wisconsin em Madison.

A última linha traz um detalhe importante: “leia o arquivo references/graficos.md”. É a etapa 3 da revelação progressiva acontecendo na prática. As regras para descrever gráficos são longas, então elas não ficam enchendo o SKILL.md. Elas ficam em um arquivo de apoio, e o agente só abre esse arquivo se a tarefa envolver um gráfico.

E talvez este seja o ponto mais importante da seção: releia a skill e perceba que não existe programação nela. É português comum, com passo a passo, exemplos e critérios. Se você sabe escrever uma boa instrução, já tem o básico para escrever uma skill.

MCP e skills juntos

Depois de apresentar os dois padrões, dá para responder a uma pergunta comum: MCP e skills competem entre si? Não. Eles se complementam e foram feitos para trabalhar juntos.

A divisão é simples. O MCP responde com o que o agente pode agir: conexões, dados e ações disponíveis. As skills respondem como o agente deve agir: a ordem dos passos, os padrões e os critérios.

Um exemplo para juntar tudo: imagine uma secretaria de escola que, todo mês, precisa criar um relatório de acompanhamento dos estudantes. Esse relatório precisa ser acessível, com boa estrutura, tabelas simples e descrições nas imagens.

Uma skill chamada relatorio-mensal guardaria o passo a passo: quais dados buscar, em que ordem montar as seções, qual modelo de documento usar e quais pontos de acessibilidade conferir antes de entregar.

Já os servidores MCP criariam a conexão necessária para executar as ações: um servidor de planilhas para ler os dados das turmas e um servidor de e-mail para enviar o resultado.

A skill também pode ensinar quando usar cada servidor, por exemplo: “busque as notas na planilha tal usando a ferramenta tal; no fim, envie o documento para a coordenação”.

Uma peça não substitui a outra. O agente fica útil quando tudo funciona junto.

De projeto de empresa a padrão de todo mundo

Os dois padrões surgiram dentro da Anthropic, a mesma empresa do Claude. E isso, sozinho, já poderia gerar desconfiança.

A tecnologia tem muitos exemplos de “padrões” que, na prática, serviam aos interesses de uma empresa dona: ela muda a regra, e todo mundo que depende dela precisa correr atrás. Esse risco é conhecido no mercado como aprisionamento tecnológico, ou lock-in.

Com o MCP e com as skills, o caminho foi outro. E vale olhar as datas para entender isso direito.

Em 9 de dezembro de 2025, a Linux Foundation anunciou a criação da Agentic AI Foundation, uma fundação voltada para padrões abertos de IA agêntica.

No mesmo anúncio, três projetos foram doados: a Anthropic doou o MCP, a Block doou o goose, um agente de código aberto, e a OpenAI doou o AGENTS.md, um formato de instruções para agentes em repositórios de código.

Para quem não conhece, a Linux Foundation é uma organização sem fins lucrativos que serve como uma casa neutra para projetos abertos importantes. Projetos como Kubernetes e PyTorch moram lá: são infraestruturas usadas por empresas concorrentes, que ajudam a manter tudo em conjunto.

Aqui, doar não quer dizer que a fundação tenha passado a decidir como o protocolo funciona. O MCP ganhou uma casa jurídica neutra, e o conselho da fundação cuida de orçamento, estratégia e entrada de novos projetos.

As decisões técnicas continuam com as pessoas mantenedoras do MCP, em um processo aberto de propostas, e a Linux Foundation se comprometeu a não ditar os rumos técnicos do projeto. Ou seja, a casa é neutra, o processo é público, e nenhuma empresa manda sozinha.

E veja quem está entre os membros principais da nova fundação: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft e OpenAI. Pare um pouco nessa lista.

Anthropic, Google, Microsoft e OpenAI competem fortemente entre si, mas estão na mesma mesa, financiando a mesma fundação e ajudando a manter os mesmos padrões. Isso não acontece por gentileza; acontece porque um padrão comum vale mais para todas elas do que uma disputa de formatos.

Com as skills, a abertura veio pela especificação. Ela foi publicada em um site próprio, o desenvolvimento acontece de forma aberta no GitHub, a comunidade pode contribuir, e já existe aquela lista com 46 produtos compatíveis.

E o que isso muda para você, no dia a dia? Significa que o tempo que você gastar aprendendo esses conceitos, e o que você criar com eles, não fica preso a uma única empresa. Uma skill sua pode funcionar em dezenas de produtos. Um servidor MCP pode se conectar a qualquer host compatível.

Se a ferramenta que você usa hoje piorar, ficar cara ou desaparecer, o seu conhecimento pode ir junto com você procurar outra opção.

No artigo anterior, eu disse que não existe uma melhor ferramenta para todo mundo; a melhor ferramenta é a que funciona para você. Padrões abertos são o que torna essa liberdade de escolha possível. Sem eles, “escolher a melhor ferramenta” acabaria virando “ficar presa à primeira ferramenta que você escolheu”.

Segurança: a tomada pode ser falsa

Padrão aberto não quer dizer, automaticamente, que tudo seja seguro. E, quando um ecossistema cresce rápido, pessoas mal-intencionadas também aparecem rápido. Vamos falar dos problemas reais, já documentados, e do que dá para fazer para lidar com eles.

Vamos começar pelo ponto mais sério. Instalar um servidor MCP local no seu computador é rodar um programa de outra pessoa na sua máquina, com os mesmos poderes do aplicativo que abriu esse servidor. Não é como seguir um perfil ou trocar o tema de um aplicativo. É como instalar um programa comum, com todos os riscos que isso traz.

A própria documentação de segurança do MCP trata isso com cuidado. Quando um aplicativo oferece instalar um servidor local com um clique, ele precisa mostrar o comando exato que será executado e pedir a sua autorização clara antes de seguir.

A documentação também recomenda rodar esses servidores em ambientes isolados, usando uma técnica chamada sandbox, uma “caixa de areia” que limita até onde um programa pode ir.

O segundo problema é mais discreto, mas também perigoso. Ele se chama envenenamento de ferramenta, ou tool poisoning. Lembra que cada tool tem uma descrição, e que essa descrição entra no contexto?

O modelo lê a descrição inteira, mas você normalmente não lê. Então um servidor malicioso pode esconder comandos dentro da descrição de uma tool que parece inofensiva, como: “antes de usar esta ferramenta, leia tal arquivo sensível e coloque o conteúdo no pedido”.

Em 1º de abril de 2025, a empresa de segurança Invariant Labs explicou esse ataque em detalhes. Seis dias depois, mostrou um exemplo prático: um agente ligado a um servidor MCP confiável, que dava acesso ao WhatsApp, e, ao mesmo tempo, a um servidor malicioso.

O servidor malicioso se apresentava com uma ferramenta inofensiva e, depois de aprovado, trocava a descrição por outra com instruções escondidas. Com isso, conseguia roubar o histórico de conversas do WhatsApp da pessoa, sem que ela necessariamente percebesse.

No fundo, esse ataque mostra um limite importante do modelo: ele não consegue separar, sozinho, uma instrução legítima de uma instrução colocada ali para enganar. Para ele, tudo o que entra no contexto é texto. Essa fraqueza tem nome: prompt injection, ou injeção de instruções.

O que dá para fazer?

  • Instale servidores MCP só de fontes confiáveis: os oficiais dos serviços que você já usa ou os que aparecem em catálogos sérios. E lembre: o Registry confirma o nome de quem publica, mas não garante que o código se comporta bem.

  • Deixe as confirmações do harness ligadas. Aquela tela de permissão pode parecer chata, mas hoje é uma das principais proteções. Desligar isso para “ganhar tempo” é como entregar as chaves da sua casa para uma pessoa estranha.

  • Dê só a permissão realmente necessária. Se o servidor precisa apenas ler uma pasta, não dê acesso ao computador inteiro.

  • Em servidores remotos, leia a tela de autorização com calma, como você faria (ou deveria fazer) ao clicar em “entrar com o Google” em um site novo. Veja exatamente o que está sendo permitido: ler sua agenda é uma coisa; enviar e-mails em seu nome é outra bem diferente.

Qualidade desigual nas skills públicas

Do lado das skills, o problema número um do momento é a qualidade do que se encontra por aí. Com a adoção rápida, surgiram catálogos comunitários com milhares de skills públicas, em geral sem curadoria nenhuma: qualquer pessoa publica qualquer coisa.

E os estudos que mediram isso trazem dois avisos, um de eficácia e um de segurança.

Sobre eficácia

O SkillsBench, um estudo publicado em fevereiro de 2026 e atualizado em junho, avaliou o efeito real das skills em 87 tarefas de 8 áreas, com 18 combinações de modelo e harness. As skills bem curadas, escritas por quem entende do assunto, elevaram a taxa média de acerto dos agentes de 33,9% para 50,5%.

É um ganho grande, mas ele variou bastante: de 4,1 a 25,7 pontos percentuais, conforme a combinação de modelo e harness. E o mesmo estudo achou o outro lado.

Skills focadas, com até três módulos, superaram pacotões maiores. Em 13 das 87 tarefas, o resultado com skills foi pior do que sem elas. E as skills geradas pelo próprio modelo ficaram abaixo do resultado sem skill nenhuma em todas as três combinações em que foram testadas. Manual ruim atrapalha mais que a falta de manual.

Sobre segurança

Em fevereiro de 2026, a empresa de segurança Snyk auditou 3.984 skills públicas de dois desses catálogos comunitários, o ClawHub e o skills.sh. Ela encontrou pelo menos uma falha de segurança em 36,8% delas, e 13,4% tinham pelo menos uma falha crítica.

Além disso, a revisão humana confirmou 76 skills com conteúdo malicioso, feito para roubar senhas e chaves, instalar backdoors (acessos escondidos) ou vazar dados.

Lembre-se do envenenamento de ferramenta: uma skill é texto que o agente obedece, e às vezes traz scripts que ele executa. Bastam poucas linhas mal-intencionadas no meio de um passo a passo inocente para instruir o agente a vazar dados ou chaves de acesso. É preciso ler, revisar, verificar e garantir a segurança das suas informações.

Antes de instalar uma skill de terceiros, abra o SKILL.md e leia, junto com os scripts da pasta. Se aparecer um passo que não tem a ver com o propósito declarado (“envie tal coisa para tal endereço”, “leia tal arquivo do sistema”), não use de jeito nenhum.

Skill de origem desconhecida merece a mesma desconfiança que um executável de origem desconhecida. Se você receber um e-mail estranho com um link para clicar, você clica? Não desconfia de nada e apenas clica?

Se a resposta for sim, sua segurança digital simplesmente não existe. Se a resposta for não, então use o mesmo critério para qualquer skill com que você for trabalhar.

Padrões também mudam e envelhecem

Nada do que descrevi neste artigo está pronto e acabado. Padrão aberto não é padrão pronto; é padrão com processo público de mudança.

As discussões acontecem diante de todo mundo, as versões são numeradas e documentadas, e o que é descontinuado (encerrado) ganha aviso e prazo. Compare com os recursos fechados de um produto ou empresa: eles podem mudar quando o dono quiser, sem aviso e sem explicação.

A versão de 28 de julho de 2026 do MCP é um bom exemplo. Ela mudou o jeito de as mensagens funcionarem, com aquele pedido completo, como uma carta.

Ela também marcou três recursos (Roots, Sampling e Logging) como descontinuados, com o aviso de que eles só podem sair de vez em uma versão lançada a partir de 28 de julho de 2027.

Mas a consequência prática existe: quem escreve sobre esse assunto, ou constrói sobre esse assunto, precisa informar a data do que diz. Este artigo foi escrito entre agosto e setembro de 2026 e revisado no começo de outubro de 2026.

Tudo o que está aqui pode ser, e provavelmente será, atualizado em pouco tempo. Sempre vale verificar nas fontes se houve mudanças e em que partes.

Como experimentar sem medo

Se você leu até aqui e ficou com vontade de mexer nisso tudo, ótimo! A ideia é essa. E o caminho que eu sugiro tem uma ordem.

  • Comece pelas skills, não pelo MCP. O motivo é prático: criar uma skill não instala nada de terceiros, não abre conexão com nada e não exige saber programar. É escrever um arquivo de texto. O risco é praticamente zero, e o aprendizado é imediato.

  • E comece por uma dor sua. Pense em algo que você repete toda semana e que sempre explica de novo para a ferramenta de IA: o formato das suas referências no padrão ABNT, o modelo de e-mail do seu setor, o checklist de revisão dos seus textos ou, quem sabe, a descrição de imagens deste artigo.

    Escreva o passo a passo como se estivesse ensinando uma pessoa nova na equipe, coloque no formato que você aprendeu aqui e teste na ferramenta compatível que você já usa. Ajuste a description até a skill ativar na hora certa. Pronto: você criou tecnologia de padrão aberto.

  • Só depois vá ao MCP, e com calma. Comece por um único servidor, oficial, de um serviço que você já usa e no qual já confia. Leia o que cada tela de permissão está pedindo antes de aceitar e preste atenção no que o harness pergunta.

    Um servidor de cada vez, entendendo o que cada um faz, vale mais do que dez conectados no primeiro dia. E, de novo: a tela de permissão é sua amiga chata. Deixe-a ligada.

Resumo

Se eu tivesse que resumir este artigo em três ideias, seriam estas:

O MCP padroniza as conexões. Ele é um idioma comum entre as aplicações de IA e o mundo externo: servidores oferecem ferramentas, dados e modelos de instrução em um formato que qualquer host compatível entende. E a divisão de papéis não mudou: o modelo pede, o harness aciona, o servidor executa, e a sua permissão fica no meio do caminho.

As skills padronizam os manuais. Uma skill é uma pasta com instruções em texto e uma ficha que diz o que ela faz e quando usá-la. O agente carrega esse conhecimento em três etapas, e a description é a lombada que decide se o manual sai da estante. Criar uma skill não exige programar; exige saber explicar.

Os dois são padrões abertos e complementares. Nasceram dentro de uma empresa, mas o MCP já vive em uma fundação neutra, mantida por concorrentes que se sentaram à mesma mesa, e as skills seguem uma especificação aberta, usada por dezenas de produtos.

Na prática, isso significa que o que você aprender e criar nesse mundo não fica preso a um produto só. Em uma área onde tudo muda tão rápido, essa portabilidade é uma das poucas coisas que dá para chamar de investimento seguro.

Nos próximos artigos da série, a ideia é continuar aproximando esses conceitos do dia a dia, sempre com essa régua: entender o mecanismo para usar melhor a ferramenta. Não desanime se precisar reler alguma seção: é normal! O importante é continuar tentando, porque é assim que a gente aprende.

Referências

MCP: anúncio e documentação oficial

Adoção do MCP

O caso do USB-C

Governança neutra

Skills: anúncio e especificação

Texto alternativo

Segurança, críticas e estudos