Portugal (public data)

active_incidents

What emergency services (civil protection, ANEPC) are responding to right now in Portugal, closest first.

Live occurrences of every kind: fires, road collisions, fallen trees, floods, rescues, with their status (e.g. "Em Curso"), time started and resources on scene. Updated every few minutes. Police-only activity (PSP/GNR) is not published anywhere and is not included. Args: near: a postal code ("4450-208") or municipality ("Matosinhos") to search around; any other text (a parish or village) filters by the incident's location name instead. lat, lon: search around these coordinates (best when the user shares their location). radius_km: search radius around the point (default 10, max 100). kind: "all", "fire", "road", "weather" (trees, floods, wind, landslides) or "rescue". limit: max incidents listed (counts always cover every match). With no place at all, returns the national picture (counts by kind and district, biggest first).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "active_incidents"
  }
}

Input Schema

Name	Required	Default
`lat`	No
`lon`	No
`kind`	No	all
`near`	No
`limit`	No
`radius_km`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does well: it discloses data freshness ('updated every few minutes'), a real coverage limitation (police-only activity is not published anywhere and excluded), and non-obvious result behavior (counts always cover every match even when limit truncates the list). It does not discuss failure modes or what happens with contradictory inputs (e.g. 'near' plus lat/lon), which keeps it short of a 5.

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 purpose and the no-argument default behavior, then a per-argument block. Every line carries information, but the Args list is somewhat verbose and the parenthetical explanations add length that could be tightened slightly.

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 six-parameter, annotation-free query tool, nothing an agent needs in order to call it correctly is missing. Since an output schema exists, the description is not obliged to explain return values, and the extra note about national counts when no location is given covers the one ambiguous case.

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 define all six parameters, and it does: 'near' resolves as postal code, municipality, or a fallback name filter for other text; lat/lon set a search point; radius_km has default 10 and max 100; kind enumerates all, fire, road, weather and rescue (with weather's sub-types spelled out); limit's interaction with counts is explained. This meaningfully 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?

Opens with a specific, scoped statement: live emergency-service occurrences in Portugal, sorted closest first. It enumerates the incident types covered (fires, road collisions, fallen trees, floods, rescues) and explicitly states that police-only PSP/GNR activity is not included, which lets an agent distinguish it from adjacent datasets like fire_risk or earthquakes.

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

Usage Guidelines4/5

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

Gives clear invocation contexts: use 'near' with a postal code or municipality, use lat/lon 'best when the user shares their location', and with no place at all it returns the national picture. That is strong situational guidance, though it does not explicitly name a sibling tool as the alternative for any of these cases.

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

All Portugal (public data) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.