A chegada da Web 2.0 2.0: MCP

• Model Context Protocol (MCP) está sendo adotado rapidamente e emergindo como um novo padrão aberto
• O valor central do MCP não está na perfeição, mas na abertura e interoperabilidade
• O verdadeiro significado da Web 2.0 não são plataformas fechadas, mas APIs abertas e compartilhamento de dados
• Está surgindo um movimento de retorno da era do fechamento para os valores da web aberta
• A adoção do MCP pode levar desenvolvedores a exigir ainda mais controle sobre plataformas e transparência

---

MCP: o surgimento de uma nova web aberta

Nos últimos meses, o interesse em Model Context Protocol (MCP) explodiu entre desenvolvedores. O ponto de partida foi a Anthropic, que em 2023 o projetou para que seu sistema de LLM (Claude) pudesse interagir com diversos aplicativos. Depois disso, a OpenAI passou a oferecer suporte ao mesmo protocolo no ChatGPT, e ele rapidamente se consolidou como padrão. Agora, está se expandindo para grandes plataformas, inclusive sendo adotado no Windows.

O ponto interessante está menos na clareza ou no grau de acabamento do próprio MCP e mais na praticidade e rapidez de uso. Diferentemente de padrões tradicionais rigorosamente projetados, o MCP é uma especificação um tanto ambígua e definida de forma mais solta, mas sua grande força é justamente funcionar bem na prática. Acima de tudo, o fato de ser um protocolo aberto, que qualquer um pode usar, aumenta sua relevância.

O verdadeiro significado da web aberta

No ambiente real da web, o verdadeiro avanço acontece quando padrões imperfeitos e um tanto incompletos são adotados rapidamente. Foi esse tipo de dinâmica que tornou possíveis inovações como "ouvir em qualquer lugar onde você escuta podcasts".

O espírito da Web 2.0 buscava um ecossistema aberto, com APIs abertas, compartilhamento de dados e maior controle para usuários e desenvolvedores. É importante notar que plataformas fechadas como o Facebook foram justamente as responsáveis por sufocar a Web 2.0. No passado, Flickr, del.icio.us e Upcoming lideraram uma cultura centrada em compartilhamento e conexão, e em plataformas como blogs ao vivo havia discussões intensas sobre padrões abertos de API e protocolos.

O retorno da abertura

Depois de uma geração, chegamos novamente a um momento em que as expectativas em torno da interoperabilidade estão crescendo. No passado, repetiram-se experiências em que APIs eram bloqueadas e serviços desapareciam por causa das políticas fechadas das grandes empresas de tecnologia. Por exemplo, uma ferramenta de análise de dados de redes sociais criada pelo autor acabou sendo descontinuada quando a plataforma bloqueou a API. Essas políticas destruíram a visão da Web 2.0 de dados abertos e compatibilidade. Como resultado, problemas como impossibilidade de incorporar conteúdo e limitações à portabilidade de dados passaram a ser comuns.

Mas com a chegada do MCP, há expectativa de que a IA atue como gatilho para o ressurgimento da programabilidade e da abertura. O fato de várias plataformas adotarem o mesmo protocolo pode possibilitar um ciclo virtuoso baseado em tecnologia.

Quando plataformas adotam o protocolo como ele é e seguem fielmente a padronização, mudanças positivas acontecem em todo o ecossistema. O texto enfatiza que a ambição do desenvolvedor de "fazer melhor do que o padrão" pode, paradoxalmente, prejudicar o ecossistema. O HTML também não é uma especificação perfeita, mas acabou se tornando a base da interoperabilidade em larga escala da internet.

A importância de seguir padrões

Uma nova geração de desenvolvedores está vivenciando diretamente a força da inovação baseada em um mesmo protocolo e formato. Essa experiência pode levá-los novamente a uma dedicação quase obsessiva a padrões abertos. Reaparece um clima semelhante ao da época em que formatos abertos como RSS, Podcast, OpenID, OAuth e OpenSocial realmente davam mais poder aos usuários.

Agora não é mais um momento exclusivo das grandes empresas: desenvolvedores e comunidades de usuários podem exercer suas próprias demandas. Todos devem poder exigir das plataformas controle sobre a experiência e transparência, e quando padrões abertos como o MCP são adotados, a transparência sobre o funcionamento interno da plataforma e o uso dos dados precisa necessariamente acompanhar esse movimento. O MCP é aberto, mas ainda deixa a desejar em aspectos como funcionamento interno e questões de segurança, o que exige melhorias posteriores.

A possibilidade de renascimento do espírito da Web 2.0

O MCP não é uma solução mágica para todos os problemas, mas parece poder servir como um gatilho para o renascimento do ecossistema aberto da era da Web 2.0. As limitações continuam existindo, como o exagero nas discussões sobre IA e a falta de senso crítico.

Ainda assim, especialmente entre desenvolvedores mais jovens, o valor de uma web programável e da superação do fechamento está voltando a ser reconhecido. A web não era propriedade de apenas algumas gigantes da tecnologia, mas um espaço aberto que todos podiam usar da maneira que quisessem, e levanta-se a possibilidade de que o MCP possa trazer essa filosofia de volta.

