Por que mantivemos ferramentas MCP nomeadas apesar de uma economia de 96% em tokens

A pilha do boat-agent aqui opera sob uma diretiva principal: se há algo utilizável por aí, melhore-o; construa o seu próprio apenas como último recurso. Então, quando precisávamos de um servidor MCP SignalK, o primeiro movimento honesto não foi escrever um — foi avaliar o que já existe.

VesselSense/signalk-mcp-server (TypeScript, MIT) é um bom trabalho. Ele expõe o SignalK a um agente através de uma única ferramenta execute_code: o modelo escreve JavaScript, o servidor o executa em um isolate V8 isolado (isolated-vm), e apenas o resultado retorna. Seu README afirma uma redução de 90–96% nos tokens em comparação com ferramentas MCP nomeadas tradicionais — 2.000 tokens reduzidos para 120 em uma consulta de estado do barco, 13.000 reduzidos para 300 em um fluxo de trabalho de múltiplas chamadas. Esses números são plausíveis e se alinham com o resultado mais amplo da indústria de que a execução de código supera a chamada de ferramentas em eficiência de tokens para trabalhos complexos de múltiplas etapas.

Lemos, rodamos os números contra nosso próprio agente e mantivemos nossa ferramenta nomeada discreta signalk-mcp mesmo assim — então colhemos três das ideias da VesselSense para nosso roadmap. Este post é essa avaliação: as duas filosofias, por que a vitória que parece óbvia não se aplica a um agente voltado para voz e uma estrutura de decisão que você pode reutilizar antes de adotar ou construir seu próprio servidor MCP.

Este é um post de raciocínio de design, não uma saga de depuração, mas mapeia o mesmo arco: uma pergunta, o beco sem saída que parece um sim óbvio, e a decisão que realmente se manteve.

A pergunta

Dois servidores MCP SignalK, dois designs genuinamente diferentes:

VesselSense/signalk-mcp-server      sailingnaturali/signalk-mcp
─────────────────────────────       ───────────────────────────
one tool: execute_code              discrete named tools:
  → agent writes JavaScript           read_sensor(path)
  → runs in a V8 isolate              battery_state(bank)
  → queries SignalK, returns          depth_state()
    only the result                   get_route()
                                      get_local_time()
TypeScript / Node + isolated-vm       list_paths(prefix)
claims 90–96% fewer tokens            get_active_alarms()
                                    Python, end-to-end

A questão de adotar ou manter: a vitória em eficiência de tokens se aplica ao nosso agente? Se sim, adotar é melhor do que manter um segundo servidor. Se não, a diretiva não obriga a adoção — obriga a construir a coisa certa para o alvo.

O alvo importa mais do que qualquer outra coisa aqui. Nosso âncora de design é um agente voltado para voz em um pequeno modelo local — Hermes 3 8B dirigindo uma interface de texto para fala em um barco. Não um modelo de fronteira em uma janela de chat. Esse único fato decide toda a avaliação.

Duas filosofias válidas, alvos diferentes

execute_code é inteligente, e a matemática dos tokens é real. Quando um agente precisa buscar cada alvo AIS, filtrar para os próximos, classificar por CPA e formatar um resumo, o padrão de ferramenta nomeada paga o custo total de entrada + saída de cada chamada intermediária — o modelo emite uma chamada estruturada, todo o resultado flui de volta ao contexto, repete. A execução de código colapsa isso em um único script e um resultado agregado. Em um modelo de fronteira fazendo consultas marinhas complexas e de múltiplas etapas, a afirmação de 90–96% é crível.

Mas a economia é paga em uma moeda: o agente deve escrever código correto de forma confiável. Esse é um preço barato para um modelo de fronteira e um caro para um 8B. A diferença de capacidade aqui não é sutil. Do campo:

Modelos pequenos como llama3.2:3b e llama3.1:8b suportam especificações de chamada de ferramentas, mas falham de forma inconsistente na prática, especialmente em comandos sequenciais ou de múltiplas entidades… A chamada de ferramentas é a maior diferença de capacidade entre modelos locais e em nuvem — a tubulação existe, mas a confiabilidade do modelo ainda não.

Se um modelo pequeno é instável ao emitir uma chamada de ferramenta estruturada, pedir-lhe para emitir JavaScript correto é estritamente mais difícil. execute_code não reduz o ônus do modelo para nosso agente — ele o aumenta. O orçamento de tokens nunca foi nossa restrição vinculativa; a confiabilidade é.

Então a comparação não é "qual design é melhor." É:

• Modelo de fronteira, consultas complexas, orçamento de tokens é a restrição → execute_code vence. Adote a VesselSense.
• Modelo local pequeno, interface de voz, confiabilidade é a restrição → ferramentas nomeadas discretas vencem. Uma ferramenta nomeada com um argumento — battery_state("house") — é a coisa mais robusta que você pode entregar a um 8B. Ele não pode errar o JavaScript porque não há JavaScript.

Ambos estão corretos. Eles são ajustados para diferentes agentes.

Por que a vitória em tokens não se aplica #1: o contrato de fala

Aqui está a parte que a comparação de tokens silenciosamente ignora. Nossas ferramentas não retornam SignalK bruto — cada valor carrega uma string display segura para TTS que o agente pode falar literalmente. O SignalK armazena tudo em unidades SI e códigos concisos; um mecanismo TTS pronuncia mal tudo isso. Nosso contrato de resposta torna a forma falada um campo de primeira classe:

{
  "path": "environment.wind.speedApparent",
  "value": 8.5,
  "display": "16.5 nós",
  "unit": "nós",
  "timestamp": "2026-05-18T00:00:00Z"
}

{
  "bank": "house",
  "soc_fraction": 0.68,
  "voltage": 12.84,
  "current": -8.2,
  "display": "68 por cento, 12.8 volts, 8.2 amps descarregando",
  "timestamp": "2026-05-14T18:00:00Z"
}

As regras por trás desse displ