portugal-mcp

sns_emergency_stats

Answer questions about ER busyness with official monthly emergency-department visit statistics by type and triage colour for a hospital, region, or all mainland Portugal.

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.1Nov 2, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it warns the latest month is usually 2-3 months back and provisional, explains that a hospital name is mapped to its ULS (check `scope`), and notes region is ignored when institution is given. It does not say what happens on an unknown institution name or an out-of-range period, which is the main remaining gap for a data-lookup tool.

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?

Well front-loaded: purpose, then use-cases, then scope, then output fields, then args. It is on the long side and some content (enumerating what red/orange/yellow mean, the 112/SNS 24 disclaimer) sits beyond what is needed to call the tool, especially since an output schema exists.

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 zero-required-parameter statistics tool with an output schema, nothing essential is missing: scope semantics, data lag, defaults, and unit/format conventions are all covered. An agent could invoke it correctly from the description alone.

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 description coverage is 0%, so the description must compensate and it does: `institution` is accent-insensitive with worked examples, `region` enumerates the five accepted values, `period` specifies the YYYY-MM format and default of newest available, and `months` gives default 6 and max 24. Every parameter is fully specified in prose where the schema is bare.

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 precise verb+resource: monthly emergency-department visits broken down by visit type and Manchester triage colour. It immediately distinguishes itself from the live-queue alternative by declaring 'OFFICIAL MONTHLY STATISTICS ONLY' and pointing live waiting times elsewhere, so an agent can route correctly 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 example queries it answers ('how busy is the ER at X?', 'what share of ER visits are green/blue?') and explicit exclusions ('not the live queue', send the user to tempos.min-saude.pt for waiting times). It also states the scope rule: one institution, one region, or all mainland SNS hospitals.

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