Skip to main content
Glama
SidneyBissoli

Banco Central do Brasil (BCB) — SGS MCP

bcb_buscar_serie

Read-onlyIdempotent

Find the code of a BCB economic time series by searching with a keyword or code. Combines multiple terms with AND, ignores accents, and checks the curated catalog plus the Open Data portal index.

Instructions

Busca séries do BCB por palavra-chave (ou pelo código) em DUAS camadas: o catálogo curado local de 139 séries verificadas contra a origem, que vem primeiro e com fonteNome dizendo se o nome é transcrito do portal do BCB ou herdado, e o índice do Portal de Dados Abertos do BCB, com milhares de séries identificadas por código. Ignora acentos e maiúsculas ('inflacao' encontra 'Inflação'); vários termos são combinados com E ('ipca servicos'). Quando usar: para descobrir o código de uma série antes de consultar valores. Quando NÃO usar: para navegar tudo por categoria use bcb_series_populares; para valores use bcb_serie_valores. Retorna: termo, totalEncontradas, series (cada item com codigo, nome, origem — 'curado' ou 'indice' — e, no índice, dataset com a página do portal), catalogo (origem, obtidoEm, seriesIndexadas, cobertura) e, quando aplicável, observacao, avisos, mensagem e sugestao. Cobertura: o índice NÃO é o SGS inteiro, portanto não encontrar aqui não prova que a série não exista — o campo catalogo.cobertura diz isso explicitamente em toda resposta. Comportamento de rede: o índice é servido de cache com validade de 24 h e a renovação é feita pela primeira busca após o vencimento (uma requisição ao portal, ~1 s); as demais buscas não tocam a rede. Se o portal estiver fora, a busca degrada para o catálogo curado (ou para o último índice obtido) e sinaliza em avisos, sempre com a data de obtenção visível.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termoYesTermo de busca (mínimo 2 caracteres) ou o código da série. Vários termos são combinados com E.
limiteNoMáximo de séries a devolver (1-100, padrão: 20). `totalEncontradas` traz o total antes do corte.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
termoYesTermo pesquisado
avisosNoAvisos de degradação (índice vencido ou indisponível)
seriesYesSéries que correspondem ao termo — as do catálogo curado primeiro
catalogoYesProveniência do índice usado na busca
mensagemNoMensagem exibida quando nada é encontrado
sugestaoNoSugestões de termos alternativos
observacaoNoAviso de corte quando há mais resultados que `limite`
provenanceYesUm bloco por procedência que contribuiu com esta resposta (contrato v1.0; licenças nunca se fundem)
attributionYesURLs canônicas das fontes desta resposta (lista de atribuição)
totalEncontradasYesQuantidade de séries encontradas, antes do corte por `limite`
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, establishing safety. The description goes far beyond these with rich behavioral disclosure: accent/case-insensitive matching, AND-combination semantics, 24h cache validity, network behavior (only first search after expiry touches network), degraded mode with fallback to curated catalog, and coverage caveat that the index is not the full SGS. No contradiction with annotations — the openWorldHint aligns perfectly with the 'not finding doesn't prove non-existence' warning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but from-loaded with the core purpose and two-layer behavior first. Every sentence carries new information: search semantics, usage guidance, return format, coverage limitation, network behavior, degradation. Given the tool's genuine complexity (dual-source search, caching, fallbacks), the length is justified. Slight structural improvement possible by separating return-schema details (already covered by output schema) from usage guidance, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and rich annotations (readOnly, idempotent, openWorld), the description still adds significant value: coverage limitation explicitly stated, network/caching behavior with timing, degradation path and signal mechanism (`avisos`), and search semantics not derivable from schema. For a dual-layer search tool with external dependency on the BCB portal, this is comprehensive and leaves no critical behavioral gap for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters at 100% (termo: min 2 chars, code or term, AND-combination; limite: 1-100, default 20), so baseline is 3. The description adds value by explaining search semantics beyond schema: accent/case insensitivity ('inflacao' finds 'Inflação'), the two-layer interpretation of results, and that `termo` accepts a code. A small gap: the caching/degradation behavior is stated at the tool level but not tied explicitly to how it affects `termo` results — minor, so 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with a specific verb+resource: 'Busca séries do BCB por palavra-chave (ou pelo código)' with a clear two-layer model (curated local catalog vs. BCB open data portal index). It actively distinguishes itself from siblings by naming bcb_series_populares and bcb_serie_valores for alternative use cases. This fully clarifies both what the tool does and how it differs from peers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: 'Quando usar: para descobrir o código de uma série antes de consultar valores' and 'Quando NÃO usar: para navegar tudo por categoria use bcb_series_populares; para valores use bcb_serie_valores.' This names specific sibling alternatives, giving the agent precise decision criteria for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SidneyBissoli/bcb-br-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server