Skip to main content
Glama

DATASUS SIH/SUS — Brazil Hospital Admissions (AIH) MCP

Tendências comparativas de ICSAP

compare_icsap_trends
Read-onlyIdempotent

Análise temporal comparativa de ICSAP entre UFs ou grupos CSAP. Calcula tendências, variação anual e identifica melhores/piores desempenhos. Para percentage e count valem todos os anos do SIH (desde 1992); rate_per_10k exige população e aceita só os anos de get_available_years.population_years. Em 1992–1997 a ICSAP vem de lista CID-9 DERIVADA e não oficial (g03 e g05 não comparáveis com 1998+) e uf é a UF do arquivo — ver as notes. Percentual no universo do pacote R csapAIH por padrão (universe): fora do numerador e do denominador as internações por procedimento obstétrico, parto e longa permanência.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_yearYesAno final
universeNoUniverso do % ICSAP: 'csapaih' (padrão) tira do numerador e do denominador as internações por procedimento obstétrico, com diagnóstico de parto (O80-O84) e as AIH de longa permanência, como o pacote R csapAIH (Nedel); 'all' conta todas as internações.
indicatorNoIndicador: percentage (% ICSAP), count (número), rate_per_10k (taxa)
compare_byNoComparar por UF ou grupo CSAP
start_yearYesAno inicial
compare_valuesNoValores específicos para comparar (UFs ou grupos CSAP)
include_trend_lineNoIncluir análise de tendência linear (default: true)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoSempre vazio: só aparece no caminho de erro-mole do funil
noteNoComo obter o dado (por exemplo, consultar get_available_years)
errorNoMotivo pelo qual não há dados nesta resposta (ano sem dado, cobertura populacional, falha na consulta)
notesNoAvisos que qualificam os números: era CID-9, raça/cor ausente, universo do % ICSAP, denominador populacional, truncamento
periodNo
seriesNoPontos em ordem cronológica
trendsNoTendência por valor comparado; só com `include_trend_line` e ao menos dois anos — ausente quando desligada
summaryNo
indicatorNoIndicador das séries
compare_byNoEixo comparado: uf, csap_group ou total (sem eixo)
provenanceYesUm bloco por procedência que contribuiu com esta resposta (SIH, lista CSAP, csapAIH, população…); licenças nunca se fundem
attributionYesURLs canônicas das fontes desta resposta (lista de atribuição)
published_yearsNoAnos que o canal de cubos publica — a verdade do canal, distinta do que esta instância tem em disco; só com o cache de cubos ligado
population_yearsNoCobertura populacional; só no erro-mole de `rate_per_10k` fora do intervalo
available_sih_yearsNoAnos com dados SIH atendíveis por este servidor
years_not_availableNoPresente só quando parte dos anos pedidos não tem dado: os números cobrem apenas os anos atendidos

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent; description adds valuable data provenance caveats (derived CID-9 list, uf from file, universe definition) that affect result interpretation. No contradiction with annotations.

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

Conciseness3/5

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

The description is dense with multiple sentences, front-loaded with purpose but long due to caveats. Each sentence adds value, but it could be more concise; still well-structured.

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

Completeness4/5

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

For a 7-parameter tool with output schema, the description covers purpose, parameter nuances, data reliability, and references notes. Missing return details are covered by output schema; complete enough for correct invocation.

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 all parameters; description adds extra constraints like rate_per_10k requiring population years and universe behavior, plus early-year data limitations, enriching parameter meaning beyond schema.

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

Purpose4/5

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

The description clearly states a comparative temporal analysis of ICSAP across UFs or CSAP groups, including calculation of trends, annual variation, and best/worst performance. It distinguishes from siblings like get_icsap or get_hospitalization_trends by focusing on ICSAP and comparison, though it doesn't explicitly name alternatives.

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

Usage Guidelines3/5

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

The description provides data constraints (e.g., rate_per_10k requires population years, 1992-1997 data caveats) but does not explicitly guide when to choose this tool over compare_regions or get_hospitalization_trends. Usage is implied from the purpose, but no exclusions or alternatives are named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.