Skip to main content
Glama
SidneyBissoli

Banco Central do Brasil (BCB) — SGS MCP

bcb_correlacao

Read-onlyIdempotent

Compute pairwise correlation between 2-5 BCB time series for a given period. Choose Pearson or Spearman method to measure if indicators like the dollar and Selic move together.

Instructions

Calcula a correlação estatística entre 2 a 5 séries temporais do BCB no MESMO período (dataInicial e dataFinal obrigatórias), par a par. Quando usar: para medir se dois indicadores se movem juntos (ex.: dólar e Selic, IPCA e IGP-M). Quando NÃO usar: para comparar a variação de cada série lado a lado use bcb_comparar; para uma série só use bcb_variacao. Métodos: pearson (padrão) mede relação LINEAR entre os valores; spearman mede relação MONÓTONA entre os postos e é o adequado quando a relação não é reta ou quando uma série fica parada em platôs (taxa de juros entre reuniões do Copom). Base: nivel (padrão) correlaciona os valores; variacao correlaciona a mudança percentual de um ponto para o outro — prefira variacao quando as duas séries têm tendência (preço, índice, estoque), porque o nível de duas séries crescentes tem correlação alta só porque ambas crescem com o tempo. Retorna: periodo, metodo, base, series, alinhamento (datas cruzadas, completas e parciais), pares (cada um com codigoA/codigoB, coeficiente entre -1 e 1, n, descartados e interpretacao em prosa), erros e derivacao. Coeficiente que não pode ser calculado vem null com motivo — nunca 0, que significaria ausência medida de relação. Periodicidades diferentes são RECUSADAS, não avisadas: cruzar uma série diária com uma mensal por data casa só as datas coincidentes (cerca de 7 por ano) e produziria um coeficiente sobre esse punhado; informe frequencia para harmonizar todas na mesma grade antes de correlacionar. Correlação não estabelece causalidade. Comportamento: consome a API pública SGS do Banco Central do Brasil — sem autenticação, chave de API ou cadastro, e sem limite de requisições divulgado (uso é best-effort). Em falha transitória ou timeout a chamada é repetida automaticamente (até 3 tentativas, backoff exponencial); persistindo o erro, retorna isError: true com mensagem em português (HTTP 404 = série inexistente ou sem dados no período solicitado). O resultado vem como JSON tanto em texto quanto em structuredContent (conforme o outputSchema); datas no formato dd/MM/yyyy e valores numéricos (ponto decimal).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseNo`nivel` correlaciona os valores; `variacao` correlaciona a mudança percentual de um ponto para o seguinte. Prefira `variacao` quando as duas séries têm tendência: o nível de duas séries crescentes tem correlação alta só porque ambas crescem com o tempo.nivel
metodoNo`pearson` mede relação linear entre os valores; `spearman` mede relação monótona entre os postos (com posto médio nos empates) e é o adequado quando a relação não é reta ou quando uma das séries fica parada em platôs, como a Selic entre reuniões do Copom.pearson
codigosYesArray com 2 a 5 códigos de séries para correlacionar par a par
agregacaoNoComo agregar os valores de cada período quando `frequencia` é informada. `ultimo` (padrão) serve a nível de preço, taxa e índice; `soma` a fluxo; `acumulada` a séries que JÁ SÃO variação percentual (IPCA mensal, por exemplo), compondo geometricamente — somar 12 variações mensais NÃO dá a inflação do ano.ultimo
dataFinalYesData final (yyyy-MM-dd ou dd/MM/yyyy)
frequenciaNoOpcional: reamostra a série para esta frequência antes de responder (só agrega para períodos MAIORES; pedir frequência mais fina que a da série é recusado). Útil para comparar séries de periodicidades diferentes.
dataInicialYesData inicial (yyyy-MM-dd ou dd/MM/yyyy)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseYesSe o cálculo usou os valores ou as variações
errosYesSéries que não retornaram dados, com o motivo
paresYesUm item por par de séries
metodoYesMétodo aplicado
seriesYesSéries que entraram no cálculo
periodoYesJanela temporal correlacionada
derivacaoYesOrigem dos números calculados: o que é derivado, por qual motor e com quais convenções
provenanceYesBloco de proveniência (contrato v1.0): fonte, URL, competência, extração e licença
alinhamentoYesComo as grades foram cruzadas. `completas` é o que efetivamente entra num coeficiente: datas em que TODAS as séries publicam. A distância entre `datas` e `completas` é a medida de quanto as séries não se sobrepõem.
attributionYesURLs canônicas das fontes desta resposta (lista de atribuição)
harmonizacaoNoPresente quando `frequencia` foi informada: descreve a reamostragem aplicada. Valor DERIVADO — calculado por este servidor, não publicado pelo Banco Central.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv1.9.2
    • addedOutput schema / properties / attribution
      Added value: +{
      +  "description": "URLs canônicas das fontes desta resposta (lista de atribuição)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / provenance
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Bloco de proveniência (contrato v1.0): fonte, URL, competência, extração e licença",
      +  "properties": {
      +    "citation": {
      +      "description": "Citação pronta para uso",
      +      "type": "string"
      +    },
      +    "data_vintage": {
      +      "description": "Competência do dado segundo a fonte; null quando a fonte não expõe",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "license": {
      +      "description": "Regime legal do dado",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "retrieved_at": {
      +      "description": "Instante REAL da extração na origem (ISO-8601, horário de Brasília). Resposta servida de cache mantém o instante do fetch ORIGINAL, que é a data de extração relevante.",
      +      "type": "string"
      +    },
      +    "source": {
      +      "description": "Fonte oficial do dado",
      +      "type": "string"
      +    },
      +    "source_url": {
      +      "description": "URL canônica que reproduz a consulta",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "source",
      +    "source_url",
      +    "data_vintage",
      +    "retrieved_at",
      +    "citation",
      +    "license"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "periodo",
      -  "metodo",
      -  "base",
      -  "series",
      -  "alinhamento",
      -  "pares",
      -  "erros",
      -  "derivacao"
      -]New value: +[
      +  "periodo",
      +  "metodo",
      +  "base",
      +  "series",
      +  "alinhamento",
      +  "pares",
      +  "erros",
      +  "derivacao",
      +  "provenance",
      +  "attribution"
      +]
  2. Addedv1.6.0

TDQS

A5/5.0
Behavior5/5

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

No contradiction with annotations (readOnlyHint=true, idempotentHint=true, openWorldHint=true). The description adds substantial behavioral context beyond annotations: uses the public SGS API with no auth, no disclosed rate limits, best-effort; retries up to 3 times with exponential backoff on transient failures; returns isError: true with error messaging in Portuguese; HTTP 404 semantics; and critically explains that different periodicities are RECUSADAS rather than naively joined—before warning about the ~7 matched days/year data-snooping pitfall.

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

Conciseness5/5

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

The description is long but every clause earns its place—it packs statistical warnings, API contract details, and edge-case behaviors into a scan-friendly structure that uses bold, uppercase emphasis, and colons effectively (e.g., 'nunca 0', 'RECUSADAS, não avisadas'). No fluff; the causational disclaimer 'Correlação não estabelece causalidade' is a single purposeful sentence.

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?

For a complex statistical tool, the description is fully complete: it covers the mathematical methods, the output contract (`periodo`, `metodo`, `base`, `series`, `alinhamento`, `pares` with `codigoA/B` and `coeficiente`), error semantics, retry behavior, date formats, and the important distinction between null-with-reason and 0. The outputSchema covers the return structure, so the description needn't duplicate it—yet it still explains what `descartados` and `derivacao` mean contextually.

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

Parameters5/5

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

Even though schema description coverage is 100%, the description adds meaningful semantics beyond what the schema provides. It explains WHY `spearman` is appropriate for plateau series (e.g., Selic), why `acumulada` uses geometric composition (because summing monthly IPCA variations is incorrect), and how `frequencia` harmonizes different periodicities. These are non-obvious statistical implications that the raw parameter docs alone cannot convey.

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?

The description opens with a specific verb+resource+scope construction: 'Calcula a correlação estatística entre ional 2 a 5 séries temporais do BCB no MESMO período... par a par.' This immediately differentiates it from siblings by naming the statistical operation, the 2-5 series constraint, the pairwise behavior, and the mandatory same-period requirement. It also explicitly names alternatives (bcb_comparar, bcb_variacao).

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?

Goes beyond vague guidance with a dedicated 'Quando usar' section (with concrete indicator examples like 'dólar e Selic, IPCA e IGP-M') and a 'Quando NÃO usar' section naming specific sibling tools. It even makes a methodological prescription—prefer `variacao` when series have trends because level-based correlation is spuriously high—which actively prevents misuse.

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

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