smhi-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_forecastA | Hourly SMHI weather forecast for a point (lat 52-72, lon 2-35): temperature, wind, gusts, precipitation, humidity, symbol code. |
| get_warningsB | Active SMHI weather warnings. Optional area filter (substring, e.g. 'Skåne'); lang 'sv' or 'en'. |
| find_nearest_stationB | Nearest active SMHI observation station for a point. parameter: SMHI metobs parameter id (1 = air temperature). |
| get_observationB | Latest-hour observed value at an SMHI station (parameter 1 = air temperature in °C). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a clearly distinct resource: station lookup, current observation, future forecast, and alerts. The find_nearest_station/get_observation pair is complementary (one supplies the station id the other needs) rather than overlapping, and observation vs. forecast is unambiguous from the descriptions.
All tools use snake_case with a verb_noun structure (find_nearest_station, get_observation, get_forecast, get_warnings). The find-vs-get distinction is semantically meaningful (search vs. retrieve) rather than an inconsistency.
Four tools is slightly lean but each earns its place, covering the core surface of a weather API: station lookup, observations, forecasts, and warnings. Nothing is redundant, though it sits at the lower end of a comfortable range.
The surface covers the main workflows of a weather service: locate a station, read its latest observation, get an hourly forecast, and check warnings. Minor gaps exist (e.g. no historical/archive data or multi-parameter observation queries), but core needs are met.