O conceito de Protocolo de Comunicação de Máquina (MCP) tem recebido considerável atenção no mundo da tecnologia, particularmente no âmbito dos Grandes Modelos de Linguagem (LLMs). Embora prometa agilizar a interação entre LLMs e recursos externos, uma análise mais detalhada revela vários problemas e limitações inerentes que merecem cuidadosa consideração. Esta análise aprofunda as críticas em torno do MCP, explorando suas vulnerabilidades, desafios de escalabilidade e as implicações mais amplas para o desenvolvimento de agentes de IA.
Sobrecarga das Responsabilidades do MCP
Uma crítica comum é que o MCP está sendo incumbido de responsabilidades excessivas. Argumenta-se que o MCP deve servir principalmente como uma porta de entrada para os LLMs acessarem e interagirem com recursos externos. Vê-lo meramente como uma ‘porta’ ou ‘ponte’ ajuda a esclarecer seu propósito e limitações.
Atribuir questões como exposição acidental de dados, vulnerabilidades de injeção de prompt e deficiências no controle de custos diretamente ao MCP é uma atribuição de culpa inadequada. Esses são problemas que os desenvolvedores devem resolver dentro dos limites que controlam. Os desenvolvedores precisam implementar limites de taxa e monitorar o uso, independentemente do protocolo utilizado. Equiparar isso a culpar a estrada por excesso de velocidade é apropriado – a infraestrutura não é responsável pelo comportamento individual.
Em última análise, muitas das preocupações levantadas são questões mais amplas relacionadas à delegação de tarefas para agentes de IA. Os desenvolvedores devem assumir a responsabilidade por gerenciar esses desafios dentro de suas aplicações específicas, em vez de esperar que a própria API lide com tudo.
A Faca de Dois Gumes dos LLMs e da Injeção de Prompt
As discussões recentes sobre o MCP frequentemente se assemelham a avisos sobre os perigos inerentes de facas afiadas – elas podem cortar se forem manuseadas incorretamente. A injeção de prompt, uma preocupação significativa, é uma consequência da natureza dos próprios LLMs. As tentativas de eliminar o risco de injeção de prompt degradam as próprias capacidades que tornam os LLMs valiosos.
A noção de separação entre ‘controle vs. dados’, comum em sistemas tradicionais, não existe naturalmente nos LLMs. Os LLMs ganham seu poder e generalidade precisamente porque carecem dessa separação rígida. Essa característica inerente os torna vulneráveis a ataques de injeção de prompt.
Embora os MCPs remotos como um Serviço possam apresentar riscos, a falha não reside no protocolo em si, mas em confiar tarefas sensíveis a terceiros não confiáveis. Essa analogia se estende à ideia de prender uma faca com fita adesiva a um Roomba errático – o problema não é a faca em si, mas a decisão de prendê-la a um dispositivo imprevisível.
Admoestações para ‘ter cuidado’ ou sugestões de equipamentos de proteção, embora tecnicamente precisas, perdem a questão central: a decisão mal aconselhada de combinar uma ferramenta afiada com um sistema não controlado.
Desafios de Escalabilidade
Além das preocupações de segurança, o MCP enfrenta limitações fundamentais de escalabilidade. Destaca-se a correlação negativa entre a confiabilidade do LLM e a quantidade de contexto instrucional fornecida. Isso desafia a crença comum de que adicionar mais dados e integrações resolverá automaticamente os problemas. À medida que o número de ferramentas e integrações aumenta, o desempenho de um agente pode degradar, ao mesmo tempo em que aumenta o custo de cada solicitação.
Enfatiza-se que o MCP não escala além de um determinado limite. Tentar adicionar um número ilimitado de ferramentas ao contexto de um agente inevitavelmente impactará negativamente suas capacidades. Essa limitação é inerente ao conceito de MCP e requer mais atenção do que questões de autenticação.
Os usuários podem eventualmente experimentar um declínio no desempenho à medida que habilitam mais servidores MCP, levando à interferência entre eles. Isso contrasta fortemente com os sistemas típicos de gerenciamento de pacotes, onde a não interferência é uma propriedade fundamental.
O problema central com o MCP é que seu comportamento real se desvia das expectativas do usuário. É crucial reconhecer que o MCP não é uma solução plug-and-play que integra perfeitamente um número ilimitado de ferramentas sem consequências.
Abordando Limitações com UI e Gerenciamento de Ferramentas
Uma solução proposta para as limitações do MCP é melhorar a interface do usuário. Se uma ferramenta for executada não intencionalmente, a UI deve fornecer uma maneira fácil de desativá-la ou modificar sua descrição para esclarecer seu uso pretendido.
Observa-se também que o crescimento do contexto geralmente leva a um melhor desempenho e habilidades de uso no mundo real, contradizendo a noção de uma correlação estritamente negativa. No entanto, reconhece-se que, em certos casos de uso ou com contextos mal projetados, a degradação do desempenho pode ocorrer.
Para abordar a escolha esmagadora de ferramentas, uma abordagem de ‘dividir para conquistar’ é sugerida. Isso envolve adicionar uma ferramenta especificamente projetada para selecionar as ferramentas mais relevantes para uma determinada tarefa. Essa ‘ferramenta de escolha de ferramentas’ poderia ser outra chamada LLM, encarregada de retornar um subconjunto de ferramentas disponíveis para o agente ‘pai’. Essa abordagem em camadas adiciona níveis extras de indireção para gerenciar a complexidade.
No entanto, simplesmente ter ferramentas no contexto pode alterar significativamente a saída de um modelo. Embora as ferramentas contextualmente relevantes (obtidas por meio de técnicas como Geração Aumentada de Recuperação ou RAG) sejam benéficas, ocultar todas as ferramentas atrás de uma solicitação ‘get_tools’ pode ser prejudicial.
MCP como uma Camada de Transporte e Autorização
O MCP funciona principalmente como um transporte e formato de fio com um ciclo de vida de solicitação/resposta, focando na autorização em nível de ferramenta. Argumenta-se que o maior problema com o MCP é sua falha em permitir que agentes de IA componham funcionalmente ferramentas.
Postula-se que o MCP pode ser desnecessário em primeiro lugar, pois os LLMs já possuem a capacidade de interagir com APIs documentadas usando especificações OpenAPI. O elemento ausente é a autorização – a capacidade de controlar quais APIs uma IA pode acessar. Em vez de MCP, sugere-se permitir que as IAs façam solicitações HTTP enquanto aplicam autorização a endpoints específicos. Essa abordagem se alinha com a tendência atual de envolver APIs existentes com ferramentas MCP finas.
Um aspecto particularmente irritante do MCP é sua falta de suporte para resultados de chamadas de ferramentas de streaming. O único par solicitação/resposta força os clientes a chamar repetidamente ferramentas para paginação, dificultando processos de longa duração. Implementar uma capacidade de streaming, talvez usando gRPC, poderia melhorar significativamente a eficiência do MCP.
A Facilidade de Expor Dados Sensíveis
Uma preocupação significativa com o MCP é o potencial para fácil exposição de dados sensíveis. Além disso, o MCP não torna inerentemente os agentes de IA mais confiáveis; ele simplesmente concede a eles acesso a mais ferramentas, o que pode paradoxalmente diminuir a confiabilidade em certas situações.
Reconhece-se que não se espera que o MCP resolva ou seja responsável por todas essas questões. Em vez disso, o MCP cria uma área de superfície maior para esses problemas, exigindo que desenvolvedores de aplicativos e usuários estejam vigilantes.
Analogias e Planejamento Urbano
Usa-se a analogia do planejamento urbano para ilustrar a questão. Comparar o MCP a uma estrada urbana de seis pistas com um limite de velocidade de 40 km/h destaca a desconexão entre o projeto e o uso pretendido. Simplesmente impor multas ou adicionar ‘correções’ superficiais não aborda o problema subjacente de um projeto ruim.
O planejamento urbano eficaz envolve projetar estradas que incentivem naturalmente a adesão aos limites de velocidade. Da mesma forma, o MCP deve ser projetado para mitigar inerentemente os riscos potenciais, em vez de depender apenas de controles externos.
LLMs Tomando Ações Indesejadas
O artigo muda para uma crítica mais ampla de protocolos que permitem que os LLMs executem ações em serviços. Identifica-se um problema central: os LLMs podem tomar ações que os usuários não pretendem que tomem. Distingue-se entre ações que os LLMs podem tomar independentemente e aquelas que exigem um prompt do usuário.
Embora o objetivo final possa ser ter os LLMs gerenciando empresas inteiras, a tecnologia ainda não está pronta para tanta autonomia. Atualmente, os usuários podem nem querer que as IAs enviem e-mails sem revisão prévia.
Rejeita-se a solução de solicitar a confirmação do usuário, citando o risco de os usuários caírem em um padrão de confirmação automática (‘modo YOLO’) quando a maioria das ferramentas parece inofensiva. Isso é comparado ao fenômeno psicológico de as pessoas gastarem mais com cartões do que com dinheiro – um problema enraizado no comportamento humano, não na tecnologia.
A Pergunta Fundamental: Por Que Não Apenas Usar APIs?
Uma pergunta recorrente nas discussões sobre o MCP é por que não simplesmente usar APIs diretamente.
O MCP permite que clientes LLM que os usuários não controlam diretamente (por exemplo, Claude, ChatGPT, Cursor, VSCode) interajam com APIs. Sem o MCP, os desenvolvedores precisariam construir clientes personalizados usando APIs LLM, uma tarefa muito mais cara do que usar clientes existentes com uma assinatura e ensiná-los a usar ferramentas específicas.
Um desenvolvedor compartilha sua experiência de construir um servidor MCP para se conectar ao seu sintetizador de hardware FM via USB, permitindo o design de som orientado por IA.
Integração do Cliente LLM e Padronização
A questão central é que nem todos os clientes LLM suportam nativamente a interação direta com a API, com as ações personalizadas do ChatGPT sendo uma exceção notável. Anthropic, Google e OpenAI concordaram em adotar o MCP como um protocolo compartilhado para agilizar o processo para clientes com tecnologia LLM como Claude, ChatGPT e Cursor.
O MCP simplifica o processo para aqueles que constroem clientes LLM. Se você deseja que um LLM interaja com uma API, você não pode simplesmente fornecer uma chave de API e esperar que funcione – você precisa criar um Agente.
O MCP pode ser visto como uma forma de documentar APIs e descrever como chamá-las, juntamente com ferramentas padronizadas para expor essa documentação e facilitar as chamadas. Ele fornece abstração suficiente para envolver APIs sem complicações desnecessárias, mas essa simplicidade também pode levar os usuários a ‘atirarem no próprio pé’.
A Eficiência e Reusabilidade do MCP
Sem o MCP, os desenvolvedores precisariam explicar repetidamente ao LLM como usar uma ferramenta cada vez que ela é invocada. Isso acarreta o risco de o LLM não conseguir usar a ferramenta corretamente devido a informações esquecidas ou comportamento de API não padronizado.
Essa explicação e duplicação constantes desperdiçam tokens no contexto, aumentando os custos e o tempo. O MCP agiliza esse processo agrupando todas as informações necessárias, tornando o uso da ferramenta mais eficiente e facilitando o compartilhamento da ferramenta.
Ao dizer a um provedor de LLM ‘aqui está uma ferramenta que você pode usar’ juntamente com a documentação da API, os usuários podem reutilizar essa ferramenta em vários chats sem lembretes repetidos. Isso também permite que clientes LLM de desktop se conectem a programas em execução localmente, resolvendo o problema de processos de execução específicos do sistema operacional.
MCP e Acesso a Recursos Locais
O MCP facilita o acesso a recursos locais como arquivos, variáveis de ambiente e acesso à rede para LLMs. Ele é projetado para ser executado localmente, concedendo ao LLM acesso controlado a esses recursos.
A ‘forma’ padrão de chamada de ferramenta LLM espelha de perto a ‘forma’ de chamada de ferramenta MCP, tornando-o um padrão simples para conectar ferramentas a agentes.
O MCP atua como uma ponte entre o esquema de chamada de função exposto ao modelo de IA e as APIs subjacentes. Ele traduz chamadas de função em ferramentas, permitindo uma comunicação perfeita.
Se você é um provedor de ferramentas, o MCP oferece um protocolo padronizado para front-ends de agentes de IA se conectarem à sua ferramenta. Isso responde à pergunta de por que o protocolo padrão não pode ser simplesmente HTTP e OpenAPI.
O MCP é uma meta-API que incorpora endpoints e seus detalhes operacionais na especificação, permitindo que os LLMs interajam com eles de forma mais eficaz.
MCP em Cenários Específicos
O MCP pode resolver problemas quando os usuários fazem perguntas ou não têm certeza de quais APIs usar. Ele também pode processar solicitações com base em mensagens anteriores.
Um usuário compartilha sua experiência de querer recuperar o ‘X’ de um usuário e enviá-lo para um endpoint. Eles acharam o MCP exagerado para uma tarefa tão simples, indicando que nem sempre é necessário para interações básicas com a API.
O MCP é comparado a um framework de aplicativos web FastAPI para construir software que pode se comunicar pela rede, especificamente projetado para experiências agentic. Ele pode ser visto como ‘Rails-for-Skynet’, fornecendo um framework padronizado para o desenvolvimentode agentes de IA.
Preocupações Sobre o Controle do Provedor
Existem preocupações de que o MCP esteja sendo promovido para aumentar o controle do lado do provedor sobre o sistema. Os provedores de LLM podem eventualmente restringir o acesso à API, semelhante a como o Google dificultou o uso de IMAP/SMTP com o Gmail.
O uso do OpenAPI permite que os agentes recuperem as especificações da API de /openapi.json.
O MCP permite interações rápidas, permitindo que os usuários realizem tarefas em segundos, em vez de gastar tempo preparando dados de entrada, enviando-os para a API, analisando a saída e repetindo o processo para cada mensagem.
Sandboxing e Riscos de Segurança
Um dos maiores problemas é como a saída de uma ferramenta de servidor MCP pode afetar outras ferramentas no mesmo thread de mensagens. Isso exige sandboxing entre as ferramentas para evitar consequências não intencionais. Os laboratórios Invariant abordaram isso com descrições de ferramentas, enquanto outros usaram anexos de recursos MCP. A falta de sandboxing exacerba os riscos de injeção de prompt.
Isso é comparado à injeção de SQL – um sistema improvisado onde as vulnerabilidades podem ser exploradas em qualquer ponto com observabilidade mínima.
A interface de prompt também é suscetível a uma forma de injeção de SQL, pois o modelo não consegue distinguir partes confiáveis do prompt de entrada contaminada pelo usuário. Resolver isso requer mudanças fundamentais na codificação, decodificação e treinamento do modelo.
Isso permite tanto a injeção de prompt quanto a injeção de ferramenta, potencialmente levando à execução de código não confiável.
Containerização e Acesso Controlado
Um desenvolvedor criou um servidor MCP que inicia um contêiner Docker com o código do projeto montado. Essa abordagem permite que o LLM acesse todo o conjunto de ferramentas Unix e as ferramentas específicas do projeto em um ambiente sandboxed.
Esse fluxo de trabalho agentic, conduzido por meio de uma interface baseada em bate-papo, provou ser mais eficaz do que os métodos tradicionais.
A chave é conceder aos agentes MCP acesso ao que eles precisam e nada mais. A containerização e a UX transparente da ferramenta são cruciais para mitigar os riscos de segurança.
Máquinas Virtuais e Acesso à Internet
Dar aos agentes um computador com uma instalação mínima do Linux (como uma VM ou contêiner) pode produzir melhores resultados, permitindo que eles busquem informações da Internet. No entanto, isso levanta preocupações de segurança em relação a instruções maliciosas e exfiltração de dados.
Limitar o acesso a sites confiáveis pode mitigar alguns riscos, mas até mesmo fontes confiáveis podem hospedar conteúdo malicioso. A compensação entre a probabilidade de encontrar instruções maliciosas e os benefícios de produtividade deve ser cuidadosamente considerada.
As diferenças entre funcionários e agentes de IA são significativas. Os funcionários são pessoas jurídicas sujeitas a leis e contratos, proporcionando responsabilidade. Os agentes de IA carecem desse framework legal, tornando a confiança mais difícil.
Os Primeiros Estágios do Desenvolvimento do MCP
O MCP foi anunciado apenas em novembro de 2024 e o RFC está evoluindo ativamente.
Alguns veem todo o conceito de assistente pessoal de IA, incluindo o MCP, como fundamentalmente falho.
O impulso inicial para assistentes de IA no final dos anos 1990 e início dos anos 2000 falhou porque os agregadores de conteúdo com integração vertical e poder de compra em massa se mostraram mais eficazes. Isso levou à ascensão de plataformas como Expedia e eBay.
Os sistemas multi-agentes exigem que os programadores influenciem o estado dos agentes, uma tarefa de programação desafiadora.
Os Limites do Valor Gratuito
O desejo de ‘classificar os resultados por disponibilidade de estacionamento’ destaca a questão do acesso a dados por trás de APIs pagas ou front-ends suportados por anúncios. As empresas dificilmente fornecerão acesso gratuito a todo o seu conjunto de dados por meio de uma API.
Embora nem todas as empresas integrarão seus dados em agentes de IA, o potencial de combinar várias ferramentas para alimentar fluxos de trabalho permanece significativo.
As empresas que priorizam a manutenção de um fosso de dados provavelmente resistirão a novas tecnologias que ameacem esse fosso.
Se o booking.com tivesse uma API, provavelmente retornaria os mesmos resultados que seu site, possivelmente com formatação JSON ou XML.
Ignorando o Intermediário
Não faz sentido para um intermediário como o booking.com permitir que os usuários ignorem completamente seus serviços.
No entanto, os hotéis individuais podem achar benéfico ignorar o booking.com, um intermediário de quem muitas vezes não gostam.
Uma Deep Research AI poderia procurar hotéis com base em critérios específicos e interagir com servidores Hotel Discovery MCP executados por hotéis individuais, evitando a necessidade de navegar na interface e nos anúncios do booking.com.
Casos de Uso Práticos
O MCP pode facilitar tarefas como buscar logs do Elasticsearch ou consultar bancos de dados de uma forma mais estruturada.
A natureza estática da configuração do servidor MCP, onde novos servidores exigem editar um arquivo .json e reiniciar o aplicativo, pode ser limitante.
Modelos Fine-Tuned
O MCP pode ser visto como um modelo pequeno e ajustado que entende inúmeras ferramentas MCP e escolhe as certas para cada conversa.
Ajustar dinamicamente as ferramentas com base no contexto pode ser necessário para certos cenários.
Conversas Abertas e Problemas de Negócios
O MCP é adequado para sistemas de conversação gerais e abertos, sem um fluxo predefinido. No entanto, não é uma solução única para todos os problemas de negócios. Não se destina a substituir frameworks como o LangChain.
A alternativa ao MCP, um padrão aberto impulsionado pela comunidade, são protocolos fraturados, proprietários e bloqueados pelo fornecedor. Um padrão falho, mas em evolução, é preferível a nenhum padrão.
A melhor maneira de ver o MCP é como uma mudança de desenvolvedores individuais construindo wrappers de clientes em torno de APIs para provedores de API ou wrappers mantidos pela comunidade construindo-os. Isso fornece uma grande caixa de ferramentas, semelhante a NPM ou PyPi. No entanto, orquestração, segurança e definição de uso ainda são necessários.
A próxima geração de Langchains se beneficiará desta caixa de ferramentas maior, mas a inovação ainda é necessária.
Ferramentas Específicas do Usuário
Em alguns casos, as ferramentas podem ser específicas dos dados do usuário, como ferramentas para fatiar e manipular arquivos CSV carregados.
Um problema frequentemente negligenciado é que o MCP pode lotar o contexto do modelo com muitas opções. A priorização e a exposição de metadados são cruciais para evitar o uso desperdiçado de tokens e o comportamento errático do modelo.
Padrões e Tecnologia em Evolução
Novos padrões surgem com o tempo, e já faz tanto tempo que os padrões realmente importam que as pessoas esqueceram como eles se desenvolvem.
Baixar pequenos programas de servidor de desenvolvedores aleatórios para adicionar ‘ferramentas’ a clientes LLM pode ser arriscado.
As questões levantadas são problemas legítimos que o ecossistema MCP precisa abordar. Algumas soluções estarão dentro da especificação MCP, enquanto outras serão externas.
Código Claude e Uso no Mundo Real
Existem opiniões contrastantes sobre o sucesso do MCP. Alguns ouviram histórias de empresas se integrando ao MCP, enquanto outros ouviram de usuários que o acharam decepcionante.
Isso destaca a desvantagem do hype e da adoção precoce.
Alguns desenvolvedores descobrem que as APIs HTTP são superiores ao MCP para a maioria dos casos de uso. Eles argumentam que o uso de ‘ferramenta’ se resume a endpoints de API para capacidades e funcionalidades.
As APIs não são auto-descritivas por padrão, representando uma oportunidade perdida para os proponentes de REST e HATEOAS mostrarem suas abordagens.
MCP como uma Alternativa ao LangChain?
O MCP foi descrito como tendo um ‘cheiro de LangChain’ – não resolvendo um problema urgente, sendo excessivamente abstrato e tendo dificuldade em explicar suas vantagens.
Talvez ele precise dizer ‘FIM DA LINHA’ e banir os aspirantes a hackers para a grade do jogo!
Uma questão fundamental é se o paradigma ‘geral’ do Chatbot persistirá. Aplicativos especializados com suas próprias ferramentas podem não precisar do MCP.
Por outro lado, à medida que os LLMs se tornam mais capazes, as ferramentas externas podem se tornar menos necessárias. Por que você gostaria de um MCP para conduzir o Photoshop quando o LLM pudesse simplesmente editar a imagem diretamente?
O sonho do robô assistente de ficção científica pode não se materializar, e ferramentas especializadas de manipulação de linguagem podem ser mais úteis.
A Base de Usuários e a Conscientização Sobre Segurança
A base de usuários do MCP inclui indivíduos menos técnicos, tornando as questões de segurança particularmente relevantes. Aumentar a conscientização sobre as melhores práticas de segurança é crucial.
Basear Xops em OpenRPC, que exige a definição do esquema de resultados, ajuda a planejar como as saídas se conectam às entradas, melhorando a confiabilidade para fluxos de trabalho complexos.
A tecnologia provavelmente evoluirá e se estabilizará com o tempo.
Redundância e Infraestrutura de Nuvem
Alguns questionam os ganhos do uso do MCP sobre o padrão OpenAPI, vendo-o como redundante.
O que o LLM usará para chamar um sistema OpenAPI? Como ele se conectará ao shell? Como o host do LLM orquestrará isso?
O MCP fornece uma forma estruturada para os LLMs fazerem chamadas de ferramentas.
Os servidores MCP já são servidores HTTP.
A maior vantagem do MCP é para provedores de LLM como o OpenAI, não para desenvolvedores de aplicativos.
Os LLMs são cérebros sem ferramentas, e a chamada de ferramenta os capacita. No entanto, com APIs normais, os provedores de LLM não têm acesso a essas ferramentas. O MCP concede a eles acesso, posicionando-os como a porta de entrada para a IA.
CLI vs. API
Por que não usar o CLI diretamente, dado que os LLMs são treinados em linguagem natural e os CLIs são uma solução comum legível e gravável por humanos?
O MCP surgiu muito rapidamente e precisa de tempo para amadurecer. Ele carece de avaliação por um órgão de padrões convencional e é impulsionado pelo hype.
Há uma falta de aplicações no mundo real.
Aplicações Chave do MCP
O MCP é usado no Claude Desktop e em aplicativos de bate-papo de IA de nicho, ferramentas de automação de código e frameworks de automação de agente/LLM.
É outra tecnologia apressada que provavelmente será descartada quando o próximo acrônimo hype-able chegar.
Existem dois tipos de protocolos de chamada de ferramenta de modelo de linguagem: aqueles dos quais as pessoas reclamam e aqueles que ninguém usa.
Anthropic desenvolveu este ‘padrão’ no vácuo, levando a problemas de segurança.
JSON-RPC 2.0
O MCP é construído em JSON-RPC 2.0, um protocolo leve que permite a comunicação cliente e servidor usando JSON.
Parece uma especificação centralizada projetada para um ecossistema específico, alegando universalidade sem merecê-la.
O MCP é poderoso o suficiente para fazer coisas úteis, o que levanta preocupações de segurança.
Não é um padrão maduro e não foi projetado para ser seguro.
Embora existam recomendações, elas não são aplicadas ou implementadas.
Langchain e Chamada de Ferramenta
Langchain é um dos muitos frameworks que implementam o padrão de ‘chamada de ferramenta’.
O MCP é uma especificação de como as informações externas entram na janela de contexto de um modelo de linguagem, incluindo chamada de ferramenta, entrada modelada, cancelamento, rastreamento de progresso e estado dos servidores de ferramenta.
Ele ajuda a padronizar detalhes para que qualquer combinação de assistente/integração seja compatível.
Embora o MCP tenha problemas legítimos, os críticos devem refinar seus argumentos.
A autenticação é crucial e não deveria ter sido omitida da versão inicial.
Há muitas complexidades.