A chegada da Web 2.0 2.0: MCP
(anildash.com)- Model Context Protocol (MCP) é uma especificação criada pela Anthropic para conectar LLMs a apps e sistemas externos, e passou a se espalhar como uma interface comum entre várias plataformas depois que a OpenAI passou a oferecer suporte no ChatGPT
- Mesmo que a especificação seja frouxa e incompleta, se vários participantes adotarem rapidamente a mesma forma de fazer as coisas, protocolos abertos podem ganhar força na web real
- O valor original da Web 2.0 estava mais próximo de um ecossistema de desenvolvedores e usuários criado por APIs abertas e ferramentas interoperáveis do que por sites sociais fechados
- A expectativa de interoperabilidade enfraquecida quando grandes plataformas como Facebook e Twitter fecharam suas APIs pode ser revivida pelo MCP como uma plataforma programável, no fluxo das ferramentas de código com IA
- MCP não é uma solução mágica e também traz grande falta de transparência no tratamento de dados e riscos de segurança, mas pode se tornar um novo ponto de partida para exigir conformidade com padrões e transparência
O contexto por trás da disseminação do MCP como padrão
- Model Context Protocol, ou MCP, é uma especificação projetada pela Anthropic para o Claude
- Seu objetivo é permitir que LLMs peçam informações a vários apps ou interajam com outros sistemas
- Quando a OpenAI passou a oferecer suporte ao mesmo protocolo no ChatGPT alguns meses atrás, o MCP começou a se consolidar como um padrão adotado em vários lugares
- O MCP também foi incluído no Windows, mostrando o alcance dessa expansão
- O ponto importante não é o grau de completude da especificação, mas o fato de vários players terem adotado rapidamente a mesma interface
- O MCP está mais próximo de uma especificação frouxa, mas se parece com a forma como a web teve sucesso por ser aberto e funcional
O que a Web 2.0 originalmente queria dizer
- Web 2.0 não era um termo para sites fechados e proprietários como o Facebook
- No centro da comunidade inicial da Web 2.0 havia um movimento em que vários sites ofereciam APIs abertas, permitindo que desenvolvedores e usuários conectassem pessoas e dados
- Flickr, Del.icio.us e Upcoming eram sites representativos de uma era que abriu caminho para recursos como tags e compartilhamento social
- Plataformas como LiveJournal e Movable Type também influenciaram o trabalho em padrões abertos em torno de APIs e protocolos
- Os valores compartilhados daquela época eram relativamente claros
- construir ferramentas, tecnologias e plataformas sobre dados abertos e protocolos abertos
- os usuários mantêm o controle
- desenvolvedores interagem com sistemas por meio de ferramentas consistentes e interoperáveis
Como as plataformas fechadas romperam a interoperabilidade
- Ao longo de uma geração, ficou mais difícil para desenvolvedores considerar natural a expectativa de interoperabilidade entre apps e plataformas
- Isso também veio acompanhado de críticas de que grandes VCs e líderes da indústria de tecnologia encerraram a era da abertura
- Ferramentas que analisavam atividade em redes sociais viram produtos e serviços voltados a usuários serem interrompidos quando grandes plataformas sociais fecharam suas APIs
- Plataformas como Facebook e Twitter frustraram, para muita gente, a promessa da Web 2.0 de dados abertos e tecnologia interoperável
- Como resultado, tornou-se comum uma situação em que usuários têm dificuldade para lidar com suas próprias redes da forma que desejam
- não é possível ver fotos do Instagram incorporadas na timeline do Twitter
- é difícil usar recursos como importar e exportar seguidores, possíveis no fediverso ou no Bluesky
- é difícil controlar sua própria rede com o app de sua preferência
As possibilidades que o MCP pode reabrir
- A ascensão do MCP, combinada com a popularidade da IA entre programadores, cria a expectativa de que plataformas possam se abrir não só para LLMs, mas também para diversos objetivos de programação
- O ponto central é que outras plataformas adotaram sem mudanças a especificação criada pela Anthropic
- Quando uma empresa adota fielmente em segundo lugar o protocolo de outra, todo o ecossistema pode funcionar mais facilmente da mesma forma
- Em contrapartida, copiar um protocolo, expandi-lo e depois eliminá-lo pode prejudicar o ecossistema
- Quando existe uma adoção de boa-fé da mesma interface, cresce o espaço para que várias ferramentas e plataformas funcionem juntas
A dificuldade de seguir um padrão como ele é
- Dar suporte a um padrão exatamente como ele é mais difícil do que parece
- Mesmo ao lançar um produto de cache semântico para plataformas de IA, não foi fácil convencer desenvolvedores a usar a API padrão do ChatGPT sem modificações
- É fácil para desenvolvedores pensar “dá para melhorar”, mas no momento em que se afasta do padrão, o resultado pode acabar sendo pior
- Mesmo uma especificação ruim e cheia de inconsistências pode ser mais valiosa se todos a implementarem da mesma forma
- O HTML também era uma especificação incompleta, com muitas lacunas, mas a web foi construída sobre ela
- A internet como um todo também se apoia em várias especificações imperfeitas
Exigir conformidade com padrões e transparência
- Uma nova geração de desenvolvedores está vivendo a criatividade e as possibilidades que surgem quando as ferramentas e plataformas de que gostam usam os mesmos protocolos e formatos
- Movimentos como RSS, podcasting, OpenID, OAuth e OpenSocial levaram, em parte, a resultados posteriores como o fediverso e o ActivityPub
- Desenvolvedores, programadores, entusiastas de tecnologia e também usuários comuns podem exigir das plataformas o direito de acessar e controlar suas experiências por meio de código
- Ao adotar padrões abertos como o MCP, também é preciso exigir transparência sobre o que as plataformas realmente fazem
- O MCP é flexível, mas deixa vários riscos em aberto
- não há transparência sobre como as plataformas lidam com os dados dos usuários
- é difícil saber quais ações podem ocorrer em interações via MCP
- os riscos de segurança são muito altos
- o protocolo não trata suficientemente dessas preocupações
Os limites e as expectativas da abertura no estilo Web 2.0
- MCP não é uma solução mágica capaz de corrigir todos os problemas do ecossistema de desenvolvedores
- Também não corrige os exageros nem as distorções do debate em torno da IA
- Ainda assim, há a possibilidade de que desenvolvedores mais jovens, que não viveram a geração anterior da Web 2.0, usem o MCP como ponto de partida para aproximar a web de sua arquitetura original
- A web não foi pensada para ser uma estrutura proprietária ou controlada por algumas poucas pessoas de grandes empresas
- A web deveria ser programável por meio de especificações ásperas que todos adotavam às pressas, e essa diversão hackeável já existia antes mesmo de a web ganhar números de versão
1 comentários
Opiniões no Hacker News
O que muita gente não percebe sobre o MCP é que ele combina bem com software corporativo
LLMs são tradutores de uso geral, então servem bem como cola para conectar sistemas isolados que seriam extremamente difíceis de integrar sem alguma camada intermediária relativamente flexível
Por isso o setor de SaaS B2B está lançando servidores MCP e, internamente, discutindo como redesenhar APIs e suas limitações para os novos padrões de uso
O protocolo não é “pronto para enterprise” em várias definições, mas, como o autor diz, isso não importa tanto. Olhando a história dos padrões, coisas bagunçadas e “ruins” também acabam sendo amplamente adotadas quando se encaixam nas pessoas certas no momento certo
Há menos discussões sobre se alterar um campo de um objeto de usuário é um PUT que substitui o objeto de usuário original ou um POST. Já perdi bastante tempo com verbos REST
O LLM também não precisa entender a semântica REST da API. Ele olha os métodos RPC disponíveis e faz a chamada que parece funcionar. Acho que o ponto central é realmente só isso
Não é como se endpoints negociassem entre si um schema para consultas baratas no futuro
Só isso já permite recursos como autodescoberta
Qualquer lugar que ofereça MCP provavelmente vai oferecer também uma API decente de qualquer forma
Que empresa não gostaria de extrair o máximo de produtividade dos funcionários durante o horário de trabalho?
A parte “comparado aos tempos em que velhos senhores rabugentos do Unix escreviam especificações” me parece uma das várias razões pelas quais a Web Semântica fracassou. Isso também não contradiz a tese do autor de que “pior é melhor”
Acho que as pessoas se empolgaram demais com o “eXtensible” do XML e acumularam certo cansaço. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS etc. ficaram demais
O que o mundo precisava na época era um formato simples de intercâmbio, e JSON atendia a essa necessidade, enquanto o lado do XML parecia quase uma arquitetura espacial para formatos de dados
Mas também acredito que agora chegou a vez do XML. Em prompts de sistema vazados de lugares como a Anthropic, XML aparece com frequência. LLMs parecem lidar muito bem com formatos de texto estruturado, especialmente Markdown e XML
Ainda assim, acho que o MCP é o modelo errado. Em vez de instruir o modelo a “puxar” contexto diretamente, acho que nós deveríamos “empurrar” contexto para o modelo
As quatro tags de macro (
#=,#&,#?,#!) se substituíam pelo resultado da própria expansão de macro, respectivamente como atribuição, substituição, ramificação condicional tipoconde chamada de função definida pelo usuário; no fim, percebi que estava recriando XSLTO que eu realmente queria era XPath. É uma forma de descrever como percorrer um grafo para frente e para trás ao longo de vários eixos e, de fato, é uma excelente especificação
Então encontrei o BaseX https://basex.org/, que permite importar documentos XML arbitrários para um banco de dados consultável e consultá-los com XPath ou XQuery
Para criar uma interface confiável de dataset em linguagem natural, sem alucinações, o melhor caminho parece ser passar o schema XML no prompt de sistema e fazer o modelo escrever consultas para buscar os dados
Se você já soubesse a informação de antemão, provavelmente teria resolvido o problema diretamente
O valor obtido com o MCP parece mais próximo de “não me faça aprender a conectar 15 fontes; execute alguma consulta por mim”
Ninguém™ alimenta um LLM com XML propriamente dito começando por uma declaração XML, nem usa namespaces, XSLT, XML Schema ou coisas do tipo
É mais como uma coleção arbitrária de tags no estilo SGML
XML é uma especificação grande que vai muito além de colchetes angulares, e tenta cobrir todos os casos e lidar corretamente com segurança e codificação de caracteres
Por isso, “editar como texto simples” não é muito intuitivo. Se você digitar algo como este parágrafo, ele pode até ser parseado em modo de compatibilidade, mas talvez não seja válido
Como formato de intercâmbio, ou como formato carregado em aplicações feitas para ele, tem mais potencial; e LLMs certamente não teriam dificuldade para entendê-lo, então isso é bom
Muitos problemas do passado vieram de programadores sem tempo e querendo encaixar recursos rapidamente, usando uma especificação fortemente estruturada como um porrete. Quando três programas diferentes e três autores repetem “XML? É só usar regex”, vira uma bagunça
Pessoalmente, o formato que mais se aproximava do que eu queria de verdade era BBCode. Ele é ótimo como formato-fonte para muitas coisas. Basicamente ainda é da família dos colchetes angulares, mas tem estrutura e flexibilidade suficientes para funcionar bem como sintaxe de frontend de uso geral
As implementações iniciais eram “é só usar regex”, mas, depois de décadas de validação em uso real, hoje também existem parsers mais elegantes
Penso o contrário da frase: “A ascensão do MCP dá esperança de que, à medida que a IA ganha popularidade entre programadores, os LLMs possam abrir outras plataformas para que sejam programáveis para qualquer finalidade, e não apenas para serem controladas por eles”
O MCP está fadado a fracassar pelo mesmo motivo que a web semântica fracassou. Porque, se algo não está trancado, ninguém ganha dinheiro com isso
Fico imaginando quanto daquilo que chamamos, desculpem, de “deep-research”, em que a IA pesquisa a web por nós, poderia ter sido resolvido de uma forma melhor
Restaurantes poderiam ter publicado seus cardápios em formato de metadados, e qualquer um poderia encontrar o taco mais barato do Texas com um script Python; mas, na prática, com uma mão trancamos dados atrás de barreiras artificiais e, com a outra, criamos IA, incluindo data centers, para contornar isso. Em escala macro, é simplesmente uma burrice
A onda anterior de agentes morreu porque, no fim, todos perceberam que não dava para confiar no próprio código rodando em uma máquina em que tudo é objeto de negociação. Foi aquela história do Java nos anos 90
Fundamentalmente, entre agentes que interagem há um problema de assimetria de informação projetado de propósito. Se você eliminar isso, grande parte da sociedade deixa de funcionar
Por mais recursos que você jogue no problema, alguém vai encontrar um jeito de esgotá-los em troca de um ganho minúsculo
O MCP só piora o problema, com agentes de IA se lançando sobre servidores MCP públicos como uma nuvem de gafanhotos
A opção estável parece ser precificação de RPC por chamada. Pelo menos a entidade que opera o modelo ou o agente serviria como câmara de compensação de pagamentos, então há mais chance do que na época das APIs da Web 2.0
Provavelmente o modelo de cobrança mais plausível é embutir esses custos em planos de assinatura. Parece ser a melhor forma de alinhar incentivos
Para começo de conversa, quem deu o nome HATEOAS já deixou tudo preparado para fracassar
Se houvesse valor “fácil” em expor dados em um formato padrão, endpoints interoperáveis teriam sido adotados em escala muito maior
Por exemplo, usando schema.org ou alguma ontologia comum geral. Mas a realidade é cheia de formatos sob medida que, a cada vez, exigem um SDK mágico especial
Exigir que restaurantes publiquem cardápios em formato de metadados é que é uma barreira artificial
A beleza das novas ferramentas de processamento de linguagem natural está nisso. O dono do restaurante não precisa aprender JSON nem comprar um pacote de software que gere JSON
Podemos usar os dados como eles são. O custo de criar ferramentas úteis se aproxima de zero
Vai ser impreciso, mas a linguagem humana já é assim mesmo
Tenho pena de quem acha que, só porque existe MCP, vai conseguir acessar qualquer coisa
Essas coisas ficarão escondidas atrás de dezenas de camadas de verificação de pagamento e autenticação. Claro que também haverá IPs em lista de permissão, e obviamente serão IPv4
O que vocês verão provavelmente será apenas
ERR 402;O que mais me preocupa no MCP não é tanto o fato de o protocolo ser malfeito, mas o fato de corrigir e melhorar isso depender apenas de equipes internas da Anthropic e da OpenAI
As pessoas que criam o protocolo não parecem engenheiros que também o implementam de fato
Isso me lembra vagamente um oligopólio tipo Visa-Mastercard
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
Agora que LLMs conseguem ler documentação de API e se adaptar, talvez seguir uma API padrão seja menos necessário do que antes
Para mim, a vantagem importante é criar a expectativa de que um site “tenha” uma API, independentemente de ele seguir ou não a especificação MCP
Mesmo com boa documentação, um LLM pode gerar código incorreto para interagir com a API. Se você corrigir o código gerado e fizer o LLM chamar esse código para interagir com a API, de qualquer forma já entrou no caminho de uma camada intermediária. Na prática, está criando um servidor “tipo MCP”
Também há questões de segurança e alocação de recursos ao dar acesso direto de API a um LLM. O LLM tem conhecimento limitado de quando a API foi chamada pela última vez. Ele pode chamar com frequência excessiva e, se o custo por chamada for alto, gerar uma conta de infraestrutura inesperada
Além disso, há muitos outros pontos potenciais de dor que são resolvidos colocando alguma coisa no meio
Se essa “coisa” precisa ser MCP, pessoas razoáveis podem discordar. Por enquanto, parece funcionar bem o suficiente para dar conta do que as pessoas precisam fazer
Agora podemos construir a web semântica. Basta criar um pequeno protocolo para que organizações compartilhem DDL SQL
CREATE TABLEem arquivos estáticos que apps MCP consigam ler. Isso bastaria como uma extensão opcional do MCPEntão, usando ferramentas já existentes que conectam chamadas de função de IA/LLM a SQL, seria possível entender e consultar os dados; isso seria a web semântica
Essa abordagem preenche o elo perdido que sempre bloqueou a web semântica: a falta de incentivo para fazer empresas usarem “tipos de dados” padrão em vez de tipos de dados proprietários
Com MCPQ, ou seja, MCP com consultas, de repente as organizações teriam motivo para colaborar na camada de estrutura dos dados
No fim das contas, a “web semântica” foi o tempo todo uma web sintática, e talvez agora seja de verdade
Fico curioso para saber quanto tempo vai levar até alguém criar um servidor MCP que controle algo como baratas
Material de referência:
https://www.technologynetworks.com/informatics/news/robo-roa...
https://www.sciencealert.com/scientists-turned-cockroaches-i...
E há muitos outros exemplos que remontam a mais de 10 anos atrás
Achei bem engraçada a expressão “na época em que as especificações eram escritas por velhos tiozões Unix exigentes”
É interessante que esta geração imagine os “velhos tiozões Unix” como pessoas exigentes. O Unix foi a rebelião definitiva do mover rápido e quebrar coisas contra a escola do MIT, afinal
Algumas coisas parecem não mudar :-)