Criora: climate & disaster risk for any place

Hazard events in the map's view

get_map_events

Read-onlyIdempotent

The hazard events the interactive map loads when the reader pans or zooms to a new view. The map calls it in clients that display it; to list the hazards near a place, use get_hazards_near.

Input Schema

Name	Required	Description
`latitude`	Yes	Latitude of the view's centre
`longitude`	Yes	Longitude of the view's centre
`radius_km`	Yes	How far the view reaches from its centre, in km

Output Schema

Name	Required	Description	Default
`events`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedOct 21, 2026

addedOutput schema / $defs / MapEvent / description

Added value: +"An event as the page draws it, from whichever read found it: a search near a place gives its\ndistance, a tapped warning read by its id gives none."

addedOutput schema / $defs / MapEvent / properties / active_at

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The latest moment the source reports it active",
+  "title": "Active At"
+}

addedOutput schema / $defs / MapEvent / properties / area

Added value: +{
+  "default": false,
+  "description": "Whether the event covers an area (a warning's, a storm's cone)",
+  "title": "Area",
+  "type": "boolean"
+}

addedOutput schema / $defs / MapEvent / properties / distance_km / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / distance_km / description
```
Added value: +"From the place the map is of; none for a tapped event"
```
addedOutput schema / $defs / MapEvent / properties / event_date / default
```
Added value: +null
```

addedOutput schema / $defs / MapEvent / properties / expires_at

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "When the source says it ends; null when it states none",
+  "title": "Expires At"
+}

addedOutput schema / $defs / MapEvent / properties / kind

Added value: +{
+  "default": "occurrence",
+  "description": "occurrence, warning or status",
+  "title": "Kind",
+  "type": "string"
+}

addedOutput schema / $defs / MapEvent / properties / label / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / nature / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / severity / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / source / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / value / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / value_normalized / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / value_text / default
```
Added value: +null
```
addedOutput schema / $defs / MapEvent / properties / value_unit / default
```
Added value: +null
```

changedOutput schema / $defs / MapEvent / required

Previous value: -[
-  "id",
-  "type",
-  "nature",
-  "lat",
-  "lon",
-  "severity",
-  "value",
-  "value_unit",
-  "value_normalized",
-  "value_text",
-  "event_date",
-  "source",
-  "label",
-  "distance_km"
-]New value: +[
+  "id",
+  "type",
+  "lat",
+  "lon"
+]

AddedOct 15, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds real behavioral context beyond that: this tool is viewport-driven, invoked repeatedly on pan/zoom, which signals a high-frequency-per-view usage pattern. It stops short of mentioning pagination, result caps, or caching behavior for repeated viewport calls.

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?

Two compact sentences with the resource and scope front-loaded and the alternative routing at the end. The clause "The map calls it in clients that display it" is slightly redundant padding, but overall there is little waste.

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?

An output schema exists, annotations cover the safety profile, and all three parameters are fully described in the schema, so the description need only establish purpose, usage mode, and sibling routing. It does all three; remaining gaps (rate limits, distinction from get_map_event/get_map_warnings) are marginal given the structured coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so latitude, longitude, and radius_km are fully documented with bounds and meanings in the schema. The description adds only the loose framing of "the view's centre and reach" via the pan/zoom language, which the schema already conveys; baseline 3 applies when the schema does the heavy lifting.

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 names a specific resource (hazard events) and scope (the map's current viewport as the reader pans or zooms), and explicitly distinguishes it from get_hazards_near. However, it is phrased as a noun phrase describing what the map does rather than a direct verb stating what the tool returns to the caller, leaving a small ambiguity.

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?

One alternative is named and conditionally routed ("to list the hazards near a place, use get_hazards_near"), which helps. But the primary guidance is "the map calls it in clients that display it," which describes an internal client behavior rather than telling the agent when it should or should not call this tool, and it never differentiates from the closely named siblings get_map_event or get_map_warnings.

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

All Criora: climate & disaster risk for any place 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.