Agentes se comportam de forma diferente via MCP e CLI, e o método DART rendeu até +9 pontos

Quando um agente de IA usa ferramentas, ele não enxerga as capacidades "em estado puro", mas a descrição delas: ou como um conjunto de funções pelo protocolo MCP (Model Context Protocol, padrão de conexão de ferramentas a um modelo de linguagem), ou como comandos no terminal, isto é, a CLI. A equipe do ModalityDance (Zhenning Shi, Liang Pang, Yongqi Li) fez uma pergunta direta: se as capacidades são absolutamente iguais e só muda a maneira de apresentá-las ao modelo, o comportamento do agente muda? A resposta é sim, e muito.

Divergiram a qualidade na resolução das tarefas, o consumo de tokens (as unidades de texto pelas quais se paga ao usar um modelo) e até a forma como o agente erra e se recupera dos erros. Os autores também propuseram o método DART, que melhorou os resultados nas seis configurações testadas, em até 9,0 pontos.

Como tornar a comparação justa

Normalmente, MCP e CLI são comparados "como estão". Assim, fica difícil saber o que de fato influenciou o resultado: a interface em si ou o fato de uma ter ferramentas mais ricas e a outra ser implementada de forma diferente. Para eliminar essa confusão, os autores construíram o MICA (Matched Interface Comparison and Analysis, "comparação e análise de interfaces equivalentes").

Ele funciona assim:

• existe um contrato único de ações semânticas: a lista do que o agente pode fazer; • desse contrato são geradas automaticamente duas versões: MCP e CLI; • seja qual for a escolha do agente, a ação é decodificada e enviada ao mesmo código de execução.

Ou seja, por baixo do capô as capacidades são totalmente idênticas. A diferença fica só na "vitrine": como as ações são descritas, como devem ser escritas e como é a resposta do ambiente. Os testes foram executados em seis modelos e em três ambientes interativos.

Onde os caminhos do agente se separam

Primeiro resultado: o desempenho e o custo da interação variam de forma significativa. E não se trata apenas de erros de sintaxe, quando o agente escreve a chamada errada. A interface influencia qual ação o agente escolhe em termos de significado, como ele falha e como se recupera depois de um erro.

Para encontrar a origem dessa sensibilidade, os pesquisadores usaram duas abordagens.

• Sondagens com estado idêntico. O agente era colocado na mesma situação, e três fatores eram alterados separadamente: como as capacidades são apresentadas, como a ação é escrita e como o retorno é devolvido. Assim foi possível ver qual das três partes mais desorienta o modelo. • Trajetórias naturais pareadas. O agente resolvia a mesma tarefa via MCP e via CLI. Em 2004 episódios, houve divergência estrutural em 94,3%, ou seja, em cerca de 1890. As diferenças iniciais não se dissipavam, e sim se propagavam: um passo mal dado no começo alterava todo o restante da interação.

A conclusão dos autores é que a interface faz parte do ciclo fechado de tomada de decisão. O agente age, recebe uma resposta, decide de novo, e a forma da resposta e do registro da ação influencia cada passo seguinte. Ela não é um invólucro neutro em volta do modelo.

DART: corrigir a escrita do comando, não a decisão

Como a divergência surge na etapa de "realização" da ação, é ali que ela pode ser corrigida. O método DART (Decoupled Action Realization and Targeted Repair, "realização desacoplada da ação e correção pontual") divide o trabalho em duas partes. Primeiro, o agente define o que exatamente quer fazer. Essa decisão semântica é verificada e preservada. Depois, uma etapa separada cuida de como escrever essa decisão na linguagem da interface específica e, se houver erros, corrige apenas esse registro. O significado da ação escolhida não é reavaliado.

O efeito, segundo os números divulgados:

• a pontuação nos benchmarks subiu nas seis configurações testadas (modelo mais ambiente), com máximo de 9,0 pontos; • o custo do MCP caiu nos três ambientes, com máximo de 27,1 mil tokens por tarefa.

O segundo número é importante para o orçamento. As descrições de ferramentas e as respostas do MCP costumam ser prolixas, e precisam circular pelo contexto a cada passo. Se parte do trabalho não é repetida, o consumo cai de forma considerável.

O que isso significa para engenheiros

O debate "MCP contra CLI", nesses termos, perde o sentido: não é possível definir um vencedor sem controlar como a interface é implementada. O mesmo modelo, com as mesmas ferramentas, pode parecer mais forte ou mais fraco dependendo da forma de apresentação.

Conclusões práticas:

• ao comparar modelos e frameworks de agentes, fixe a interface e descreva-a no relatório; caso contrário, os números não são comparáveis; • vale analisar as falhas do agente por níveis: ele errou na escolha da ação ou apenas na escrita da chamada; • se você constrói um agente sobre MCP e paga por tokens, faz sentido separar a decisão semântica da sua formatação e corrigir apenas a formatação.

As limitações também são visíveis: o estudo abrange seis modelos e três ambientes, então é preciso cautela ao transpor os números para qualquer outro conjunto de tarefas. O código e a página do projeto são abertos (repositório ModalityDance/MICA no GitHub), de modo que é possível verificar os resultados com os seus próprios agentes.