Skip to main content
Glama

Criora climate risk

Seven-day forecast and weather risk

get_forecast
Read-onlyIdempotent

This week's forecast at a place, and how risky the weather is each day.

Per local day: minimum and maximum temperature, peak precipitation rate, peak wind, and the day's forecast risk class with the hazard behind it (heat, cold, wind, rain, snow, freezing rain) and its physical reading (UTCI felt temperature, gust speed or rain rate). Steps are hourly for the first day, then 3-hourly, then 6-hourly to day seven, and each day gives its step_hours: from the fourth day the minimum and maximum are of 6-hourly steps, so the true peak can fall between two of them. A day marked partial is cut by the start or end of the window. With hourly=true, every step. Source: Environment and Climate Change Canada GDPS global model, read at its own 15 km cell containing the point.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
placeNoA place name or address, used when latitude and longitude are not given
hourlyNoInclude every forecast step, not only the daily summary
latitudeNoLatitude in degrees, WGS84
longitudeNoLongitude in degrees, WGS84

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

With annotations already declaring readOnly and idempotent, the description adds valuable behavioral detail: the temporal resolution changes (hourly, then 3-hourly, then 6-hourly), the 'partial' day marker, the limited precision of 6-hourly min/max to day seven, and the data source (ECCC GDPS, 15 km cell). It does not mention rate limits or caching but covers output semantics well.

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?

The description is front-loaded with the core purpose and then details step resolution and risk classes. It is somewhat long and dense, but every sentence adds useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (time-varying output, multiple risk metrics), an output schema exists so return values need not be explained. The description still adds crucial context on step resolution and data source. It is nearly complete, missing only explicit usage alternatives.

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 coverage is 100%, so all parameters are documented. The description adds context on the `hourly` flag (every step vs daily summary) and `place` behavior, but does not clarify latitude/longitude semantics beyond what the schema provides. Baseline 3 is appropriate.

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 clearly states it returns this week's forecast at a place and each day's weather risk, naming specific metrics (temperature, precipitation rate, wind, risk class). It is specific but does not explicitly differentiate from siblings like get_climate_profile or get_hazards_near, which an agent might confuse for weather-risk queries.

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?

Usage is implied by the description (get a seven-day forecast), but there is no explicit when-to-use guidance or comparison to alternatives such as get_climate_profile (long-term climate) or get_hazards_near (nearby hazards). The agent must infer appropriateness.

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.

Resources