IBGE Brasil MCP

Indicadores de saúde

ibge_datasaude

Read-onlyIdempotent

Queries Brazil health indicators, served through IBGE's SIDRA (some originally produced by DataSUS, e.g. mortality and births).

Mortality and Birth:

mortalidade_infantil: Infant mortality rate
nascidos_vivos: Live births by location
obitos: Deaths by residence

Demographic Indicators:

esperanca_vida: Life expectancy at birth
fecundidade: Fertility rate

Sanitation:

saneamento_agua: Water supply
saneamento_esgoto: Sewage system

Health Coverage:

plano_saude: Health insurance coverage
autoavaliacao_saude: Self-rated health status

Territorial levels: 1=Brazil, 2=Region, 3=State, 6=Municipality

Examples:

Infant mortality: indicador="mortalidade_infantil"
Life expectancy by state: indicador="esperanca_vida", nivel_territorial="3"
Deaths in SP: indicador="obitos", nivel_territorial="3", localidade="35"
List indicators: indicador="listar"

Statistics mode: for largest/smallest/mean/median/distribution/ranking questions ("which state has the highest infant mortality?", "median life expectancy across states") use estatisticas=true — full distribution + top/bottom over ALL rows before truncation; agruparPor="" ranks groups by descending sum. In this mode campos/formato are ignored and registros comes empty.

Use a different tool when:

A single municipality's general panel (which also includes infant mortality) → ibge_cidades
Population/demographic counts (not health-specific) → ibge_censo or ibge_sidra

Behavior: read-only and idempotent — a live GET against the public IBGE SIDRA API. Returns Markdown plus a typed structuredContent payload.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`topN`	No	Tamanho das listas top/bottom quando estatisticas=true sem agruparPor (padrão: 10, máx: 100)
`campos`	No	Selecionar apenas algumas colunas por rótulo, separadas por vírgula (ex: 'Valor,Ano'). Reduz o volume da resposta.
`formato`	No	Formato de saída	tabela
`periodo`	No	Período: 'last', 'all', ou ano específico	last
`indicador`	Yes	Indicador de saúde. Disponíveis: - mortalidade_infantil: Taxa de mortalidade infantil - esperanca_vida: Esperança de vida ao nascer - nascidos_vivos: Nascidos vivos - obitos: Óbitos por local de residência - fecundidade: Taxa de fecundidade - saneamento_agua: Abastecimento de água - saneamento_esgoto: Esgotamento sanitário - plano_saude: Cobertura de plano de saúde - listar: Lista indicadores disponíveis
`agruparPor`	No	Com estatisticas=true, agrupa pela coluna informada (rótulo, ex: 'Unidade da Federação', 'Ano') e ranqueia os grupos por soma decrescente (grupos[0] = maior total), cada grupo com sua mini-distribuição
`localidade`	No	Código da localidade ou 'all'	all
`estatisticas`	No	Computa estatísticas (mínimo/máximo/média/mediana/desvio-padrão/percentis) sobre TODOS os registros da consulta, antes da paginação, + ranking top/bottom. Use para 'qual o maior/menor', 'média', 'mediana', 'distribuição', 'ranking'. Quando true, ignora pagina, campos e formato
`nivel_territorial`	No	Nível territorial (código N): 1=Brasil, 2=Região, 3=UF, 6=Município	1

Output Schema

TableJSON Schema

Name	Required	Description
`nome`	No	Nome do indicador
`fonte`	No	Fonte do dado
`colunas`	Yes	Rótulos das colunas, na ordem
`indicador`	No	Chave do indicador de saúde consultado
`registros`	Yes	Registros: cada um mapeia rótulo da coluna -> valor
`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)
`estatisticas`	No	Bloco estatístico presente quando estatisticas=true (registros vem vazio nesse modo)
`totalRegistros`	Yes	Total de registros de dados

Schema Changelog

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

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that it is a live GET against the public IBGE SIDRA API and that it returns Markdown plus typed structuredContent. It also reveals important mode-specific behavior: in estatisticas=true mode, campos/formato are ignored and registros comes empty. None of this contradicts the annotations.

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 longer than average and partially duplicates the indicator list already present in the schema, but it is well organized with headings, examples, and a clear alternatives section. The extra length earns its place by adding examples and mode-specific caveats rather than padding.

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 9-parameter tool with multiple modes, the description is remarkably complete: it covers the indicator vocabulary, territorial levels, example requests, statistics-mode behavior, exclusions/alternatives, and high-level behavior. Because an output schema exists, the lack of a detailed return-value explanation is acceptable.

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 concrete usage meaning: example parameter combinations ('Deaths in SP: indicador="obitos", nivel_territorial="3", localidade="35"'), the meaning of territorial codes, and advanced semantics for agruparPor and estatisticas. It even lists a valid indicator, autoavaliacao_saude, that is absent from the schema's indicador list.

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 and resource ('Queries Brazil health indicators') and then enumerates the indicator families and territorial levels, making the tool's scope unmistakable. It also names adjacent tools (ibge_cidades, ibge_censo, ibge_sidra) for nearby use cases, so an agent can tell it apart from siblings.

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?

The description is explicit about when to use the tool and when not to: it gives a 'Use a different tool when' section with concrete alternatives, and it tells the agent to enable estatisticas=true for largest/smallest/mean/median/ranking questions. This leaves little to inference.

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

All IBGE Brasil MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.