Skip to main content
Glama

Criora: climate & disaster risk for any place

Interactive climate risk and weather map

show_risk_map
Read-onlyIdempotent

Shows an interactive map of a place in clients that render apps, such as Claude and ChatGPT: this week's forecast risk over the area, hazard events nearby as markers, and the risk by day, which the reader can pan, zoom and open full screen. Instead of the risk, the map can lay the precipitation, temperature or wind forecast under the events (layer), hour by hour over the week, and the reader can switch between all four. A client without apps gets the same summary as text, with a link to the place on Criora's own map.

Use it when the user wants to see the place, the week's risk or the hazards around it on a map, or when a map makes an answer clearer than a list. The figures come from the same sources as get_forecast and get_hazards_near, which give them in full.

Give latitude and longitude, or place, which costs a lookup in the shared geocoder. With both, the coordinates are used and place only names the map, at no lookup: pass the name the user knows the place by, or the map is titled by its coordinates and country.

Input Schema

NameRequiredDescriptionDefault
focusNoWhat the map shows: this week's forecast risk, the hazard events nearby, or bothboth
layerNoThe forecast field the map opens on, under the hazard events: the risk (default), or the precipitation, temperature or wind forecast when the question is about the weather itself. The reader can switch between them on the maprisk
placeNoA place name or address, used only when latitude and longitude are not given. It is resolved to its best match by a geocoder shared by every user and limited to one lookup a second, so pass coordinates when you have them
latitudeNoLatitude of the place asked about, in degrees, WGS84. Give it with longitude, or give place instead
longitudeNoLongitude of the place asked about, in degrees, WGS84. Give it with latitude, or give place instead

Output Schema

NameRequiredDescriptionDefault
daysYesThis week's forecast risk by day; null when not asked for
layerYesThe forecast field the map opens on: risk, precipitation, temperature or wind
placeYes
radius_kmYesHow far the search for events reached
criora_urlYesThe place on Criora's own map
events_totalYesHazard events found near the place; null when not asked for
resolved_fromYesWhat a place name was resolved to; null when coordinates were given
counts_by_typeYesEvery event found, by type; null when not asked for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds behavioral context they cannot express: interactivity (pan, zoom, open full screen), the reader switching layers, the degraded text mode for clients that don't render apps, and the shared geocoder's one-lookup-per-second rate limit. That is substantial beyond-annotation disclosure.

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 capability in the first clause, then layers, then fallback, then usage, then parameters. Every sentence carries information, though the opening sentence is dense and slightly overlong with appending the layer list and interaction modes before the fallback. Slight verbosity, no dead weight.

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 so return values needn't be described, and the annotations cover the safety profile. For a five-parameter, all-optional, rendering-oriented tool, the description supplies everything an agent needs: rendering context, fallback behavior, precedence between place and coordinates, and the geocoder constraint.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: it explains the precedence rule when both coordinates and place are supplied ('the coordinates are used and place only names the map, at no lookup'), the cost of a geocoder lookup, and the layer behavior (map opens on `layer`, reader can switch). This is more than a restatement of the enum titles.

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 verb and resource ('Shows an interactive map of a place') and enumerates exactly what appears on it: this week's risk, hazard markers, day-by-day risk, plus alternate layers. It also distinguishes itself from siblings by noting the figures come from the same sources as get_forecast and get_hazards_near, 'which give them in full.' An agent can tell this apart from the data-returning tools without opening either 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 an explicit when-to-use clause ('when the user wants to see the place, the week's risk or the hazards around it on a map, or when a map makes an answer clearer than a list') and routes competition to the sibling tools that return the same figures in full. The client-capability fallback (text summary plus link when no apps) is genuine addition/exclusion guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.