Especificação MCP – mudanças na versão de 2025-06-18

• A nova atualização da especificação MCP coloca foco em metadados estruturados e gerenciamento de contexto. O objetivo é melhorar a expansibilidade e reforçar a interoperabilidade entre diversos sistemas
• Novos campos de dados foram adicionados, e os campos obrigatórios existentes passaram a ser definidos de forma mais específica. A hierarquização da estrutura de metadados permite oferecer suporte a métodos de extensão separados para cada sistema
• São apresentadas regras claras para rastreamento de contexto e atualização de atributos, com ênfase em uma gestão de informações de estado mais consistente do que antes
• Procedimentos de gerenciamento de permissões e validação de dados foram explicitados na especificação do protocolo. Alguns campos recém-adicionados foram pensados levando em conta a compatibilidade com versões futuras do protocolo
• Suporte à integração multiplataforma: fornece a base para trocar dados de contexto de maneira consistente entre várias plataformas de IA e ambientes de serviços em nuvem

---

• MCP(Model Context Protocol) é um protocolo para troca de metadados de contexto entre diversos sistemas de IA, como modelos de machine learning ou grandes modelos de linguagem

Major changes

1. Remoção do suporte a batching do JSON-RPC (PR #416)
2. Adição de suporte a structured tool output (PR #371)
3. Classificação de servidores MCP como servidores de recursos OAuth, com adição de metadados de recursos protegidos para facilitar a localização do servidor de Authorization vinculado (PR #338)
4. Clientes MCP agora devem implementar o Resource Indicator da RFC 8707 (para evitar que servidores maliciosos obtenham access tokens) (PR #734)
5. Esclarecimento das considerações de segurança e das melhores práticas na especificação de Authorization, com adição de uma página separada de guia de segurança
6. Adição do recurso Elicitation (solicitação de consulta), permitindo que o servidor peça informações adicionais ao usuário (PR #382)
7. Adição de suporte a Resource Links, permitindo incluir links de recurso no resultado de chamadas de ferramentas (PR #603)
8. Durante a negociação da versão do protocolo, o cabeçalho MCP-Protocol-Version passa a ser obrigatório em HTTP (PR #548)
9. Mudança de SHOULD para MUST em Lifecycle Operation (referência)

---

Other schema changes

1. O campo _meta foi adicionado a mais tipos de interface (PR #710), com orientações de uso apropriado
2. Adição do campo context em CompletionRequest, permitindo incluir variáveis interpretadas anteriormente (PR #598)
3. Adição do campo title para exibição amigável ao usuário, separado do identificador para programas (name é usado como identificador de código, e title para exibição) (PR #663)

[kernel00]

Os comentários no Hacker News ficaram meio decepcionantes. Acho que só olharam para stdio, mas agora estão surgindo aos montes servidores MCP remotos e registries que fazem a mediação disso...

[GN⁺]

Opiniões no Hacker News

• A principal coisa que aprendi com o boom do MCP (Machine Context Protocol) é que, no desenvolvimento de software de backend, na verdade não há muita necessidade de usar MCP. Há partes em que ele não se encaixa bem arquiteturalmente. Especialmente em ambientes como Elixir, isso parece ainda mais verdadeiro. Se você colocar um servidor separado para cada API, isso significa rodar 500 microsserviços para 500 APIs. Só percebi isso depois de usar uns 20 servidores MCP diferentes: no fim, MCP também era só um invólucro para chamada de função. Cada API já pode ser feita como um módulo separado, sem precisar virar um servidor. Não há motivo para ficar correndo atrás da especificação mais recente do MCP nem para atualizar centenas de microsserviços toda vez que a especificação mudar. No fim das contas, é só complexidade desnecessária
  • A menos que o cliente se conecte diretamente a cada microsserviço sem passar por um gateway ou BFF, basta colocar o MCP na frente do serviço inteiro e expor as funções como já se faz com API, GraphQL, RPC etc. Na prática, ele parece uma interface especializada para LLM. Também dá para usar tool call com base em especificação OpenAPI sem problema. De qualquer forma, imaginar que todos os microsserviços vão se comunicar apenas via MCP é exagero demais
  • Eu sempre vi o MCP só como uma solução de integração em estilo plugin que permite function call sem custo de API, como no Claude. Se você já usa API e não está com urgência, não é uma opção da qual realmente precise
  • Na verdade, acho que o MCP é um protocolo padrão que conecta cliente e modelo. Não é apenas um recipiente que embrulha chamadas de ferramenta
  • Isso mesmo, um servidor MCP por API não escala. Usando algo como nango.dev, um único servidor pode cobrir mais de 400 APIs. Ele também oferece tratamento de autenticação, visibilidade e várias interfaces para fazer tool call diretamente. (Aliás, eu sou o fundador)
  • Eu iria além e diria que a própria cultura de forçar o LLM a produzir JSON é tola. Gasta-se tempo e esforço demais para encaixar o modelo num formato rigoroso de que ele nem gosta naturalmente. Um DSL textual muito mais restritivo acabou sendo uma alternativa bem melhor. Na época do GPT 3.5, bastava colocar alguns exemplos simples no prompt para obter saída confiável num DSL em inglês. Mas ainda fica o aviso de que até modelos recentes às vezes ignoram partes de um JSON schema. Parece tentar enfiar um pino redondo num buraco quadrado; queria que as pessoas parassem de forçar isso
• Estou realmente muito feliz que agora exista um caminho simples para servidores MCP autenticados. Quero expressar meu agradecimento sincero à comunidade MCP e à equipe da Anthropic
  • Não entendo muito bem por que um servidor MCP seria necessário. Se o agente quer fazer RPC, não bastaria simplesmente usar RPC?
• Acho realmente curioso que a especificação principal tenha sido escrita em TypeScript em vez de OpenAPI ou outra coisa. Deve haver uma boa razão, mas ainda assim parece algo inesperado
  • Fiquei curioso sobre por que isso é surpreendente. Eu também uso muito TypeScript, mas nunca tinha pensado por esse ângulo, então queria entender que tipo de decisão houve do ponto de vista de design de linguagem
• Fiquei muito feliz com a introdução do desafio WWW-Authenticate. Agora ficou mais claro o fluxo em que o servidor MCP encaminha o cliente para o OAuth do provedor de recursos e só precisa receber o cabeçalho Authorization: Bearer ...
• Acho que <i>a maior parte</i> disso realmente é complexidade desnecessária, mas sinto falta da execução em lote. Foi divertido implementar algo como “faça todas essas tarefas e depois responda tudo de uma vez”. Claro, o cliente pode agrupar respostas em lote por conta própria, mas ainda assim era divertido
  • Concordo. O recurso de batch do JSON-RPC realmente me deu aquela sensação de “uau, isso é interessante”. É uma pena sair da especificação, mas entendo, porque no fim também adiciona complexidade
• Acho que o elicitation (tratamento de prompt baseado em inferência) foi um grande ganho. Um dos meus servidores MCP favoritos é um servidor SSH que eu mesmo fiz. Dá para automatizar 90% do trabalho de administração de servidores. Eu gerencio a autenticação com um arquivo de configuração, mas fica um pouco incômodo ter que editá-lo manualmente sempre que preciso me conectar a um novo servidor
  • Nesses casos, também daria para usar algo como fabfile.org. Se for uma conversa em que não há necessidade de introduzir LLM, acho melhor manter isso no âmbito privado
• Nos últimos dias, brinquei de criar um wrapper de dataset com MCP

1. Acho que é uma das tentativas mais empolgantes no campo de LLM. Claro, daria para fazer algo parecido com API e tool call tradicionais, mas foi muito impressionante poder simplesmente mandar a um amigo que não domina tecnologia uma URL de MCP para Claude e vê-lo usar com alguns cliques
2. Estou usando o SDK de csharp, mas a parte de autenticação ainda só existe em uma branch, então está num estágio bem inicial. Em 95% do tempo de integração com MCP, eu fiquei preso implementando autenticação (o que é obrigatório se não for build local). Isso deve melhorar quando sair mais documentação, mas por enquanto é um processo bem trabalhoso
3. Outro ponto é a falta de logs visíveis para desenvolvedor. Eu gostaria que o Claude, na web (não no desktop), mostrasse no modo desenvolvedor os logs de request/response do que está sendo trocado e onde ocorre o erro. Passei um tempão sofrendo com problema de renovação de autenticação e só depois percebi que eu estava registrando o endpoint errado. Se houvesse logs melhores de MCP, isso teria sido resolvido em minutos. No desktop e no MCP inspector funciona bem
4. Minha maior preocupação é o tratamento de tarefas longas. O dataset que exponho consiste em vários documentos PDF. O próprio Claude aparentemente não consegue lidar com PDFs (se alguém souber uma forma, adoraria saber!), então por enquanto passo primeiro pelo gemini para converter em texto e depois entrego via MCP. Documentos simples funcionam bem, mas os longos demoram muito. No momento, só envio uma mensagem dizendo “está processando, tente de novo depois”. Existe uma API de progresso, mas como é preciso manter a conexão com o servidor continuamente (e no Cloudflare ela cai depois de um tempo), isso parece ter limitações práticas. Seria ótimo se houvesse uma forma de fazer o LLM verificar novamente após x segundos e, até lá, tocar outras tarefas, ficando em um estado de “execução temporariamente suspensa” até o temporizador acabar. Do jeito que está, ou o LLM fica parado sem poder fazer nada enquanto mantém a conexão, ou então eu retorno um job ID e ele acaba dando uma resposta incompleta, muitas vezes sem o contexto todo. Para tarefas que levam mais de 10 minutos, isso pode ser um grande obstáculo

• Tarefas de longa duração ainda são um tema em discussão pública. Pelo que sei, o MCP pretende resolver isso no futuro. Há várias propostas circulando, e como nem sempre dá para saber se um trabalho vai demorar muito, separar apenas uma API para tarefas longas não resolve sozinho. Eu também tenho uma proposta para tratar isso de forma integrada link da discussão
• É muito bom ver a especificação do MCP melhorando rapidamente. A cada novo release, dá para ver que algum ponto que eu sentia falta na integração com MCP está sendo preenchido
• Acho engraçado que basta uma única aprovação para que uma mudança na especificação seja incorporada
• Não entendo muito bem o que o MCP realmente resolve. Pessoalmente, só consigo imaginar algum papel quando estou prototipando rapidamente algo no notebook. Se eu estivesse criando um programa local, gostaria de controlar com muito mais precisão o conjunto de ferramentas a que o LLM pode acessar. Mesmo pensando num servidor MCP para Google Calendar, o MCP não me poupa tanto tempo assim. Eu mesmo posso usar a mesma API diretamente e ainda preciso dizer explicitamente ao LLM quando e como chamar o Google Calendar, então não quero delegar isso a terceiros. Também me incomoda subir processos arbitrários no meu ambiente sem saber os detalhes de implementação, independentemente da linguagem em que o MCP foi escrito. Se do meu lado tudo é Python, pode ser complicado exigir do usuário também um runtime de TypeScript. Se surgir uma vulnerabilidade no wrapper MCP, isso também vira preocupação de segurança. Em ambiente de servidor, é ainda mais difícil justificar. Para chamar algo entre máquinas diferentes sem conhecer os detalhes de implementação, RPC já é um método excelente. O MCP me parece só acrescentar middleware opinativo e problemas de segurança por cima disso
  • O que eu não entendo é por que todos os MCPs que vi até agora são baseados em comando e não usam interface HTTP. Se fosse por HTTP, daria para subir um único servidor e compartilhá-lo com a organização inteira, sem que cada pessoa precise configurar sua própria toolchain
  • Diferentemente da abordagem tradicional, em que o backend impõe um fluxo fixo, a vantagem do MCP é que o próprio LLM faz a orquestração diretamente. Por exemplo, numa busca na web, ele pode reformular a consulta e tentar de novo até encontrar a informação desejada. Ao resolver um problema específico via CLI, também consegue usar várias ferramentas na ordem apropriada. Esse tipo de organização não é possível com fluxos fixos
  • O que o MCP resolve é padronizar, a partir do centro no LLM, a conexão do agente com várias capacidades como tools por meio de um protocolo padronizado
  • Também concordo bastante com isso. Quando você usa na prática, ele parece bem lento. Eu larguei meu emprego há 2 anos para desenvolver um cliente de LLM e até hoje não consegui integrar Google Calendar. Ainda assim, do ponto de vista do usuário, a utilidade do MCP é justamente tapar esse tipo de buraco temporário. Lembro daquela história de que as três primeiras linhas da tela inicial do iPhone eram parecidas para todo mundo, mas a última linha era totalmente diferente de pessoa para pessoa. Tenho a impressão de que, daqui para frente, equipes de TI e times de desenvolvimento vão continuar criando seus próprios servidores MCP conforme as necessidades do trabalho de cada um