MCP: um sistema de plugins universal (por acaso)

• USB-C não vale apenas para carregar e transferir arquivos; seu valor está na versatilidade de poder se expandir para vários usos
• MCP (Model Context Protocol) foi projetado originalmente para assistentes de IA, mas na prática pode se tornar um sistema de plugins universal que conecta todas as fontes de dados e ferramentas
• Como no caso de NFT Base64, o protocolo pode se expandir além de seu objetivo original para armazenar e utilizar diretamente dados do mundo real
• Quanto mais servidores MCP existirem, mais cada app poderá aproveitar diversas funcionalidades com facilidade, sem integrações separadas
• Assim como o USB-C, o MCP também pode se tornar um "espaço de possibilidades onde qualquer coisa pode ser conectada", servindo de base para inovações inesperadas

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C e a universalidade inesperada

• Todo mundo pensava no USB-C como algo para carregamento ou transferência de arquivos, mas graças à sua estrutura ele pode se expandir para vários usos
• O caso do amigo do autor, Rex, que conectou uma torradeira a um monitor, dando à torradeira saída HDMI, mostra as possibilidades infinitas do USB-C
• Isso acontece porque o USB-C é uma estrutura em que, sem se preocupar com especificações de energia e dados, qualquer coisa pode ser conectada se o conector servir

O princípio do acendedor de cigarros do carro

• O acendedor de cigarros do carro era originalmente para acender cigarros, mas hoje é usado como uma porta de energia universal para várias finalidades
• Como no acendedor, um protocolo não limita a escolha do usuário e permite vários usos
• O MCP também tem uma expansibilidade parecida

Redescobrindo o MCP: por acaso, um sistema de plugins universal

• Em geral, o MCP (Model Context Protocol) é conhecido como algo usado para permitir que assistentes de IA, como o Claude, utilizem dados
• A documentação oficial também afirma que ele "conecta de forma padronizada modelos de IA a várias fontes de dados e ferramentas"
• Mas, se tirarmos o elemento de IA, o MCP se torna um meio de conectar "qualquer coisa" a diferentes fontes de dados e ferramentas
• Em outras palavras, ele acaba virando um protocolo de conexão universal, independentemente de seu propósito original

A revelação do NFT Base64

• Os NFTs originalmente serviam para referenciar imagens, mas em algum momento a própria referência virou dado
• À medida que o propósito original do protocolo mudou, o cartão de biblioteca passou a fazer o papel do livro de verdade
• Ele se transformou em uma ferramenta que lida diretamente com dados reais de uma forma muito mais ampla do que sua intenção original

O efeito de rede que ninguém previu

• Quanto mais servidores MCP surgirem para IA, mais acontece o efeito de todos os apps ganharem novas funções sem desenvolvimento separado
• Por exemplo, se alguém criar um servidor MCP do Spotify, um app de exercícios pode gerar playlists automaticamente via MCP
• Surge um efeito de rede em que desenvolvedores e apps que nem se conhecem se conectam naturalmente, e todos saem ganhando
• Cada servidor MCP pode ser reutilizado como um plugin universal
• Ninguém planejou isso, mas acaba surgindo, por acaso, um ecossistema universal de plugins

O significado do USB-C e a filosofia do MCP

• O MCP costuma ser comparado ao USB-C da IA, mas o que torna o USB-C especial não é ser apenas uma porta simples, e sim um espaço de possibilidades onde qualquer coisa pode ser conectada
• Assim como o USB-C aceita energia, dados, vídeo e outras funções ainda desconhecidas, o MCP não é algo "para IA", mas sim um 'encaixe bem projetado para funcionalidades', no qual qualquer pessoa pode conectar qualquer função

A parte em que eu digo que estou construindo algo

• O autor está desenvolvendo um app de gestão de tarefas chamado APM (Actions Per Minute)
• O APM funciona como um sistema de plugins usando exclusivamente servidores MCP
• Sempre que quiser adicionar uma função, o usuário só precisa conectar um servidor MCP (por exemplo: corretor ortográfico, pedido automático de café, reações de personagem de jogo etc.)
• É uma estrutura em que o próprio app pode se transformar de forma fluida em vários formatos

