Curiosidades

O que a gente mediu
e não esperava.

Todo experimento aqui existe para responder a uma pergunta prática. Às vezes a resposta contraria o que a gente apostava — e esses são os achados que valem contar. Inclusive quando desmentem o próprio site.

A regra desta página: nenhum número entra sem n, modelo, data e método. E cada achado carrega a lista do que ele não prova — porque é aí que benchmark costuma virar propaganda.
01 "Meu agente precisa de MCP ou uma API resolve?"

MCP não é necessário. É que sai bem mais barato.

Rodamos 144 agentes de verdade (Claude Code em modo headless) resolvendo as mesmas 8 tarefas sobre o mesmo backend de ticketeria. Só uma coisa mudava: como o agente alcança o sistema — pelas ferramentas MCP, ou por curl contra a API REST equivalente, descobrindo os endpoints pelo spec OpenAPI ou já com a documentação colada no prompt.

A expectativa era ver o braço sem MCP falhar. Não falhou. Os três chegam ao resultado praticamente sempre — a diferença aparece na conta: com MCP o mesmo trabalho custa cerca de metade do braço OpenAPI, com 3 a 5 vezes menos tokens e nenhuma chamada falhada no caminho.

Modelo
Todos concluem a tarefa
Sucesso conferido no banco de dados depois de cada execução — não no que o agente diz que fez — incluindo checagem de dano colateral. O traço fino é o intervalo de confiança de 95% (Wilson): onde eles se sobrepõem, não há diferença demonstrada.
Mas não pelo mesmo preço
Média por execução, sobre as 8 tarefas. O número cinza é o multiplicador em relação ao MCP.
E não sem tropeçar
Execuções em que ao menos uma chamada falhou (HTTP 4xx, comando de shell com erro, ou erro de ferramenta MCP) — mesmo quando o agente se recuperou e concluiu a tarefa. Fora da conta: a T7, onde o erro faz parte do enunciado, e as falhas causadas pelo shell do Windows, que num agente em Linux não existiriam. O número bruto aparece ao passar o mouse.
Ver tarefa por tarefa
n = 144 execuções · 24 por braço e modelo modelos claude-sonnet-5 · claude-haiku-4-5 data 19/09/2026 método 3 repetições · ordem sorteada · banco resetado a cada execução verificação estado do banco, sem LLM-juiz
O que este experimento não prova
  • Que agentes precisam de MCP. Em capacidade de concluir a tarefa os três braços empatam dentro da margem de erro. Um agente com shell, curl e documentação razoável chega lá.
  • Que API sempre gasta mais turnos. Com a documentação no prompt, o Sonnet usou menos turnos que no MCP — no shell ele encadeia várias chamadas num único comando, enquanto no MCP cada chamada é um turno.
  • Nada sobre muitos servidores conectados. Aqui são 8 ferramentas, e o custo fixo dos schemas é pequeno. Com dezenas de servidores MCP ele cresce — e isso não foi medido.
  • Generalização. Um domínio (ticketeria), um harness (Claude Code), shell Windows no braço API e 3 repetições por célula. As diferenças de custo e tokens são grandes e consistentes; as de taxa de sucesso, não.

As duas únicas falhas saíram do mesmo erro, e ele é instrutivo: o agente mandou ?status=open&status=pending, o REST aceitou em silêncio usando só o último valor, e ele respondeu com confiança sobre o ticket errado. O schema tipado de uma ferramenta MCP não permite escrever essa chamada. Foram 2 casos em 144 — sinal, não prova.

02 "E se a gente medir o nosso próprio medidor?"

Nossa probe dava 100% de acerto em ruído puro.

O módulo 2 treina uma linear probe sobre vetores de ativação para prever uma pergunta binária: "o agente acertou esta instância?". Havia dois defeitos empilhados. O primeiro: a probe era avaliada no mesmo conjunto em que treinava — e com 50 parâmetros para 30 amostras, decorar é trivial. Não é "quase 100%" por sorte; é 100% por construção.

O segundo era o rótulo na tela. A linha que imprimia "Origem: ⚡ Llama real" lia o modo que o usuário pediu no seletor, não o que de fato tinha rodado. Bastava escolher "real" para a tela anunciar Llama sobre ruído gaussiano. E a docstring da função se contradizia em uma linha só: "acurácia no treino (leave-one-out simplificado)" — acurácia no treino não é leave-one-out. O comentário dizia a verdade; o rótulo mentia.

Com validação cruzada 3-fold estratificada, medindo fora da amostra, o ruído cai para perto do acaso — que é o resultado honesto — e o sinal limpo se mantém em 1,000. O número bonito de antes era a probe decorando, não descobrindo.