[GN⁺]

Comentários do Hacker News

• Tenho a impressão de que muita gente tende a ignorar que o ponto central do MCP é que ele se encaixa bem em software corporativo; como o LLM pode atuar como uma espécie de tradutor universal e servir de camada intermediária flexível para conectar sistemas difíceis de integrar entre si, a adoção de servidores MCP já está acontecendo ativamente também no setor de B2B SaaS, e dentro das empresas também estão aumentando as discussões sobre ajustar restrições ou estruturas de acordo com os padrões de uso de API; mesmo que o protocolo não seja “enterprise-ready” em vários sentidos, há a visão de que isso não importa tanto, porque na história dos padrões foi comum ver especificações pouco refinadas e meio “desajeitadas” serem adotadas no fim quando atendiam à demanda do mercado
  • Entendo o MCP como algo parecido com RPC operando em conexões longas, geralmente baseado em WebSocket; pessoalmente acho RPC mais simples, primeiro porque reduz discussões desnecessárias no desenho de endpoints REST, como trocar tudo com POST ou modificar só campos com PUT, e segundo porque o LLM nem precisa conhecer a terminologia/semântica de REST: basta olhar os métodos RPC e chamar; no fim, esses dois pontos são grandes vantagens
  • Do ponto de vista empresarial, vale destacar que o MCP é um excelente modelo de receita; cada requisição de dados fica diretamente ligada à execução paga de um LLM; por outro lado, deixa uma frustração o fato de que, com a adoção de MCP, não exista nenhuma otimização como negociação de schema para baratear consultas futuras
  • Já existem REST e OpenAPI, que por si só oferecem recursos como self-discovery (descoberta automática); acredito que, entre as empresas que vão oferecer MCP, de qualquer forma todas também vão fornecer boas APIs
  • Concordo muito com isso: em grandes empresas, há muitos engenheiros que fazem um ótimo trabalho das 9 às 5 e depois nem querem pensar na empresa ao sair; nesse cenário, para a empresa, o resultado lógico é que a melhor escolha seja aproveitar ao máximo a chance de elevar a produtividade dos funcionários durante o horário de trabalho
• Fico me perguntando quanto tempo vai levar até aparecer um experimento para controlar criaturas tipo baratas com um servidor MCP; na prática, já houve muitos casos ao longo de mais de 10 anos, como o experimento RoboRoach e baratas ciborgues
• Antigamente, os desenvolvedores Unix escreviam documentação de especificação de forma extremamente rigorosa, mas os tempos mudaram, e eu diria que esse rigor e o cansaço com a ideia de eXtensible foram um dos fatores do fracasso das arquiteturas baseadas em XML; naquela época havia arquiteturas excessivamente complexas, com XSL, XHTML, XSD, WSDL, RDF, RSS etc., e isso acabou abrindo espaço para formatos simples como JSON ganharem popularidade; ainda assim, recentemente também venho vendo uma tendência de aumento no uso de XML, especialmente em prompts de sistema de LLMs como os da Anthropic, onde se usa bastante texto estruturado como XML ou Markdown; porém, acho que o modelo do MCP está errado: em vez de mandar o modelo “puxar” informação, é melhor empurrá-la, ou seja, fornecer o contexto antecipadamente
  • Um ponto interessante é que, ao criar recentemente uma linguagem de extensão de macros baseada em JSON, percebi que na prática estava reinventando XSLT ou XPath, e isso me fez admirar como a especificação de xpath é excelente para percorrer grafos; ferramentas como BaseX são úteis porque permitem importar XML arbitrário para um banco de dados e consultá-lo com XPATH/XQUERY; se a ideia é criar para o LLM uma interface de dados confiável para evitar alucinações, acho que a melhor solução é colocar um schema XML no prompt de sistema e fazer o modelo gerar consultas aos dados
  • Tenho dúvidas sobre até que tipo de problema esse “modelo de empurrar contexto antecipadamente” consegue lidar na prática; se o usuário já souber as informações de antemão, então simplesmente resolveria o problema direto, e sinto que a maior parte da demanda por MCP é algo como “só processe a consulta sem eu precisar aprender a conectar 15 fontes diferentes”
  • O LLM lida bem com XML em forma de tags, mas na prática quase ninguém usa um bloco de XML de verdade começando com <?xml version="1.0" encoding="UTF-8"?>, com namespaces, schema etc.; normalmente é só um conjunto de tags em estilo SGML
  • Quero enfatizar que o verdadeiro motivo do fracasso da web semântica foi um fator bem realista: ela não conseguiu se conectar a inserção de anúncios nem a modelos de negócio
  • Sou crítico da abordagem de “empurrar contexto”: como a capacidade de contexto (context window) dos LLMs é muito limitada, o ideal é passar apenas o mínimo de informação necessária; é quando cada modelo pode selecionar por conta própria apenas o contexto de que precisa e fazer o pull que a chance de superar esse limite aumenta bastante
