Pitch: Construí uma API aberta para unificar dados do BCB, IBGE e Tesouro
Nos últimos meses, comecei a construir uma ferramenta para resolver um problema que parecia simples: consultar dados econômicos oficiais do Brasil sem precisar aprender uma API diferente para cada fonte.
BCB tem uma estrutura.
IBGE tem outra.
Tesouro tem outra.
SICONFI, Comex Stat, Novo Caged, ANP, EPE e CVM também têm seus próprios formatos, identificadores e particularidades.
A primeira ideia parecia óbvia: criar uma API única em cima dessas fontes.
Só que, durante o desenvolvimento, percebi que o problema mais difícil não era unificar APIs.
Era garantir que uma consulta retornasse o dado economicamente correto.
O problema de encontrar uma série "parecida"
Imagine que alguém pergunte:
Qual é a Selic atual?
Existem várias séries oficiais relacionadas à Selic:
- Meta Selic definida pelo Copom
- Selic efetiva
- Selic acumulada no mês
- séries anualizadas
Todas são dados reais e oficiais.
Mas devolver a série errada significa responder incorretamente mesmo que o número venha de uma fonte confiável.
Por isso, no Open Economics separei duas etapas:
1. Resolução semântica: entender qual conceito econômico está sendo pedido.
2. Disponibilidade: identificar quais datasets oficiais realmente representam aquele conceito e estão disponíveis para consulta.
Se o dataset correto não estiver disponível, o sistema não substitui silenciosamente por uma série apenas "parecida".
Ele informa que aquela necessidade não está completamente coberta.
Proveniência virou parte do dado
Quando comecei a colocar várias fontes atrás da mesma interface, apareceu outro problema.
Quanto mais abstração eu adicionava, mais fácil ficava perder respostas para perguntas básicas:
- De qual órgão veio esse número?
- Qual era o dataset original?
- Qual é a unidade?
- Qual período o valor representa?
- Houve alguma transformação?
- Onde está a fonte oficial?
Então a proveniência passou a viajar junto com o resultado.
Por exemplo, uma consulta da Meta Selic continua identificando explicitamente:
bcb-sgs:432
Essa é a série oficial "Taxa de juros - Meta Selic definida pelo Copom", publicada pelo Banco Central do Brasil.
Um bug interessante apareceu quando testei com agentes de IA
Além da API REST, eu queria que agentes de IA conseguissem consultar a mesma camada de dados.
Então implementei um servidor MCP.
Hoje ele possui 19 ferramentas para descoberta semântica, inspeção de datasets, metadata e consulta dos dados.
Durante um teste no Cline, porém, aconteceu algo interessante.
O agente encontrava a série correta e executava a consulta, mas dizia que não conseguia enxergar o valor retornado.
A causa estava na resposta MCP.
O resultado completo estava disponível em:
structuredContent
Mas o conteúdo textual entregue ao modelo dizia basicamente:
Retrieved official BCB observations...
Tecnicamente, a chamada havia funcionado.
Na prática, aquele cliente MCP não estava expondo o conteúdo estruturado para o agente, então ele sabia que havia recebido dados, mas não conseguia utilizá-los.
A solução foi manter o resultado completo em structuredContent e também gerar uma representação textual limitada contendo informações importantes como:
- valor;
- data;
- unidade;
- dataset;
- instituição;
- proveniência;
- URL da fonte oficial.
Depois da mudança, o Cline conseguiu descobrir a série, consultar os dados e responder à pergunta sobre a Meta Selic utilizando somente o Open Economics, sem acessar diretamente a API do Banco Central.
Foi um bom exemplo de como seguir uma especificação não garante que todos os clientes vão consumir a resposta exatamente da mesma maneira.
O resultado virou o Open Economics
O projeto acabou se tornando o Open Economics.
A ideia é criar uma camada aberta sobre dados econômicos oficiais brasileiros que possa ser usada por humanos, software e agentes de IA.
Hoje os dados podem ser acessados de diferentes formas.
REST API
Por exemplo, para buscar a observação mais recente da Meta Selic:
curl "https://open-economics-data.knbf982hkn.chatgpt.site/api/v1/indicators/br-selic-target/latest"
A resposta não traz apenas o valor, mas também metadata e proveniência.
Interface web
Também criei uma interface para testar consultas sem precisar escrever código:
MCP
Para agentes de IA, o endpoint é:
https://open-economics-data.knbf982hkn.chatgpt.site/api/mcp
Ele possui 19 ferramentas e não exige API key.
O projeto hoje
O Open Economics é:
- gratuito;
- sem cadastro;
- sem API key;
- read-only;
- open source;
- acessível por REST e MCP.
As integrações atuais incluem fontes como:
BCB, IBGE, Tesouro, SICONFI, MDIC/Comex Stat, MTE/Novo Caged, EPE, ANP e CVM.
Código:
https://github.com/felipegambettadesouza6-jpg/open-economics
Workspace público no Postman:
https://www.postman.com/open-economics/open-economics
O que eu gostaria de descobrir agora
Mais do que saber se o projeto "ficou legal", quero descobrir onde essa abstração quebra em casos reais.
Principalmente em situações envolvendo:
- revisões de séries;
- datas e períodos;
- unidades;
- dimensões;
- datasets muito parecidos;
- mudanças metodológicas;
- proveniência;
- consultas que exigem combinar fontes diferentes.
Se você trabalha com dados econômicos, APIs ou agentes de IA:
Qual consulta envolvendo dados oficiais brasileiros ainda costuma dar trabalho para você?
Se vocês deixarem exemplos concretos, quero testar cada um contra o Open Economics e descobrir onde a camada ainda falha.