As skills dos agentes vão para uma biblioteca compartilhada via MCP. O hash prova o arquivo, não o conselho

Onde uma skill deveria morar?

Para a maioria dos times enterprise, a resposta honesta hoje é “em vários lugares”. Uma skill, o pacote de instruções e arquivos de referência que ensina um agente a fazer uma tarefa do jeito da empresa, nasce na pasta de um agente. Funciona. Outro time copia. Seis meses depois há cinco versões, cada uma um pouco diferente, e ninguém sabe qual o agente de sinistros está usando.

Dois lançamentos de 12 de outubro apontam para outro arranjo.

Um padrão, um preview e um beta

A Microsoft publicou um guia técnico sobre a Skills extension do MCP, identificada como io.modelcontextprotocol/skills. A proposta, SEP-2640, chegou ao status Final. A extensão permite que um servidor declare que oferece skills, liste-as com skills/list e publique um manifesto para cada uma: endereço, tamanho e digest SHA-256 de cada arquivo. O host, ou seja, a aplicação que roda o agente, lê as instruções e os arquivos de apoio só quando precisa e confere cada um contra o manifesto antes de usá-lo.

O Microsoft Foundry oferece skills em preview. Os times fazem upload de uma skill para criar uma versão fixa e depois a referenciam num toolbox que expõe ferramentas e skills por um único endpoint MCP. Um toolbox pode fixar uma versão da skill ou seguir a padrão. O preview não tem SLA e a Microsoft não o recomenda para produção.

No mesmo dia, a Databricks lançou em beta uma Skills API no Unity Gateway, com operações para criar, ler, atualizar, listar, excluir e finalizar skills pela CLI e pelos SDKs.

O que a extensão garante e o que deixa com você

A parte útil do texto da Microsoft é o cuidado em separar o que o protocolo verifica do que ele não tem como verificar.

Quem responde a cada pergunta sobre uma skill compartilhada

O servidor e o protocolo

• Quais skills existem
• Bytes exatos de cada arquivo, por tamanho e digest
• Qual versão é servida
• De qual servidor veio

Integridade e procedência

O host e a empresa

• Se o conselho está certo
• Se pode ser carregada
• Se scripts podem rodar
• Quais ferramentas o agente pode chamar

Confiança, aprovação e permissão

A especificação é rígida do lado do host. Ele precisa saber qual servidor forneceu cada skill, porque dois servidores podem oferecer skills com o mesmo nome e elas “não podem se substituir em silêncio”. Precisa rejeitar um arquivo cujo tamanho ou digest não bata mais. A aprovação salva fica atrelada às impressões digitais dos arquivos, então, se um manifesto atualizado muda, acrescenta ou remove um arquivo, “essa aprovação é revogada e o host precisa perguntar de novo”. Ler um script não dá permissão para executá-lo; a execução no host exige aprovação explícita do usuário. E se as instruções de uma skill mandam o agente usar outra ferramenta, “esse pedido não é permissão para usá-la”.

Depois vem o limite, dito com clareza: “Essas verificações dizem que o conteúdo corresponde ao que o servidor ofereceu. Não dizem se o conteúdo é seguro ou se as instruções são boas.”

Por que uma biblioteca compartilhada muda o risco

Centralizar skills resolve a divergência entre cópias, e isso é um ganho real. Também concentra influência. Uma skill que ensina um agente de compras a avaliar fornecedores, servida de uma biblioteca para quarenta agentes, passa a ser um procedimento com quarenta executores. Se estiver errada, ou for editada sem alarde, o erro se espalha na velocidade da próxima atualização de cache.

Isso transforma a biblioteca de skills num repositório de documentos controlados, quer alguém chame assim ou não:

• Autoria e revisão. Quem pode publicar uma nova versão de skill, e quem precisa aprová-la? Procedimentos regulados já têm donos; skills que os codificam precisam dos mesmos.
• Fixação por risco. Agentes que fazem trabalho com consequência devem fixar uma versão revisada. Seguir “a padrão” serve para skills de baixo risco e é perigoso para qualquer coisa sobre a qual um auditor perguntaria.
• Conteúdo dinâmico. Servidores podem marcar skills geradas como dinâmicas quando não há impressões digitais estáveis. Hosts podem recusá-las; para trabalho com consequência, deveriam.
• Portabilidade. Skills guardadas no runtime de um fornecedor fazem parte do custo de troca que descrevemos em memória e skills de agentes como o novo lock-in. Um padrão só reduz esse custo se o seu próprio repositório continuar sendo a fonte e a biblioteca do fornecedor um espelho.

Confira o cliente antes de planejar

Os testes da Microsoft são um bom alerta sobre maturidade. O endpoint do Foundry negociou uma revisão mais antiga do protocolo (2025-11-25), aceitou skills/list nela e rejeitou como não suportada uma requisição na revisão mais recente. “Conseguir chamar uma ferramenta MCP não basta para descobrir e carregar skills remotas.” Antes de desenhar em cima de skills compartilhadas, confira a matriz de suporte da extensão para cada host onde seus agentes rodam.

O MCP padronizou como os agentes chegam às ferramentas sem governá-las, a lacuna que descrevemos em o MCP conecta, mas não governa. As skills seguem o mesmo caminho. O protocolo agora entrega instruções com integridade. Decidir quais instruções merecem ser entregues continua sendo trabalho da empresa.