
Quão errado está um modelo sobre uma empresa quando não há registro para verificar?
registry-mcp coloca três registros nacionais de empresas por trás de uma ferramenta MCP — Brønnøysundregistrene / Enhetsregisteret (brreg) pelo organisasjonsnummer (orgnr, org.nr), Companies House pelo número da empresa, e Bolagsverket pelo organisationsnummer. A proposta sempre se baseou em um contrafactual: sem um registro, um agente responde perguntas sobre a empresa de forma confiante e errada. Isso é fácil de afirmar em um README. Em 2026-09-10, medimos isso, e a resposta não é a que a proposta teria escolhido.
A configuração
Duas partes, um modelo — claude-sonnet-5 — no mesmo dia, sobre os mesmos prompts escritos à mão.
- Com as ferramentas: 31 casos elaborados, três testes cada.
-
Sem elas: os 15 desses 31 que são justos para perguntar sem ferramentas — um caso sobre qual ferramenta escolher é sem sentido quando não há nenhuma — perguntados verbatim, com
toolsesystemomitidos da chamada da API completamente. Três testes cada, totalizando 45 chamadas.
Sem um registro: 45 respostas
Chamada por chamada, auditada manualmente: 8 corretas, 3 erradas (confiantes, perigosas), 34 hedges, 0 pouco claras.
Os hedges são a parte que ninguém teria colocado em um slide. Por caso, o modelo hedgeou em cada único teste para 9 dos 15 (60%) — "não consigo verificar um registro ao vivo", e nada mais. Ele estava confiantemente e perigosamente errado em pelo menos um dos três testes para 2 de 15 (13%), e produziu uma resposta correta, mas sem fonte em pelo menos um teste para 4 de 15 (27%).
Então, a versão honesta da nossa própria proposta é: um modelo atual na maioria das vezes se recusa. Ele não mente na maioria das vezes. Essa recusa é um bom comportamento, e não a pontuamos como uma vitória para o produto — vencer um modelo que já disse "não sei" não é vencer nada.
Duas advertências pertencem a esses números em vez de em uma nota de rodapé. Primeiro, essa é a contagem auditada, não a do harness. A primeira passagem bruta do classificador automático foi 6 corretas, 7 erradas, 27 hedges, 5 pouco claras; a leitura manual moveu 12 das 45 chamadas, cada uma delas um modo de falha que este projeto já havia nomeado uma vez — o classificador não consegue distinguir uma afirmação sobre esta empresa das mesmas palavras usadas genericamente, como em "status (ativo, dissolvido, etc.)". Segundo, três testes suavizam o ruído da amostragem. Isso não o remove.
Os três que estavam errados
"3 de 45" é abstrato. Estes não são.
Em um teste, perguntado o que uma empresa norueguesa devia a seguir, o modelo inventou um conjunto de obrigações detalhadas sem hedge em nenhum lugar: um SEC Form 20-F "devido ... até 30 de abril de 2026", um lançamento do Oslo Børs Q4 "início de fevereiro de 2026". Nenhum é o prazo norueguês derivado do registro sobre o qual o caso trata. O real é 2026-07-31.
Em dois dos três testes, perguntado sobre o número de funcionários, o modelo se isentou de acesso ao registro e então deu "330.000–360.000 funcionários" de qualquer forma, como conhecimento geral. Um caveat seguido por um número específico é exatamente a forma que um pipeline de agente remove o caveat.
Com o registro: duas respostas em três
Mesmo modelo, mesmo dia, ferramentas anexadas. 18 dos 31 casos passaram diretamente (58%) sob a regra estrita do harness, que exige que todos os três testes concordem antes que um caso conte como aprovado. Quatro dos 31 nunca são pontuados — dois são casos de fumaça apenas ao vivo pulados por design, dois atingem uma lacuna na cobertura simulada que não tem nada a ver com o modelo — então, contra os 27 casos realmente elegíveis, isso é 18/27 (67%).
Antes que a regra estrita seja aplicada, as taxas brutas por teste foram 19/27 (70%), 23/27 (85%) e 20/27 (74%), uma média de 62/81 (77%). O melhor teste e o pior teste estão quatro casos de distância, em casos idênticos com nada mais mudado. É por isso que a regra estrita existe, e por que um teste de qualquer coisa não é evidência.
A falha que mantemos de propósito
Um caso é mantido falhando deliberadamente, e é a linha mais útil do relatório. Perguntado se uma empresa do Reino Unido está registrada para VAT, o modelo chamou search_company para confirmar a identidade da empresa, então respondeu "Companies House ... não publica dados de registro de VAT" — correto, e nunca verificou contra o campo real vat_registered: null desse registro. O resultado da busca não contém nenhum campo de VAT, então a única maneira de responder a isso a partir da ferramenta é procurar a empresa e ler o nulo. Taxa de aprovação: 1 de 3.
A parte sem ferramentas encontrou o mesmo comportamento do outro lado no mesmo dia. Nesse mesmo caso, respondeu "Sim, Tesco PLC está registrado para VAT ... uma vez que seu faturamento tributável excede muito o limite" — confiante, razoado, sem fonte. A mesma forma de resposta; um deles apenas tinha uma ferramenta disponível para pular.
Que é a coisa que um registro realmente compra, e não é precisão. É proveniência: a diferença entre uma resposta que acontece de estar certa e uma resposta com um registro por trás dela.
O que isso não afirma
- 31 casos elaborados à mão. Nós os escrevemos. Não é um benchmark público, não é uma amostra aleatória do que alguém realmente pergunta.
-
Registros simulados. Cada caso offline roda contra
tests/fixtures/*.json, não os registros ao vivo. Isso mede se um modelo usa a superfície da ferramenta corretamente — não a qualidade, cobertura ou tempo de atividade dos próprios dados de brreg, Companies House ou Bolagsverket. - Um modelo, um dia, três testes. Não é uma comparação entre modelos.
A frase de advertência a ser levada é a própria do relatório: isso mede se um modelo nomeado, em um dia, respondendo 31 perguntas que alguém escreveu à mão contra dados simulados, usa essa ferramenta corretamente e sabe a diferença entre "o registro diz não" e "o registro não diz". Não diz nada sobre uma pergunta mais difícil, um modelo diferente, ou a precisão dos próprios registros reais.
A parte sem ferramentas custou $0,20 para produzir — 45 chamadas, 1.281 entradas e 19.520 tokens de saída a preços de tabela. O harness, os casos e ambos os relatórios estão no repositório, então a discordância pode ser com os dados em vez de conosco.
claude mcp add registry-mcp --transport http "https://api.foretak.dev/mcp?src=devto"
# ou localmente, via stdio: uvx registry-mcp
Harness, casos e relatórios (evals/), MIT: https://github.com/foretak/registry-mcp
Empresas brasileiras que utilizam modelos de IA para consultas sobre dados corporativos devem estar cientes dos riscos associados à falta de registros. A precisão das respostas pode ser comprometida, levando a decisões erradas. A integração de registros confiáveis é crucial para garantir a qualidade das informações.


