MCP ignora lições valiosas dos sistemas distribuídos
(julsimon.medium.com)- MCP (Model Context Protocol) se apresenta como padronização para integração de ferramentas de IA, mas tem o problema de ignorar as melhores práticas de sistemas distribuídos e RPC acumuladas em 40 anos
- Isso faz com que, em ambientes corporativos, faltem recursos essenciais como confiabilidade operacional, segurança de tipos, segurança, observabilidade e gestão de custos
- O MCP não apenas depende de bibliotecas externas para funcionalidades críticas; também provoca fragmentação do protocolo, complexidade de integração e aumento da carga de auditoria e segurança
- Rastreamento distribuído, versionamento de schema, descoberta de serviços, otimização de desempenho e outros requisitos operacionais importantes ainda permanecem carentes
- A adoção precoce do MCP pode levar a falhas graves em empresas, com riscos operacionais, desenvolvimento duplicado e gastos desnecessários, impulsionada pela euforia da onda de IA
O risco causado pela simplicidade do MCP
O MCP (Model Context Protocol) se apresenta como o "USB-C do campo de IA" ao promover a integração entre ferramentas de IA e destaca a simplicidade para reduzir a barreira de adoção. Mas essa simplicidade, na prática, ignora as lições acumuladas em 40 anos nos sistemas distribuídos e gera falhas críticas em ambientes reais. Empresas que adotam o MCP agora estão, em essência, construindo sistemas sobre uma base sem funções essenciais de RPC.
A perigosa lacuna entre realidade e expectativas
A defensores do MCP o apresentam como infraestrutura pronta para produção, porém sua filosofia de projeto favorece mais a conveniência de desenvolvimento e carece de robustez operacional. Em curto prazo, é possível conectar ferramentas de IA rapidamente, mas, quando o uso atinge milhões de requisições em operações reais de negócio, as deficiências tornam-se críticas. Devido à expectativa excessiva em torno da IA, a adoção é antecipada sem maturidade arquitetural, aumentando o risco de falha operacional.
Erros repetidos em 40 anos de história
-
UNIX RPC (1982) introduziu XDR (External Data Representation) e IDL (Interface Definition Language) para compatibilidade de dados entre sistemas heterogêneos, como inteiros de 32 bits, detectando erros de incompatibilidade de tipos em tempo de compilação.
O MCP ignora essa experiência e oferece apenas JSON sem schema e dicas não mandatórias. Isso faz com que erros de tipo apareçam em tempo de execução, e a IA gere datas inválidas, podendo causar falhas críticas de conversão de dados e qualidade em setores reais como finanças, saúde e manufatura. -
CORBA (1991) usava o OMG IDL para garantir interfaces consistentes entre linguagens diferentes. No MCP, cada linguagem é implementada separadamente, sem consistência em serialização e tratamento de erros entre linguagens e bibliotecas, criando um pesadelo de integração.
-
REST (2000) alcançou alta escalabilidade e confiabilidade com estado sem estado (stateless), clareza semântica baseada em verbos e cabeçalhos de cache
No MCP, a distinção entre stateful e stateless é ambígua, faltam cache, semântica padronizada de requisição e suporte a idempotência. Isso torna extremamente difícil escalar servidores, fazer retry e balanceamento de carga. -
SOAP/WSDL trazia contratos mecanicamente legíveis, possibilidade de automação e expansão de segurança
O MCP oferece apenas schema JSON simples, com ausência de contratos machine-readable, geração automática, segurança de tipos e trilha de auditoria. O OAuth 2.1 foi adicionado tardiamente apenas ao transporte HTTP, enquanto o stdio depende de variáveis de ambiente, entre outros pontos, deixando o controle de segurança aquém do necessário. -
gRPC (2016) já incorporava observabilidade, rastreamento distribuído, streaming bidirecional, deadlines e códigos de erro estruturados
O MCP só suporta streaming unidirecional do tipo event, sendo ineficiente para interações complexas. Faltam elementos essenciais como contexto de rastreamento, deadline e classificação de erros.
O risco do discurso “use apenas esta biblioteca”
A cada apontamento de falha crítica, o MCP responde com a adição de bibliotecas de terceiros (por exemplo, mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator). Porém, isso trata o fracasso central do protocolo como secundário. Quanto mais funções centrais são distribuídas para fora do protocolo, pioram os problemas de fragmentação, inconsistência e a divisão de responsabilidades de manutenção, segurança e integração.
No ambiente corporativo, a carga de padronização, auditoria e integração cresce em poucos meses, enquanto a dependência externa e o treinamento de desenvolvedores ficam anormalmente altos.
Ajustes paliativos que vão se acumulando
A versão de 2025–03–26 do MCP se parece com notas de patch com correções adicionadas após bugs descobertos em produção. OAuth, gerenciamento de sessão, propriedades de ferramenta (annotation), notificações de progresso, entre outros, são apenas adições tardias de funcionalidades que deveriam ter sido essenciais desde o início.
Inclusão de distinções entre propriedades de ferramentas também não existia no começo, e autenticação de segurança também foi inicialmente tratada como desnecessária. Isso confirma uma compreensão superficial das exigências corporativas.
Pesadelos de depuração e falta de rastreabilidade operacional
eM ambientes gRPC, rastreamento distribuído e trace ID permitem depuração rápida e consistente
Em contraste, no MCP, a ausência de ID de correlação entre requisições, formatos de log inconsistentes e necessidade de implementação própria fazem com que a depuração e rastreamento de erros levem dias
Do ponto de vista operacional e de negócio, também é impossível fazer rateio de custos e gerenciamento de uso (header, contagem de tokens, cotas etc.).
Em nuvem, funcionalidades básicas nem sequer são fornecidas, tornando quase impossível rastrear custo de IA e responsabilidade de uso.
Principais problemas operacionais ainda pendentes
- Ausência de descoberta de serviços impede disponibilidade, expansão multi-região e atualizações sem interrupção
- Falta de versionamento de schema por ferramenta mantém o risco de quebra em toda a base de clientes sem aviso quando uma ferramenta é atualizada
- Limites de desempenho: overhead de JSON, ausência de connection pooling, protocolos binários e compressão insuficientes, além do ressurgimento de padrões antigos como comunicação por processo
Riscos sérios na aplicação corporativa
À medida que a IA entra em áreas com responsabilidade direta por receita, segurança e qualidade (finanças, saúde, manufatura, atendimento ao cliente), o risco da adoção do MCP aumenta. Abandonam-se padrões de integração maduros e robustos por anos construídos, optando por remediações temporárias para aplicar posteriormente segurança, auditoria, segurança de tipos e estabilidade operacional.
Estratégias de "construir rápido e quebrar" em nível de protótipo não têm espaço em serviços críticos, pois podem causar consequências fatais.
Direções de melhoria e requisitos de longo prazo
- Curto prazo: incluir no próprio protocolo segurança de tipos, rastreamento distribuído (ID de correlação), autorização, formato padrão de auditoria e versionamento de schema independente por ferramenta
- Operacional: exigir descoberta de serviços, pool de conexões, transmissão binária, deadlines e políticas padronizadas de erro e retry
- Longo prazo: streaming bidirecional, quota e gestão de custos embutidas, enforcement de SLA, orquestração de workflow e outros recursos de nível empresarial
Conclusão
A orientação para simplicidade do MCP funciona para integração de ferramentas de IA em ciclos curtos e experimentais, mas no ambiente corporativo de produção pode resultar em riscos operacionais críticos e custos elevados.
A adoção avança à frente impulsionada pelo boom de IA, com a repetição de uma prática paliativa: adicionar posteriormente funções essenciais como segurança, observabilidade e estabilidade operacional.
No fim, há risco de que a própria fragmentação e duplicação de desenvolvimento que o protocolo pretende evitar se reproduzam sobre o MCP.
A indústria de IA está numa encruzilhada: repetir problemas já resolvidos pela história de 40 anos dos sistemas distribuídos ou aprender com ela.
Se seguir assim, teremos repetição de adoções fracassadas, falhas de segurança e pesadelos operacionais, e os custos recairão integralmente sobre as empresas.
1 comentários
Opinião do Hacker News
No começo, pelo título achei que seria aquela história típica de show de segurança. Mas, ao ler, fiquei com a impressão de que há uma real perspicácia aqui. Em especial, esse ponto chama atenção: o MCP ignora essa lição e usa dicas não mandatórias em JSON sem schema, com validação de tipos acontecendo em runtime ou então não acontecendo. Por exemplo, se uma ferramenta de IA espera um timestamp ISO-8601 e recebe um valor epoch do Unix, o modelo pode não falhar corretamente e gerar qualquer data. Em serviços financeiros, isso pode levar a uma IA de negociação a interpretar mal números e executar operações com precisão decimal incorreta. Em saúde, pode levar a uma recomendação de dose de medicação errada por conta de conversão incorreta do tipo de dado do paciente. Em manufatura, a perda de precisão durante a serialização JSON de dados de sensores pode virar problema de controle de qualidade. Quem lida com LLM no dia a dia vê isso com frequência. No futuro, vou me comprometer a que, em algum ponto de algum sistema com MCP, vai ocorrer um incidente grande, e ao olhar o registro de falhas vemos o servidor MCP emitindo dados estranhos, a LLM recebendo isso e gerando saída alucinada sem sentido, e essa cadeia levando a problemas cada vez maiores. A combinação do erro humano, da característica do LLM de não ter tratamento de exceção para alucinação e da cultura das startups de subir serviços correndo cria inevitavelmente um novo tipo de bug. Quando isso estourar, usuários do Twitter vão insistir sem parar que uma AGI está hackeando código de lançamento de mísseis, e essa cena também pode ser bem interessante para assistir.
Sinceramente, antes de 2023 eu achava que bugs e falhas tecnológicas de Star Trek eram tão fictícios que parecia impossível acontecerem de verdade. Depois da chegada das LLM, eu sinto que vai acontecer mesmo. Não entendo mais qual a relação da integração de LLM com engenharia e fico em dúvida se é tão razoável colocar o controle de toda a infraestrutura da empresa sob domínio externo. Além disso, considerando a falta de reprodutibilidade, “dar um jeito de qualquer forma” não pode ser chamado de engenharia.
Não entendi bem a crítica que o autor está fazendo. O MCP suporta JSON Schema, então a resposta do servidor deve seguir esse schema. Se um schema exige timestamp ISO-8601 e o servidor envia epoch Unix, isso é uma violação clara do protocolo. No texto, ele diz que, embora o MCP suporte JSON Schema, não se consegue gerar clientes type-safe, mas isso é factualmente incorreto, já que já existem inúmeros geradores de código de JSON Schema.
O PEBKAC (erro do usuário) já existe, e a LLM está só automatizando isso em escala.
Sobre o ponto de que em saúde uma conversão de tipo de dado errada pode causar prescrição médica errada: trabalhando com telemetria médica, senti na prática o quanto é importante parsear timestamp corretamente. Acho que foi por isso que comecei a escrever testes unitários. Em situação sem NTP, tínhamos que recalcular o timestamp do cabeçalho para compensar. Isso foi por causa de revisão de incidentes e de questões de responsabilidade por erro médico. Por exemplo, a diferença entre o horário em que um paciente recebe medicação antes de uma parada cardíaca e o horário depois disso pode definir se alguém vive ou morre. Como no caso recente do correio britânico, um erro de dado pode arruinar uma vida, e em dados de saúde uma diferença de 1 minuto pode virar o mundo.
O objetivo do MCP é transporte e controle de contexto. Ou seja, a responsabilidade por implementar uma interface razoável, como definição e validação de schema, fica com o usuário. É uma crítica parecida com “HTTP não suporta validação JSON” — um ponto óbvio.
O MCP dizendo que vai ser o ‘USB-C do mundo da IA’ é irônico; paradoxalmente, pode ser menos uma façanha do MCP e mais um exemplo dos problemas do USB-C. USB-C quase conecta tudo, mas o cumprimento de padrão é um caos, igual ao parsing inconsistente de JSON e à não conformidade de protocolo do MCP. Como a realidade de vários tipos de cabo USB-C, a aparência de universalidade esconde uma complexidade real. Acredito que APIs/protocolos claramente separados seriam melhores.
Um exemplo extremo da falha do USB-C começou quando a Apple removeu a porta USB-A do novo Mac mini com M4. A porta visualmente igual pode ter desempenho totalmente diferente, e os usuários percebem isso só depois, não na época do anúncio. Antes, nos desktops/laptops Apple Silicon dava para esperar que todas as portas USB-C fossem Thunderbolt de 40 Gbps; agora algumas são USB3 de 10 Gbps. Para saber qual é qual, é necessário olhar a especificação ou um pequeno ícone. Se a Apple tivesse mantido algumas portas USB-A, a limitação de 10 Gbps ficaria explícita, mas em vez disso só diluiu ainda mais o valor de marca do USB-C. No fim, até a maioria dos dispositivos USB-C usa adaptador para conectar em USB-A, e a versão USB-C é mais cara, menos comum e até pior em qualidade. Mas vivemos em um mundo em que hype e fandom superam praticidade e usabilidade.
Sinceramente, ver aquela linha (“USB-C é universal, mas na prática é opaco”) foi bastante engraçado. Objetivo alcançado, digamos assim.
Sobre o SOAP, alguém disse que ele é prolixo, mas entende algo que o MCP não sabe; na prática, o SOAP em si também não era bem compreendido. Aliás, estou em manutenção de sistema SOAP legada e não tenho nada positivo para dizer sobre ele. Vejo-o como algo que não pode servir de modelo para ninguém.
De fato, SOAP foi uma catástrofe enorme. É impressionante como algo que deveria ser simples foi tornado tão complexo. O XML era complexo, além de WSDL e multipart HTTP, com critérios de definição nebulosos e até falhas de interoperabilidade entre linguagens (ex.: experiência de usar SOAP com servidor .NET e cliente Java), etc. Com o tempo, as pessoas lembram só o que era bom, mas eu prefiro ficar 50 anos trabalhando com APIs JSON sem schema do que usar SOAP por um mês. Pessoalmente, acho que protobuf e capnp são muito melhores.
Eu vejo que REST (na prática, JSON-RPC) e GraphQL ainda tentam alcançar funcionalidades que SOAP e SOA davam. Dá para ficar triste com o fato de que, a cada nova tecnologia, jogamos fora até partes boas.
Um protocolo com a palavra ‘Simple’ quase nunca é simples. Tenho a sensação de que logo veremos algo como SMCP.
Compartilho um link com uma explicação de SOAP que é ao mesmo tempo divertida e precisa: https://harmful.cat-v.org/software/xml/soap/simple. Eu gosto de tecnologia baseada em XML, e principalmente acho que a combinação de tipos e validação do XML Schema ainda é inigualável. Mas o SOAP pareceu um monstro sem necessidade. O que se precisava era de uma especificação de chamada remota simples; virou uma especificação que tenta definir tudo e acaba não resolvendo direito nada. O SOAP diz que suporta vários protocolos de transporte (até SOAP over email), vários tipos de RPC, UDDI, e até RPCs de tecnologia própria, mas na prática autenticação, cache e códigos de resposta HTTP, ou seja, os fundamentos da implementação, ficam sob responsabilidade do usuário.
Ironicamente, o que fez com que eu rejeitasse SOAP para sempre foi uma apresentação de tecnologia SOAP que ouvi na época. Entre linguagens iguais, funcionava mais ou menos; quando mudava a linguagem, era o pior cenário. Acho que é por isso que a Microsoft gostou tanto de SOAP.
O CORBA surgiu em 1991 com a percepção de que, em ambientes heterogêneos, não basta implementar um protocolo por linguagem. E faz sentido que o OMG IDL evitasse inconsistência de interface e problemas de serialização criando bindings iguais em múltiplas linguagens. Mas ainda assim fico em dúvida se foi mesmo um caso de sucesso.
O ambiente de APIs centradas em JSON de hoje apareceu como reação ao fracasso do CORBA e do SOAP. Podemos dizer que não esqueceu a lição do CORBA, mas a rejeitou deliberadamente.
Eu já trabalhei em um lugar que usava CORBA muito bem. Acho que o motivo do sucesso ali foi ter um engenheiro sênior com muita experiência em desenvolvimento CORBA dentro da equipe.
Em 1998, me candidatei para um emprego em uma empresa da AT&T que usava CORBA, e esse foi meu último contato (depois disso, só vi download de JDK demorando). Na época, o entrevistador não gostou do meu código concorrente e não consegui convencer sobre condição de corrida, embora ela existisse. Mais tarde, considerando o problema do Java Memory Model, concluiu-se que minha resposta estava certa.
O CORBA acertava em muitas coisas, mas era filho do fim dos anos 80 em redes tradicionais de telecom e na onda de OOP. Então ele embutiu a suposição de rede transparente, confiável e simétrica. Na prática isso não acontece: timeout, retry, congestionamento de rede, crash de sistema etc. Em especial, o binding C++ do CORBA era horrível antes da chegada da STL, e outras linguagens até saíam melhores.
Dá para reconhecer seu mérito técnico mesmo em projetos que foram sucesso técnico, mas fracasso comercial.
A ‘lição principal que o MCP de fato aprendeu’ e que está sendo ignorada na discussão de MCP é que toda funcionalidade avançada acaba introduzindo complexidade e empurra a maioria dos casos reais para escolhas mais simples. Por isso JSON sobre HTTP virou padrão. Mesmo em grandes empresas, migrar para protocolos de serialização avançados como gRPC pode levar anos e pode falhar várias vezes no meio. O papel real do MCP, na minha visão, é padronizar contratos simples de API JSON e facilitar coisas como geração de tokens e de estilo de chamada de tool para LLM.
O MCP não é perfeito, mas aprendeu corretamente uma lição de décadas de história de RPC: que complexidade é o que mais dificulta implantação e uso (semelhante à ascensão de JSON em comparação com XML). O SOAP tornou a interoperabilidade entre sistemas complexa demais, e XML e schema eram verbosos demais. O CORBA era evitado nas linguagens modernas da época por causa da complexidade de suas libs e frameworks. gRPC é rápido, mas reduz legibilidade e exige mapeamento. O esqueleto de RPC hoje é REST e JSON. Os padrões citados foram sendo deslocados, ou o gRPC acabou ficando restrito a necessidades de altíssimo desempenho. REST e JSON são o principal fluxo justamente por essa vitória da simplicidade, e o MCP é uma resposta projetada nessa direção.
Muitos bons comentários. Acho que estamos entendendo mal o MCP. O que é mais importante é o mal-entendido e desalinhamento, de ponta a ponta da indústria, sobre o que é um agent e para onde ele vai. Muitas plataformas web acreditam que o agent está “enterrado” em infraestrutura de rede distribuída, então visam fazer com que todos os agents dentro de container se conectem ao MCP via service mesh. A minha visão é que afirmar que o que deveria ser ‘web-native agent e SDK/framework como aplicação de servidor’ é o caminho certo é errado; isso não é um agent, e nem sequer é uma forma inicial de agent. O verdadeiro harness de agent, acho, só vai ser feito por poucos provedores como Frontier labs, e tende a ir para algo mais pessoal (ex.: um MCP server para Claude Desktop em meu desktop). MCP servers foram feitos originalmente para esse caso de instância única e harness.
Alguém poderia explicar claramente por que o MCP é necessário em vez de Swagger ou proto.
OpenAPI (Swagger) ou Proto (protobuf) não abrangem inteiramente o papel do MCP. Em teoria, dá para colocar MCP acima disso, mas no uso local do MCP a suposição de comunicação do Swagger não encaixa e protobuf, por design, não inclui protocolo de comunicação, exigindo desenho extra. Mesmo que substitua JSON-RPC, no fim é preciso manter quase toda a especificação do MCP e acaba ficando ainda mais complexo.
O MCP é uma tecnologia nova.
O MCP suporta resposta em streaming. Dá para implementar via polling ou estado de sessão, mas isso é uma gambiarra ineficiente.
Quando a OpenAI diz que cobrou $50,000 no mês passado pelo uso de API, não dá para distinguir qual ferramenta MCP de qual departamento gerou esse custo, quais chamadas de ferramenta, usuários ou casos de uso individuais estiveram envolvidos. Em tecnologia de IA, a maior parte do mercado ainda corrige problemas só depois de eles aparecerem. Mas, assim como frameworks web e blockchain, quando a tecnologia é grande demais fica impossível saber tudo perfeitamente no início. A lacuna também tende a reduzir com o tempo. Em IA, concordo que precisamos manter o compartilhamento de ideias e de alerta contínuo. É realmente uma época empolgante.
Quando a escolha é entre um design melhor e um design suficientemente bom, acredito que sempre vence o lado “suficientemente bom”. Dá para citar Multics vs Unix, SOAP baseado em XML vs REST baseado em JSON, o fracasso do xhtml, o próprio JavaScript, e tantos outros. Então me acostumei a assumir que humanos sempre vão reimplementar o “suficientemente bom”, remendando com paliativos quando os problemas aparecem.
Isso é a repetição do fenômeno Worse is Better já bem conhecido (https://en.m.wikipedia.org/wiki/Worse_is_better). Ele continua sendo comprovado várias vezes ao longo do tempo. Eu também sempre tenho tendência a me atrair por “soluções melhores”, mas a realidade nem sempre é assim.
Precisa um minuto de silêncio pelo xforms 2.0. O mundo que poderíamos ter tido: validação de web form que funciona, microdados...