O princípio do protocolo da torradeira

• Todos os grandes protocolos acabam sendo usados de forma diferente da intenção inicial, criando inovação em usos inesperados
  • HTTP: para artigos acadêmicos → infraestrutura da civilização
  • Bluetooth: viva-voz → destravar a porta de casa etc.
  • USB: dispositivo de entrada → carregar ventilador portátil etc.
• O MCP também foi criado originalmente para transmitir contexto para IA, mas em essência é um protocolo que conecta tudo a tudo
• O texto enfatiza que ele é a base de um ecossistema de plugins capaz de gerar inovações imprevisíveis
• Mesmo sem ter sido pensado para isso, ele combina perfeitamente com uma era em que torradeiras são conectadas a monitores por HDMI

Encerramento

• PS: se alguém criar um computador que exale cheiro de pão fresco com um servidor MCP, por favor entre em contato
• PPS: o acesso antecipado do APM foi lançado, e o autor incentiva tentativas engenhosas e experimentos criativos
• (Em algum lugar, um protocolo está sendo usado exatamente como foi projetado. Isso é bastante suspeito)

[a1eng0]

As respostas do servidor MCP muitas vezes vêm em linguagem natural, sem um schema definido.

Provavelmente seria difícil processar programaticamente essa resposta em linguagem natural sem um LLM.

[winterjung]

Só para constar, com a adição recente de structured tool output à especificação mcp 2025-06-18, passou a ser possível descrever schemas de resposta. Como você disse, a maioria das ferramentas MCP já implementadas provavelmente é unstructured, mas parece algo promissor para as ferramentas MCP daqui para frente.

[a1eng0]

Que coincidência encontrar você aqui de novo, Gyeoul haha

Eu não tinha conseguido acompanhar a especificação de 250618. Obrigado!

[GN⁺]

Comentários do Hacker News

• Gosto muito deste texto e do protocolo MCP. Mas, quando olho para o MCP, ele me lembra microsserviços e SOA. Fico preocupado se não estaremos repetindo o pesadelo de criar novos pontos de falha. Por outro lado, também tenho a expectativa de que, com a adoção de agentes, melhorias de confiabilidade possam acontecer de forma mais natural

• Concordo com a ideia do texto, e acho bem interessante a forma como o autor usa o MCP de um jeito meio fora da proposta original. O verdadeiro ponto central dessa linha de pensamento não é simplesmente o surgimento de um protocolo que permite fazer coisas novas. Como outros comentários disseram, o MCP em si não é uma ideia particularmente nova ou interessante. A parte realmente interessante é que, com a febre dos agentes de IA, interoperabilidade passou a ganhar atenção, e o problema de vendor lock-in está sendo tratado como algo ultrapassado. Não sei por quanto tempo isso vai durar, mas já me deixa contente

  • Isso me lembra a época da adoção do Winsock. Houve um tempo em que todo o trabalho de rede no Windows usava interfaces proprietárias e desconectadas entre si. Aí houve aquele momento em que vários fornecedores se reuniram e decidiram criar um padrão comum que beneficiava todo mundo. Veja a Wikipedia do Winsock
  • O ponto principal não é apenas que interoperabilidade virou moda ou que ficou fácil conectar tudo. A verdadeira inovação é que o próprio LLM aprendeu a lidar com ferramentas. Se eu só precisar construir o backend, o frontend deixa de ser problema meu e a IA resolve sozinha. Claude e Gemini também conseguem usar ferramentas por conta própria se você só der o objetivo. Antes, eu sempre precisava definir um procedimento claro, passo a passo, para obter o resultado desejado; agora, os LLMs se adaptam muito melhor a situações dinâmicas do que programas rígidos, e isso é uma mudança enorme
  • Há um clima de expectativa excessiva. Mas, na minha opinião, os agentes de IA realmente criaram um incentivo forte para a interoperabilidade. Antes, todo mundo trabalhava devagar dentro do seu próprio sistema, e isso até ajudava a garantir empregos estáveis; agora, a tendência é conectar tudo com tudo. É como se fosse mais barato para o CEO ir pessoalmente levar pizza ao hackathon: agentes dependem de integração. Como alguém que surfou diretamente a onda anterior de inovação em integrações de API, minha sensação é que o mundo finalmente alcançou isso. Espero que esse clima dure bastante
  • Não concordo totalmente com a ideia de que a febre dos agentes de IA está impulsionando a interoperabilidade e tornando o vendor lock-in uma coisa do passado. Ferramentas em evidência hoje, como o Cursor, usam MCP só em uma direção e não expõem para fora o histórico de conversa nem o contexto. Gosto do Cursor, mas, começando por ser um fork não open source do VS Code, esse tipo de mentalidade de “não devolver nada” tende a prejudicar a confiança dos desenvolvedores. No fim, o lock-in continua muito sólido
  • Ironicamente, as recentes restrições de acesso a APIs pioraram por causa da questão de treinamento de dados para IA. Na verdade, esse tipo de lockdown de API já existia muito antes, e há uma visão cética de que, se a nova tendência de abertura não corresponder ao hype, tudo pode voltar a se fechar a qualquer momento

