Loading ToolBench
MCP server for accessing Brazilian public health data (DATASUS)
DATASUS MCP provides 10 tools with complete input schemas and descriptions for most parameters. However, there are significant gaps in output schema documentation, error handling guidance, and some parameters lack detailed constraints. Tool naming follows the verb_noun pattern well (query_*, search_*, lookup_*). Descriptions are present but vary in specificity. The server uses FastMCP framework with tools properly registered via decorators. All tools are read-only with no destructive operations, which simplifies security concerns. Key weakness: no documented output schemas or pagination guidance, which forces LLMs to guess what fields will be returned and how to chain results.
Compare a health indicator across multiple states in a given year.
List available DATASUS data files for a given information system.
Look up an ICD-10 code or search by disease name. Provide either a code (e.g. "I219") for exact lookup, or a search_term (e.g. "dengue") to find matching codes.
Look up an IBGE municipality code or search by city name. Provide either a code (e.g. "3550308") for exact lookup, or a search_term (e.g. "São Paulo") to find matching cities.
Query birth records from SINASC (Live Births Information System). Returns birth statistics by delivery type with counts.
Query notifiable disease records from SINAN. Returns case counts by classification and outcomes for diseases like Dengue, Chikungunya, Zika, Malaria, Tuberculosis, and others.
No output schemas documented. Tools return strings (markdown-formatted text) but the structure of that text is undocumented. LLMs cannot reliably extract structured data or chain results without knowing what fields to expect.
No pagination parameters or guidance. Tools accept 'limit' but do not document offset/page parameters or whether results are truncated. Large result sets could exhaust context window without explicit pagination support.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Query hospital admission records from SIH (Hospital Information System). Returns top diagnoses with admission counts, average stay, and costs.
Query death records from SIM (Mortality Information System). Returns the top causes of death with counts and ICD-10 descriptions.
Query vaccination records from SI-PNI. Returns vaccination counts by immunobiological type.
Search health facilities from CNES (National Health Facility Registry). Returns facility counts by type for a state and year.
Enum constraints missing for categorical parameters. Parameters like 'disease' (query_diseases), 'facility_type' (search_facilities), and 'vaccine' (query_vaccinations) should be enums listing valid values, not free-form strings. Current descriptions mention valid values inline (e.g. 'DENG, CHIK, ZIKA, MALA, TUBE, HANS, ANIM') but these are not enforced schemas.
No error handling guidance. Tools return string errors but do not categorize them as retryable, user-fixable, or fatal. No guidance on what the LLM should do next (e.g. 'User not found. Try search_icd10() with a partial name.').
Parameter 'sex' repeated across tools with inconsistent documentation. Some describe it as 'M' for male, 'F' for female, but others just say 'sex filter'. Should be a consistent enum across all tools (M|F|unknown or similar).
lookup_icd10 and lookup_municipality accept mutually exclusive parameters ('code' vs 'search_term') but do not document this relationship or enforce it. LLM could pass both or neither, causing ambiguous behavior.
No idempotency guarantees. Tools like query_* may or may not return the same results if called twice with identical parameters, depending on whether the underlying DATASUS data changed. This is acceptable for read-only tools but should be documented.