$ probe antiga (pontua no proprio treino) --entrada ruido_puro --sementes 5 tamanho acuracia por semente media n=30 1.000 1.000 1.000 1.000 1.000 1.000 ← 100% em ruido n=40 1.000 1.000 1.000 1.000 0.975 0.995 n=60 0.917 0.983 0.950 1.000 0.833 0.937 ! 50 parametros para 30 amostras: o 1.000 e por construcao $ probe nova (validacao cruzada 3-fold, fora da amostra) ruido puro 0.533 ← acaso = 0.500, como deveria sinal limpo 1.000
métrica acurácia (não AUC) · acaso com classes balanceadas = 0,500 entrada ruído N(0,1) sem relação com o rótulo probe 50 das 2048 dimensões do vetor n = 30 / 40 / 60 · 5 sementes cada correção commit 0c08b51 — "fase 1: parar de enganar"
O que este achado não é
  • Não é "a plataforma lia o Llama errado". Essa página nunca leu ativação de modelo nenhum: o ramo "real" era código morto — testava um nome que não existe, então dava sempre falso — e os dois modos geravam o mesmo ruído sintético. O erro foi de rótulo e de avaliação, não de leitura.
  • Não desqualifica a técnica. Linear probe sobre ativações é método legítimo e publicado. O defeito era da nossa avaliação.
  • O 0,533 não é constante. Ele varia com o tamanho da amostra e a semente: o que o dado sustenta é "perto do acaso", não esse decimal. Só o 1,000 do sinal limpo é firme.
  • A página ainda não lê o seu modelo. O hook de verdade (hook_resid_post via TransformerLens) precisa dos pesos e roda num script local — o site mostra simulação didática, e agora diz isso.

Fica aqui porque é o achado mais desconfortável do projeto: quem constrói a ferramenta de medir é quem tem mais facilidade em se enganar com ela. A regra desta página — citar n, modelo, método e o que não se prova — nasceu deste episódio.

03 "Qual arquitetura de agentes é melhor na minha tarefa?"

Quando todos acertam tudo, "melhor" deixa de ser sobre qualidade.

Numa tarefa operacional real de triagem de cobrança, três arquiteturas foram medidas com o mesmo modelo de raciocínio. As três acertaram os 24 casos — score 1,000 em todas. O score, que é a métrica que todo mundo olha primeiro, não decidiu nada. Quem decidiu foi token e latência: a arquitetura mais simples fez o mesmo trabalho por menos da metade dos tokens e em um terço do tempo.

$ avaliar --tarefa triagem_cobranca --casos 24 --seed 42 arquitetura score tokens latência sas 1.000 700 23.2s verificador-precedencia 1.000 1 517 67.0s cascata-de-regras 1.000 1 701 59.8s ! score satura: empate em 1.000 → decide quem gasta menos: sas, 2,2x menos tokens
n = 24 casos · 1 execução (sem repetição) modelo gemma-4-31b-it seed 42 tarefa triagem_cobranca
O que este experimento não prova
  • Nada com significância estatística. É uma execução, sem repetições e sem desvio-padrão. Serve para orientar a próxima rodada, não para fechar questão.
  • Que SAS é a melhor arquitetura. O que a tarefa mostrou é que esta tarefa satura com um modelo de raciocínio. Numa tarefa que não sature, o score volta a decidir — e a resposta pode inverter.
  • Que multi-agente é desperdício. Só que, quando o score empata, o custo extra fica sem contrapartida visível nesta medição.
04 "O MCP público do OTM funciona de fora mesmo?"

Testar como cliente de verdade achou o que o teste interno não achava.

O servidor MCP do OTM passou a ser verificado por um cliente MCP real, contra a URL pública, e não por chamada interna simulada: conexão, catálogo de ferramentas, prompts e o repasse de chave BYOK por header. 14 de 14 ferramentas respondem. O caminho até lá incluiu um HTTP 421 que só aparece quando a requisição chega pelo domínio público — exatamente o tipo de falha que teste local não encontra.

verificação 14/14 · testar_mcp.py superfície 14 ferramentas · 5 prompts · 3 recursos alvo URL pública em produção inclui repasse de chave BYOK por header
O que isso não é
  • Não é benchmark. Diz que o servidor funciona como cliente nenhum havia testado antes — não diz que é rápido, barato ou melhor que alternativa.
  • Não cobre o backend inteiro. O deploy do backend e o do frontend seguem ciclos separados, e já ficaram fora de sincronia antes.

Quer ligar seu próprio agente? O mcp.json está na página inicial, na seção "Para agentes" — a chave é sua, e não fica guardada no servidor.