• O autor deposita grandes expectativas na generalidade do MCP, mas, sinceramente, fico me perguntando qual é a diferença disso para o próprio conceito de API. Se trocarmos MCP por REST, o texto mudaria tanto assim? Há semelhanças com APIs de sistema operacional, POSIX e pipes do Unix. Claro, o MCP é muito mais simples e genérico do que tudo isso. Mas talvez a solução real não seja criar uma nova abstração a cada vez, e sim fazer software simples e bem fundamentado

  • MCP é diferente de REST. Na verdade, ele se parece mais com um protocolo que permite descobrir endpoints REST dinamicamente em tempo de execução e deixa o usuário configurar quais endpoints REST quer usar. Por exemplo, se um app vai tocar músicas do Spotify, naturalmente ele usa a API do Spotify. Se depois você quiser adicionar suporte às músicas do Sonofm, do jeito tradicional teria de mudar código, adicionar condicionais, publicar uma nova versão, avisar sobre a atualização etc. Já o MCP permite configurar esse tipo de coisa em tempo de execução, então parece muito mais escalável
  • A diferença central é que o MCP torna a descrição da interface obrigatória desde o início. O REST também tem OpenAPI, mas isso foi um acréscimo posterior, e a adoção padronizada é baixa. Já o MCP exige que a descrição seja publicada primeiro, então o nível de acessibilidade é outro
  • Para mim, a única parte realmente nova do MCP é ter tornado obrigatória, no nível do protocolo, a entrega de esquemas. Claro, o fato de a estrutura de requisição e resposta ser consistente ajuda bastante até para bibliotecas que encapsulam tipagem dinâmica em tipos estáticos. Na prática, todo mundo já fazia algo parecido em APIs. Só nunca tínhamos concordado sobre esse formato de envelope. Acho que ele está ganhando atenção justamente porque fornecer esquema é obrigatório, e os modelos de IA conseguem usar isso imediatamente
  • Uma diferença importante entre MCP e REST é a existência de um comando embutido list-tools. APIs REST têm várias maneiras de listar recursos, mas o MCP fornece um único jeito padronizado
  • Outra grande diferença é que o MCP já traz um processo de discovery embutido no protocolo. No REST, não existe nenhum elemento que diga ao cliente quais recursos estão disponíveis ou quais capacidades a API oferece