• O MCP parece alimentar a esperança de que, com a popularidade da IA, várias plataformas se tornarão programáveis para qualquer finalidade, mas acho que na verdade ele está fadado ao fracasso, porque a web semântica também fracassou por não conseguir estruturar uma forma de monetização; o mesmo vale para recursos de “pesquisa” em que a IA explora a web em profundidade; por exemplo, restaurantes poderiam publicar seus menus como metadados para permitir automações como “encontre o taco mais barato do Texas”, mas a realidade é uma corrida de infraestrutura entre bloqueio de dados e crawlers de IA tentando contornar isso; olhando o quadro geral, a conclusão é que o sistema atual é ineficiente
  • No fim, o MCP é só uma forma evoluída de robots.txt; essencialmente, é um modelo de “se você descrever bem meus recursos, eu vou utilizá-los”; no passado, sistemas de agentes em Java dos anos 90 também fracassaram por causa do problema de assimetria de informação entre agentes, e há o receio de que, se esse limite de design desaparecer, toda a sociedade e o negócio parem de funcionar
  • Minha avaliação empírica é que APIs abertas, antes mesmo da questão de receita financeira, acabam levando à falência porque, sem investir recursos praticamente ilimitados, a onda de bots de solicitação de agentes de IA esgota os recursos; no longo prazo, acho que um modelo RPC com cobrança pay-per-call será uma alternativa estável, com operadores de modelos e agentes atuando como clearing house de pagamentos e incorporando esse custo a assinaturas e afins
  • Ideais de arquitetura REST como HATEOAS fizeram muito sucesso no início dos anos 2010, mas acabaram morrendo sem expansão prática além de ferramentas de automação como swagger yaml; na minha visão, o próprio vocabulário era difícil demais e isso ajudou a condenar a ideia ao fracasso
  • Discordo da visão de que texto legível por humanos seja uma barreira artificial; na verdade, exigir que um restaurante tenha habilidade para produzir JSON ou adote software é que é uma barreira artificial na prática; graças a ferramentas de NLP, dá para aproveitar os dados existentes quase como estão, reduzindo o custo de desenvolvimento quase a zero; embora haja imprecisão linguística, isso faz parte da própria natureza da linguagem humana, então não vejo como um grande problema
  • Falando isso com cuidado, já que estamos criticando a web semântica, acho que qualquer dono de restaurante que realmente queira pode publicar metadados a qualquer momento, e isso pode servir de ponte para conectar compradores e vendedores com facilidade; usando plugins do WordPress como exemplo, já existe suporte a metadados como schema.org/Restaurant, Menu, MenuItem e Offer, então talvez a maior barreira no fim seja o gatekeeping de serviços como Cloudflare, que de fato é o fator prático que bloqueia ideias de automação em Python
• Como LLMs conseguem ler documentação de API e se adaptar automaticamente, penso que conformidade com padrões de API já não é tão obrigatória quanto antes; independentemente de adotar ou não a especificação MCP, o simples fato de se esperar que cada site “ofereça uma API” já é uma grande mudança
  • Em ambientes reais, a documentação de API pode ser ruim, então o LLM pode gerar código ou chamadas incorretas; quando o usuário corrige isso e devolve ao LLM, o resultado acaba sendo criar uma camada intermediária, isto é, um servidor no estilo MCP; ao dar ao LLM acesso direto à API, também surgem riscos de segurança e de gestão de recursos, como explosões de custo por chamadas excessivas; existem vários outros pain points, e parte deles é resolvida justamente por uma arquitetura com uma interface intermediária como o MCP; se esse “intermediário” precisa ser MCP especificamente é outra questão, mas no momento é uma solução suficientemente prática
• O que mais me preocupa no MCP não é o nível ainda imaturo do protocolo, e sim o fato de que o poder de melhorar ou corrigir tudo está concentrado em equipes dentro de empresas como Anthropic e OpenAI; também sinto cautela por parecer uma especificação ainda presa à fase de brainstorming, e não centrada em quem realmente desenvolve e opera; passa uma sombra parecida com um duopólio Visa-Mastercard
  • Há também o caso de a Microsoft entrar no steering committee
• Tenho a expectativa de que a “web semântica” era na verdade apenas uma estrutura gramatical, e que talvez o MCP tenha chances de ser algo com viabilidade prática de verdade
• Existe essa percepção de que “os principais desenvolvedores Unix da velha guarda eram exigentes demais”, mas ironicamente o próprio Unix foi um dos berços da cultura de “tentar rápido e quebrar as coisas”; as gerações mudam, mas acho que a essência não muda
• Há uma preocupação real de que o MCP possa ser abusado, como o SEO do Google, para espalhar publicidade e spam voltados à IA
• Acho importante tomar cuidado com a ilusão de que, graças ao MCP, todo mundo terá acesso fácil a todo tipo de dado; na prática, a realidade mais convincente é a de várias camadas de autenticação de pagamento, IPs na whitelist e outros mecanismos de segurança, e no fim o usuário só recebe um erro ERR 402