IBGE Brasil MCP

Calendário de divulgações

ibge_calendario

Read-onlyIdempotent

Query IBGE's release and collection calendar to find upcoming survey publication or fieldwork dates, filtering by product such as IPCA, PNAD, or GDP and by date range.

Instructions

Queries IBGE release and collection calendar.

Features:

List upcoming survey releases
Filter by product (IPCA, PNAD, GDP, etc.)
Filter by period
Distinguish releases from field collections

Event types:

Release: Publication of survey results
Collection: Field research period

Examples:

Upcoming releases: (no parameters)
IPCA releases: produto="IPCA"
2024 calendar: de="01/01/2024", ate="31/12/2024"
Field collections: tipo="coleta"

Use a different tool when:

Already-published news and releases → ibge_noticias

Behavior: read-only and idempotent — a live GET against the public IBGE Calendário API. Returns a Markdown list.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`de`	No	Data inicial no formato DD/MM/AAAA (ex: '01/01/2024')
`ate`	No	Data final no formato DD/MM/AAAA (ex: '31/12/2024')
`tipo`	No	Tipo de evento: 'divulgacao' (publicações), 'coleta' (pesquisas de campo), ou 'todos'	divulgacao
`pagina`	No	Número da página (padrão: 1)
`produto`	No	Filtrar por produto/pesquisa (ex: 'IPCA', 'PNAD', 'PIB')
`quantidade`	No	Quantidade de resultados por página (padrão: 20)

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes	Total de eventos disponíveis para os critérios
`pagina`	No	Página atual retornada
`eventos`	Yes	Lista de eventos do calendário (divulgações/coletas)
`produto`	No	Filtro de produto aplicado, quando informado
`provenance`	Yes	Bloco de proveniência (contrato v1.0): fonte, URL, período, extração e licença
`attribution`	Yes	URLs canônicas das fontes desta resposta (lista de atribuição)
`totalPaginas`	No	Total de páginas disponíveis

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv5.0.0Sep 12, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Changed4 schema fields changedv4.0.0Aug 29, 2026
- removedOutput schema / properties / provenance / properties / data_vintage / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / provenance / properties / data_vintage / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / provenance / properties / license / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / provenance / properties / license / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed6 schema fields changedv3.3.0Aug 17, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

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, período, extração e licença",
+  "properties": {
+    "citation": {
+      "description": "Citação pronta para uso",
+      "type": "string"
+    },
+    "data_vintage": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Período de referência do dado segundo a fonte; null se a fonte não expõe"
+    },
+    "license": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Regime legal do dado"
+    },
+    "retrieved_at": {
+      "description": "Instante real da extração no upstream (ISO-8601, horário de Brasília)",
+      "type": "string"
+    },
+    "source": {
+      "description": "Fonte oficial do dado (API do IBGE consultada)",
+      "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: -[
-  "eventos",
-  "total"
-]New value: +[
+  "eventos",
+  "total",
+  "provenance",
+  "attribution"
+]

Changed3 schema fields changedv3.0.0Jun 20, 2026

changedInput schema / properties / ate / description

Previous value: -"Data final no formato MM-DD-AAAA (ex: '12-31-2024')"New value: +"Data final no formato DD/MM/AAAA (ex: '31/12/2024')"

changedInput schema / properties / de / description

Previous value: -"Data inicial no formato MM-DD-AAAA (ex: '01-01-2024')"New value: +"Data inicial no formato DD/MM/AAAA (ex: '01/01/2024')"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "eventos": {
+      "description": "Lista de eventos do calendário (divulgações/coletas)",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "dataDivulgacao": {
+            "description": "Data/hora de divulgação no formato 'DD/MM/AAAA HH:MM:SS'",
+            "type": "string"
+          },
+          "id": {
+            "description": "Identificador do evento no calendário",
+            "type": "number"
+          },
+          "link": {
+            "description": "Link para mais informações, quando disponível",
+            "type": "string"
+          },
+          "produto": {
+            "description": "Nome do produto/pesquisa associado",
+            "type": "string"
+          },
+          "tipo": {
+            "description": "Descrição do tipo do evento",
+            "type": "string"
+          },
+          "tipoId": {
+            "description": "ID do tipo (1 = divulgação, 2 = coleta)",
+            "type": "number"
+          },
+          "titulo": {
+            "description": "Título do evento",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "titulo",
+          "produto",
+          "dataDivulgacao",
+          "tipoId",
+          "tipo"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "pagina": {
+      "description": "Página atual retornada",
+      "type": "number"
+    },
+    "produto": {
+      "description": "Filtro de produto aplicado, quando informado",
+      "type": "string"
+    },
+    "total": {
+      "description": "Total de eventos disponíveis para os critérios",
+      "type": "number"
+    },
+    "totalPaginas": {
+      "description": "Total de páginas disponíveis",
+      "type": "number"
+    }
+  },
+  "required": [
+    "eventos",
+    "total"
+  ],
+  "type": "object"
+}

First observedv1.0.0Jan 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so 'read-only and idempotent' is largely redundant. The description still adds genuine context beyond annotations: it is a live GET against the public IBGE Calendário API and returns a Markdown list.

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?

Front-loaded one-line purpose, then tightly grouped Features / Event types / Examples / Routing / Behavior sections. The 'read-only and idempotent' clause duplicates the annotations and could be trimmed, but overall structure is clean and scannable.

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 6-param read-only query tool with a 100%-documented schema, full annotations and an output schema, the description supplies everything else an agent needs: purpose, event semantics, examples, sibling routing, and API/return context. Nothing material is missing.

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 coverage is 100% (baseline 3), but the description adds meaning the schema does not: it interprets the 'tipo' enum values as Release vs Collection events and shows realistic values for produto (IPCA, PNAD, GDP) and de/ate formatting. The example block converts abstract params into concrete usage.

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?

States a specific verb and resource ('Queries IBGE release and collection calendar') and immediately names the sibling it must not be confused with (ibge_noticias). An agent can distinguish this calendar-query tool from the news tool without opening either schema.

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?

Provides explicit 'Use a different tool when' routing to ibge_noticias for already-published content, plus four concrete invocation examples (no params, produto, date range, tipo). When-to-use and when-not-to-use are both covered.

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