FinMCP-Bench: Benchmarking de Agentes de LLM para Uso de Ferramentas Financeiras no Mundo Real sob MCP

O MCP tornou-se o padrão de integração de fato para o uso de ferramentas por LLMs — a Anthropic o introduziu no final de 2024 e, no início de 2026, todos os principais provedores de modelos o haviam adotado. O FinMCP-Bench (arXiv:2603.24943, ICASSP 2026) é o primeiro benchmark construído sobre servidores de ferramentas MCP reais especificamente para agentes financeiros, e chegou no momento certo para nos dizer se essa estrutura padronizada realmente ajuda os agentes a realizar um trabalho financeiro útil.

O artigo

Jie Zhu, Yimin Tian e colegas da equipe Alibaba Cloud Qwen DianJin, YINGMI Wealth Management e Soochow University apresentam o FinMCP-Bench, uma suíte de avaliação com 613 amostras cobrindo 10 categorias de cenários financeiros e 33 subcenários. As ferramentas não são simuladas — 65 servidores de ferramentas financeiras reais em conformidade com o MCP sustentam o benchmark, extraídos de logs de produção reais do assistente financeiro Qieman APP. Os autores categorizam as amostras em três tipos: 145 de ferramenta única, 249 de múltiplas ferramentas e 219 multiturno. Eles testam seis modelos: a família Qwen3 com contagens de parâmetros de 4B, 30B e 235B (todos com raciocínio estendido), além de DeepSeek-R1, GPT-OSS-20B e Seed-OSS-36B. As principais métricas de avaliação são Precisão de Ferramenta, Recall de Ferramenta, F1 de Ferramenta e uma Taxa de Correspondência Exata (EMR) que exige que cada chamada de ferramenta em uma sequência esteja exatamente correta.

Ideias fundamentais

• MCP como substrato de avaliação: usar definições reais de servidores MCP em vez de esquemas de API sintéticos fecha uma lacuna importante entre a avaliação de benchmark e o que os agentes realmente enfrentam em sistemas financeiros implantados.
• Divisão de dificuldade em três níveis: amostras de ferramenta única, multiferramenta e multiturno não são apenas diferenças de quantidade — elas expõem modos de falha qualitativamente diferentes.
• Colapso multiturno: o melhor modelo (Qwen3-235B) alcança 60% de EMR em ferramenta única, 10,62% de EMR em multiferramenta e 3,08% de EMR em multiturno. A queda de única para multiturno é de 20 vezes.
• F1 de Ferramenta é mais tolerante: o mesmo modelo pontua 66,85%, 69,42% e 41,56% de TF1 nas três configurações — mostrando que os modelos frequentemente escolhem as ferramentas certas, mas falham na ordenação, parametrização ou acompanhamento da conversa.
• Recall vence a precisão em ferramenta única: os modelos tendem a chamar ferramentas em excesso quando estão incertos, em vez de chamar a menos, o que é o modo de falha mais seguro para tarefas financeiras, mas ainda significa chamadas de API desperdiçadas e ruído no rastro de raciocínio.
• Escalonamento de tamanho não monotônico: o Qwen3-30B não supera consistentemente o Qwen3-4B em todos os subcenários, quebrando a suposição de que modelos maiores sempre vencem no uso de ferramentas em múltiplas etapas.

O que se sustenta — e o que não

O uso de logs de produção reais como fonte para exemplos de ferramenta única é a escolha metodológica mais forte aqui. Isso fundamenta o benchmark no comportamento real do usuário, em vez de cenários inventados por pesquisadores, o que é raro na literatura de IA financeira. As amostras multiferramenta e multiturno são estendidas sinteticamente usando grafos de dependência e prompts de interpretação de papéis, o que é razoável dado o custo de rotulagem, mas introduz um risco: o processo de síntese tende a produzir consultas mais limpas e diretas do que as escritas por usuários reais. O EMR de 3,08% no multiturno é alarmante, mas deve ser interpretado com cautela — o EMR exige que a sequência completa esteja exatamente correta, portanto, uma única chamada de ferramenta intermediária errada invalida toda a tarefa. Esse é um padrão de produção rigoroso e possivelmente irrealista; métricas de crédito parcial como o TF1 contam uma história mais detalhada.

O que o artigo não aborda: não há análise sobre se a lacuna de desempenho é primariamente um problema de compreensão de entrada (o modelo interpreta mal o que o usuário quer), um problema de formatação de saída (intenção correta, mas chamada de ferramenta malformada) ou um problema de raciocínio (conclusões intermediárias erradas). Sem essa decomposição, é difícil saber onde investir o esforço de engenharia. O artigo também avalia os modelos isoladamente; não há teste sobre se a adição de uma etapa de verificação ou reflexão altera o cenário multiturno.

O benchmark também está profundamente ligado às 65 ferramentas específicas da Qieman, o que limita a transferência dos resultados para outras plataformas financeiras com inventários de ferramentas diferentes.

Por que isso importa para a IA nas finanças

O FinMCP-Bench é a avaliação publicada mais próxima do que um agente de escrita (write-back) do Beancount realmente faria: receber uma solicitação do usuário, identificar qual ferramenta (ou cadeia de ferramentas) se aplica, invocá-las em ordem e lidar com os turnos subsequentes. O EMR multiturno de 3,08% é um choque de realidade. Um agente Beancount que gerencia uma correção de livro-razão em várias etapas — por exemplo, reclassificar um conjunto de transações entre contas em um intervalo de datas, depois conciliar e gerar um relatório — é exatamente o tipo de tarefa multiturno e multiferramenta em que os modelos atuais falham quase universalmente pelos padrões de correspondência exata.

O enquadramento do MCP é diretamente relevante: a API Python do Beancount, a interface beanquery e a camada REST do Fava poderiam todos ser encapsulados como servidores MCP. O FinMCP-Bench nos diz que o protocolo não é o gargalo — o raciocínio sobre sequências de chamadas de ferramentas é.

A descoberta de que o recall de ferramentas excede a precisão (modelos chamam em excesso) também importa para a segurança da escrita: um agente que chama a ferramenta de mutação do razão quando apenas uma leitura era necessária poderia corromper o livro-razão silenciosamente. Métricas de avaliação tendenciosas para precisão, e não para recall, devem ser o principal sinal de segurança para agentes de write-back.

O que ler a seguir

• JSONSchemaBench (arXiv:2501.10868) — avalia a confiabilidade da saída estruturada em 10 mil esquemas JSON; aborda diretamente se as falhas de formatação de chamada de ferramenta no FinMCP-Bench são um problema de decodificação restrita.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — a estrutura fundamental de treinamento para uso de ferramentas contra a qual o FinMCP-Bench se posiciona; entender sua exploração de árvore de busca em profundidade esclarece o que a metodologia de logs de produção do FinMCP-Bench adiciona.
• WildToolBench (arXiv:2604.06185) — avalia o uso de ferramentas em consultas de usuários reais no mundo real; sua descoberta de que nenhum modelo excede 15% de precisão no comportamento selvagem do usuário complementa a abordagem de logs de produção do FinMCP-Bench.