• Muita gente fala do MCP como se fosse algo incrível, mas não tenho visto tantos exemplos de coisas realmente legais sendo construídas. A sensação é parecida com a febre do blockchain. No fim, o MCP me parece mais uma solução temporária até a IA ficar mais inteligente. Daqui a uns dois anos, acho que a evolução natural será jogar a documentação da ferramenta ou o OpenAPI diretamente para a IA e deixá-la absorver todo o contexto sozinha, em vez de usar MCP

  • Por exemplo, tenho dúvidas de quanto simplesmente fornecer a documentação do Ableton Live ajudaria o Claude a compor uma música por conta própria
  • Por melhor que o modelo fique, sua utilidade continua bastante limitada se você não der a ele acesso determinístico a ferramentas e informações sobre o estado do mundo. E, pensando em segurança, você não pode deixar um modelo fazendo requisições arbitrárias em produção sem controle. Acho o hype em torno do MCP um pouco exagerado, mas o problema que ele tenta resolver é, sim, importante. Se esse protocolo fizer com que desenvolvedores passem a expor funcionalidades de forma clara via API, isso seria algo muito animador
  • A febre do blockchain e o MCP são bem diferentes. Eu também era cético no começo, mas, quando você implementa um servidor MCP por conta própria, percebe que a experiência é totalmente outra. Com IA conversacional/de voz, LLMs atuais, MCP e várias ferramentas e funções misturadas com APIs e dados/serviços privados, parece mesmo que estamos entrando numa fronteira completamente nova. Não é 100% perfeito, mas é bom o suficiente para quase todos os casos reais de uso, e a forma de construir apps deve mudar bastante daqui para frente
  • Eu mesmo queria saber o que os parlamentares do meu estado tinham feito nesta semana, mas não havia um jeito fácil de encontrar isso. Ouvi dizer que o MCP junto com a API do congress.gov era interessante, então fiz um servidor MCP. Aqui está o código. Hoje eu realmente uso isso para acompanhar em tempo real a movimentação do Congresso dos EUA
  • Enquanto a arquitetura dos modelos de IA continuar evoluindo, acho difícil que uma camada intermediária de middleware como o MCP desapareça facilmente

• Tenho a impressão de que a estratégia “Embrace, Expand, Extinguish” que a Microsoft sempre usou também está sendo aplicada aqui. Em nome da estabilidade e da segurança do sistema, deixar agentes descobrirem ferramentas dinamicamente sem qualquer controle aumenta muito o risco de conflito. Existem alternativas como PydanitcAI, mas no fim a Microsoft colocou o peso dela por trás do MCP oficialmente no Build 2025 e está conduzindo o setor no ritmo dela. A Anthropic lançou o padrão com ferramentas fracas e sem governança, então a Microsoft está numa posição fácil para tomar conta. O próximo passo seria a Microsoft transformar seu próprio registro no padrão da indústria e combiná-lo com comandos específicos do Windows. No final, desenha-se um cenário em que ela passa a definir critérios de “segurança” de forma vantajosa para si e isola os concorrentes

• E se a gente removesse totalmente o componente de IA? Minha preocupação é que, se passarmos a depender diretamente de servidores MCP sem middleware de IA, vamos bater imediatamente em problemas de compatibilidade retroativa. Isso porque os servidores MCP assumem que quem chama é um algoritmo de IA, então mudanças incompatíveis em ferramentas ou em esquemas de entrada/saída podem acontecer a qualquer momento

• Eu também pensei algo parecido, mas acabei concluindo que a maior parte dos servidores MCP não passa de novos clientes para APIs já existentes. Por exemplo, o servidor MCP da Kagi só chama a API da Kagi. Então não seria melhor usar logo a API diretamente? Outra coisa: vamos acabar com um interpretador Python extra rodando para cada servidor MCP no sistema. Será que não vai surgir um serviço de “hospedagem” para juntar tudo isso e fazer a ponte de uma vez?

  • Pelo que entendi, MCP é basicamente adicionar mais um endpoint de API, /list-tools, a uma API existente. Todo cliente primeiro acessa /list-tools para obter a lista de ferramentas disponíveis e depois chama cada API específica
  • Minha abordagem é a seguinte: se já existe uma API com especificação OpenAPI, não bastaria empacotá-la com FastMCP? Na prática, ao lidar com autenticação e integrar com o Goose, a conclusão foi que no fim o Goose só precisa disparar comandos curl para as rotas da API existente. Se a especificação OpenAPI já for boa o bastante, talvez o MCP nem seja realmente necessário. Claro, se não houver uma API existente, aí o próprio servidor MCP pode evoluir para implementar a lógica principal

