Por que Rejeitamos uma Economia de 96% de Tokens

Encontramos um servidor MCP que economiza 96% de tokens. Ele utiliza apenas uma ferramenta: execute_code. Em vez de chamar funções específicas, o agente escreve JavaScript para obter dados.

No papel, ele vence. Para tarefas complexas, a execução de código supera a chamada de ferramentas em termos de eficiência.

Mas não o adotamos. Em vez disso, mantivemos nossas ferramentas discretas e nomeadas.

Aqui está o porquê de a escolha óbvia ter sido a escolha errada para o nosso agente.

O Alvo Determina o Design

A maioria das pessoas constrói para modelos de fronteira em uma janela de chat. Esses modelos possuem orçamentos de tokens enormes. Para eles, a execução de código é soberana.

Nós construímos para um agente focado em voz, rodando em um modelo local pequeno (Hermes 3 8B) em um barco.

Para um modelo pequeno, a restrição não são os tokens. A restrição é a confiabilidade.

Se um modelo pequeno tem dificuldade para chamar uma ferramenta simples, pedir que ele escreva um JavaScript correto é uma tarefa muito mais difícil. O execute_code troca confiabilidade por tokens. Não podemos nos dar ao luxo de fazer essa troca.

O Problema da Última Milha

A execução de código transfere a "última milha" do trabalho para o agente. O agente deve:

• Filtrar os dados
• Ordenar os resultados
• Formatar a saída

Nossas ferramentas realizam esse trabalho dentro do servidor. Por exemplo, ao perguntar sobre o estado da bateria, nossa ferramenta retorna uma string pronta para text-to-speech. Ela diz "68 por cento, 12,8 volts" em vez de números brutos.

Se usarmos o execute_code, o agente terá que escrever a lógica para formatar essa fala. Modelos pequenos falham nisso constantemente.

A Regra da Ausência

Em um barco, sensores ficam offline. Em nosso sistema, um sensor ausente retorna um null limpo. Isso é uma chamada bem-sucedida.

Em um modelo de execução de código, um sensor ausente geralmente gera um erro. Se um modelo pequeno tentar alguns caminhos errados, ele aciona limites de erro e quebra o agente. Ferramentas nomeadas nos permitem transformar a ausência em um sucesso, não em uma falha.

Checklist: Adotar vs. Construir

Antes de adotar ou construir um servidor MCP, faça estas perguntas:

• Quem é o agente alvo? (Modelo de fronteira vs. Modelo local pequeno) • Qual é a restrição principal? (Tokens vs. Confiabilidade) • Quem faz a última milha? (A ferramenta formata os dados ou o agente?) • Como ele lida com a ausência? (Um valor ausente é um erro ou um null?) • Qual é o custo de manutenção? (Você está herdando uma base de código dormente?)

Não ignoramos o outro projeto. Colhemos suas ideias. Pegamos o tratamento de alarmes e a lógica de descoberta de caminhos deles e os adicionamos ao nosso roadmap.

Eficiência é ótimo, mas confiabilidade é obrigatória quando você está na água.

Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optional learning community: https://t.me/GyaanSetuAi