Por que LLMs Precisam de Ferramentas Matemáticas Estruturadas (e Não Engenharia de Prompt)

Os LLMs são notavelmente bons em parecer competentes em matemática. Eles falam sobre fórmulas de juros compostos com confiança. Eles descrevem como o TDEE é calculado passo a passo. Então, eles lhe dão duas respostas diferentes quando você faz a mesma pergunta duas vezes.

Isso não é um problema de alucinação. É um problema de arquitetura — e tentar consertá-lo com prompts é a solução errada.

O Problema: LLMs São Probabilisticamente Inconsistentes

Aqui está um exemplo real. Pergunte ao Claude para calcular uma hipoteca de 30 anos sobre $400.000 a 6,5% de APR:

Tentativa 1: "Seu pagamento mensal seria aproximadamente $2.528."

Tentativa 2: "Você pagaria cerca de $2.533 por mês."

Resposta correta: $2.528,27 (usando a fórmula padrão de amortização)

A diferença é pequena — mas em finanças, isso importa. E o TDEE (Gasto Energético Diário Total) é ainda pior:

Tentativa 1: "Seu TDEE é aproximadamente 2.240 calorias."

Tentativa 2: "Com base nas suas estatísticas, eu estimaria cerca de 2.185 calorias."

O modelo não está fazendo aritmética. Ele está prevendo como uma resposta razoável soa com base em padrões de dados de treinamento. Não é determinístico, e não está chamando uma calculadora.

A engenharia de prompts não conserta isso. "Pense passo a passo" faz o modelo mostrar seu trabalho — mas o trabalho ainda pode estar errado. "Use a fórmula de Harris-Benedict" ajuda, mas você não tem como verificar se realmente a usou corretamente.

A Solução: Trate a Matemática Como uma Consulta de Banco de Dados

Você não pediria a um LLM para "procurar o preço atual da AAPL." Você chamaria uma API. A mesma lógica se aplica a cálculos.

Quando você dá a um LLM uma ferramenta estruturada para um cálculo — uma função que ele chama com entradas específicas e obtém uma saída determinística — a matemática se torna confiável. O trabalho do LLM é entender o que o usuário quer e extrair os parâmetros corretos. O trabalho da ferramenta é calcular a resposta.

Essa é a abordagem MCP (Modelo de Protocolo de Contexto): ferramentas chamadas como funções, com entradas tipadas, entradas validadas e saídas determinísticas.

Calculadoras MCP na Prática

Aqui está como isso se parece em uma configuração real do assistente Claude:

// claude_desktop_config.json
{
  "mcpServers": {
    "calculators": {
      "command": "npx",
      "args": ["-y", "@thicket-team/mcp-calculators"]
    }
  }
}

É isso. Agora, quando um usuário pergunta ao Claude "qual seria meu pagamento mensal em uma casa de $350k?", Claude chama:

calculate_mortgage({
  principal: 350000,
  annual_rate: 6.5,
  term_years: 30
})

E recebe:

{
  "monthly_payment": 2212.24,
  "total_interest": 446406.40,
  "total_cost": 796406.40,
  "amortization_schedule": [...]
}

Toda vez. Determinístico. Verificado por fórmula. Sem deriva probabilística.

Ferramentas Atuais no Pacote

Na versão v1.0.0, @thicket-team/mcp-calculators inclui:

Todas as ferramentas têm:

• Definições de tipo TypeScript
• Validação de entrada (rejeita coisas sem sentido como idades negativas)
• Cobertura de testes unitários (mais de 500 testes em todo o pacote)
• Saídas determinísticas — mesmas entradas, mesma resposta, toda vez

Por que isso é melhor que o Fine-Tuning

Você pode pensar: "basta ajustar o modelo em matemática." Mas:

1. Ajustar é caro — e você precisaria reajustar com cada nova versão do modelo
2. Ajustar melhora médias, não consistência — o modelo ainda tem variância em casos extremos
3. Ferramentas se compõem melhor — uma ferramenta de hipoteca estruturada funciona no Claude, GPT-4, Gemini, Mistral, em qualquer lugar que suporte chamadas de função

Ferramentas estruturadas lhe dão determinismo hoje, em qualquer modelo, com custo zero de treinamento.

Começando

npm install @thicket-team/mcp-calculators

Ou use diretamente no Claude Desktop sem nenhum código:

{
  "mcpServers": {
    "calculators": {
      "command": "npx",
      "args": [