sns-portugal-mcp

emergency_stats

Get official monthly emergency-department visit counts by type and Manchester triage colour for a Portuguese hospital, region, or all mainland SNS hospitals; use historical data, not live waiting times.

Instructions

Emergency-department (urgência) visits per month: by type and by Manchester triage colour.

Use for "how busy is the ER at X?", "how many emergency visits in the Algarve last month?", "what share of ER visits are green/blue (non-urgent)?". OFFICIAL MONTHLY STATISTICS ONLY — not the live queue (the latest month is usually 2-3 months back and provisional). For live waiting times send the user to https://tempos.min-saude.pt. Not medical advice: in an emergency call 112; SNS 24 (808 24 24 24) for advice.

Scope: one institution, one region, or (neither) all of mainland Portugal's SNS hospitals.

Per period (latest first): visits_in_month and visits_year_to_date by type (general, paediatric, obstetric, psychiatric, total), triage_in_month by colour (red = immediate, orange = very urgent, yellow = urgent, green = less urgent, blue = non-urgent, white = not clinical / other) and triage_share_in_month_pct.

Args: institution: Hospital or ULS name, accent-insensitive ("Santa Maria", "São João", "Hospital de Faro"). A hospital is mapped to its ULS; check scope. region: Norte | Centro | LVT (Lisboa) | Alentejo | Algarve. Ignored if institution is given. period: Latest month to include, "YYYY-MM" (default: newest available). months: How many months back to return (default 6, max 24).

Input Schema

Name	Required	Description	Default
`months`	No
`period`	No
`region`	No
`institution`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it warns the latest month is usually 2-3 months back and provisional, explains the institution→ULS mapping and the `scope` field to verify it, and documents default/max behaviour for period and months. Those are the traits that actually change how an agent interprets and presents results.

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 with the core purpose and example queries, then scope, then args — a good ordering with no filler sentences. It is on the long side, and the emergency-contacts disclaimer (112 / SNS 24) is an emergency-response message that contributes little to tool selection or invocation.

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 0-required-param statistics tool with an output schema, the definition covers everything that remains open: geographic scope semantics, time-window semantics, freshness caveats, and what the returned fields mean (visit types, triage colours and their clinical meanings, share percentages). Nothing needed to call it correctly is missing.

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?

Schema coverage is 0%, and the description fully compensates: it gives the accepted region vocabulary (Norte | Centro | LVT (Lisboa) | Alentejo | Algarve), states region is ignored when institution is supplied, defines period as 'YYYY-MM' with newest-available default, and gives months default 6 / max 24 plus accent-insensitive institution examples. This exceeds what the bare schema conveys.

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 resource and breakdown precisely: monthly emergency-department visits by visit type and by Manchester triage colour. It also contrasts itself with the nearest confusable thing (live queue / waiting-time tools) and with the sibling wait-stats family, so the agent can pick it without opening the 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?

Gives concrete trigger phrasings ('how busy is the ER at X?', 'how many emergency visits in the Algarve last month?'), states an explicit when-not ('OFFICIAL MONTHLY STATISTICS ONLY — not the live queue'), and routes the out-of-scope case to https://tempos.min-saude.pt. The exclusion plus redirect is exactly what an agent needs.

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

Deploy Server