• Há bastante ceticismo nos comentários, e eu entendo. Na semana passada implementei um servidor MCP por conta própria e, sinceramente, acho exagero dizer que ele é “bem projetado”. Um dos objetivos do MCP é “ser fácil de construir”, mas, na prática, não é tão simples assim. Ainda assim, o importante é que neste momento a atenção de muitos desenvolvedores está concentrada na mesma direção. Com esse tipo de momentum, a velocidade de resolução de problemas pode ser muito alta. Além disso, para um ecossistema se formar, é preciso haver massa crítica em torno de alguma coisa, e sinto que esse ponto de inflexão está realmente chegando agora. Torço para que todos tenham paciência e sorte

  • Se você usar só a biblioteca Python do MCP, fica realmente fácil. Basta colocar um decorator na função e a ferramenta fica pronta na hora. Eu nem conhecia o protocolo MCP, mas, desse jeito, tudo funcionou bem. Claro, se tiver de implementar o protocolo você mesmo, a situação pode ser diferente
  • Um servidor MCP deveria apenas reexpor “APIs públicas ou semipúblicas já existentes”. Faz sentido a visão de que ele deveria poder ser implementado com o mínimo possível de alterações nos endpoints originais
  • Já houve tentativas assim no passado, mas, depois de alguns anos, os apps acabam fechando seus endpoints e bloqueando o acesso, permitindo apenas servidores específicos como ChatGPT, Claude etc. Interoperabilidade é, na prática, também portabilidade do usuário, e muitas empresas de tecnologia preferem lock-in e monopólio a portabilidade

• Vale destacar que, ao longo da história, reduzir a barreira de entrada sempre teve um papel importante na adoção e difusão de tecnologias. O MCP segue essa linha e não deve ser ignorado. Até no nosso time, uma pessoa sem qualquer formação técnica conseguiu usar diretamente um agente para automatizar tarefas de compartilhamento de arquivos. Claro, antes isso só era possível com centenas de linguagens de programação, bibliotecas e APIs, mas agora, graças ao MCP, até quem não é especialista pode simplesmente resolver o problema sem se preocupar com esses detalhes. Em termos de desempenho, não é o melhor, e a implementação também não é a ideal, mas o valor trazido por essa nova abordagem é algo sem precedentes dentro dos recursos e do nível técnico que temos hoje. Esse é o ponto realmente importante

  • Acho exagerada essa história de que alguém sem perfil técnico no time conseguiu organizar compartilhamento de arquivos sozinho. Se fosse para organizar milhares de arquivos, até vai, mas, pela minha experiência, em quase toda tentativa de reorganização de compartilhamento de arquivos é difícil até conseguir a cooperação dos departamentos envolvidos. Mesmo as pessoas responsáveis pelo trabalho não gostam, porque nem consideram aquilo parte da função delas. Às vezes só se consegue convencer com pressão de executivos de alto escalão, ou então sentando junto e passando uma hora inteira só para extrair a estrutura de pastas. Uns 50% do trabalho são política entre departamentos, 20% atualização de processo, 20% treinamento, e só 10% é problema técnico. Já passei por desastres grandes e pequenos, além de um caos interminável, então não acho plausível que a realidade seja tão simples só porque uma ferramenta de IA facilitou a criação. Minha aposta cética é que, alguns meses depois, alguém vai estar restaurando backup

• A piada de que “seria legal se um agente de IA respondesse e obedecesse comandos em Warcraft 3 como o peão”, e eu responderia que preferia estar velejando

  • Só queria apontar que “I'd rather be sailing” é uma fala de Warcraft 2; em Warcraft 3, a resposta é “I'd rather be flying”