Raft Analisou Onde MCP e Thin MCP Adicionam Latência a Agentes de IA

MCP é frequentemente apresentado como uma forma universal de conectar ferramentas de forma limpa às aplicações LLM, mas na prática essa modularidade tem um custo de latência. Em uma nova análise, Raft comparou várias arquiteturas e mostrou que o problema geralmente não está em um componente específico, mas em como o caminho da solicitação do agente até a ferramenta e vice-versa é estruturado em geral.

Onde nasce a latência

O autor começou com uma pergunta básica: quanto de latência o próprio MCP adiciona se você remove a rede e mantém tudo em um único processo. Para isso, compararam um monólito sem MCP e um monólito com MCP in-process. Descobriram que o padrão em si adiciona uma sobrecarga relativamente pequena — em média cerca de 10–11 ms, às vezes até 35 ms. Este é um ponto de referência importante: se um agente é lentificado por centenas de milissegundos, geralmente o culpado não é o uso do MCP em si, mas a camada externa ao seu redor.

Em seguida, moveram a comparação para uma arquitetura mais realista, onde os servidores MCP são implantados em contêineres Docker separados. Aqui a situação muda notavelmente: a latência adicional média para ferramentas principais cresceu para cerca de 169 ms por chamada. Ao mesmo tempo, os rastreamentos mostraram que até isso não é o principal consumidor de tempo. As partes mais pesadas são obtenção de embeddings e trabalho de reranker, enquanto a busca em banco de dados vetorial leva relativamente pouco. Em outras palavras, MCP adiciona um custo, mas nem sempre é o principal gargalo de toda a cadeia.

O que os testes revelaram

O artigo analisa vários cenários para separar os efeitos do transporte, serialização e tempo de execução em si.

• S1, MCP in-process: cerca de 10–11 ms de latência adicional, significando que o tempo de execução em si é relativamente leve.
• S2, MCP separado pela rede Docker: cerca de 169 ms de sobrecarga por chamada em média devido à rede, serialização e comunicação entre processos.
• S3a, Thin MCP por HTTP + JSON: em uma série de medições, a sobrecarga caiu para cerca de 128 ms, mas o resultado se mostrou instável e poderia ser notavelmente pior em execuções repetidas.
• S3b, Thin MCP por HTTP + YAML: latência aumentou para cerca de 274 ms, indicando um custo adicional de serialização e desserialização.
• S4 e S5: ZeroMQ teve cerca de 200 ms, mas com comportamento mais previsível, enquanto o tempo de execução C++ reduziu a sobrecarga para cerca de 130–145 ms sem uma mudança radical em magnitude.

A principal conclusão desses números é que otimizações intuitivas nem sempre funcionam como esperado. Substituir JSON por YAML não acelerou o sistema, mas o piorou. Mudar de HTTP para IPC também não deu ganhos automáticos: a implementação em iceoryx2 não mostrou a melhoria esperada, e apenas o ZeroMQ se mostrou praticamente mais útil devido ao seu modelo assíncrono. Até C++ ajudou moderadamente, não dramaticamente.

Por que thin não salva

Thin MCP no artigo não parece um botão mágico de aceleração, mas uma forma de simplificar a arquitetura. Neste esquema, a camada proxy permanece mínima e apenas traduz chamadas, enquanto a lógica de negócio vai para serviços HTTP separados. Esta abordagem oferece independência de linguagem, simplifica o escalonamento e permite escrever executores em Go, Rust ou C++, mesmo que um SDK MCP completo ainda não exista para eles.

Thin MCP é mais uma ferramenta arquitetônica do que um método de

otimização de latência.

A nuance prática é que a abordagem thin pode parecer mais rápida em uma execução, mas não se reproduz estivelmente em outra. Para um sistema em produção, isso é crítico: às vezes um comportamento previsível sob carga repetida é mais importante do que um p95 único mínimo. É por isso que Raft faz uma conclusão bastante severa, mas útil: se você quer realmente acelerar um agente de IA, não é apenas mudar a linguagem ou protocolo, mas reconstruir o esquema de interação entre proxy, componentes backend e etapas computacionais pesadas.

O que isso significa

Para equipes que constroem agentes de IA, isso é um bom antídoto contra otimização superficial. Se o sistema é lento, você deve primeiro considerar o número de transições entre componentes, operações bloqueantes, o modelo de execução concorrente e etapas pesadas como embeddings e reranking. Thin MCP pode tornar um sistema mais limpo e flexível, e C++ ou IPC podem fornecer ganhos adicionais, mas o efeito decisivo aparece apenas quando a própria arquitetura deixa de executar solicitações através de camadas desnecessárias.