Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@smhi-mcp Will it rain in Uppsala this afternoon, and are there any warnings?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Swedish weather data from SMHI (the Swedish Meteorological and Hydrological Institute). It lets an AI assistant fetch point forecasts, active weather warnings and live station observations for Sweden and the wider Nordic area.
No API key and no account needed: it uses SMHI's public open-data APIs.
Small: about 150 lines of Python. The SMHI client uses only the standard library, and the server needs only the official mcp SDK.
Returns structured JSON and passes Swedish/English text through as published by SMHI.
Tool | Arguments | Returns |
|
| Hourly rows: |
|
| Active warnings, one row per warning area: |
|
| Nearest active station: |
|
| Latest-hour value: |
Errors such as out-of-range coordinates, unknown stations or network failures come back as {"error": "..."} instead of crashing the session.
Example question: "Is it going to rain in Uppsala this afternoon, and are there any warnings for Uppsala län?" The assistant calls get_forecast(59.86, 17.64) and get_warnings(area="Uppsala").
symbol_code is SMHI's weather symbol (1 = clear sky … 27 = heavy snowfall). Parameter ids for find_nearest_station and get_observation follow SMHI's metobs API. For example, 1 is air temperature, 4 is wind speed, 6 is relative humidity and 7 is precipitation.
Related MCP server: Apiverket MCP Server
Requires Python 3.10 or newer.
git clone https://github.com/MarkusIsaksson1982/smhi-mcp.git
cd smhi-mcp
python -m venv .venv && . .venv/bin/activate
pip install -e .
smhi-mcp # speaks MCP over stdioMCP client configuration (Claude Desktop, Cursor and others):
{
"mcpServers": {
"smhi": { "command": "smhi-mcp" }
}
}If smhi-mcp is not on your PATH, use the full path to the virtualenv's bin/smhi-mcp, or "command": "python", "args": ["-m", "smhi_mcp.server"].
The server is also listed on Smithery.
pip install -e '.[dev]'
pytest # offline tests (recorded SMHI responses, no network)
python scripts/smoke_live.py # live smoke test: starts the server and calls all four tools against SMHIAll weather data comes from SMHI open data (opendata.smhi.se) and is licensed under Creative Commons Attribution 4.0 (CC BY 4.0). If you display or redistribute the data, attribute it to SMHI. Each tool response includes "source": "SMHI" where practical.
This is an independent project. It is not affiliated with or endorsed by SMHI. Forecasts and warnings are provided as is, so for safety-critical decisions use SMHI's official channels (smhi.se).
The code is MIT licensed (see LICENSE). The SMHI data it returns is CC BY 4.0, as described above.
Nearest active SMHI observation station for a point. parameter: SMHI metobs parameter id (1 = air temperature).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| parameter | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses one useful trait, that only 'active' stations are returned, but says nothing about permissions, rate limits, distance/search radius behavior, or what happens when no station is nearby for the given parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and followed by the one parameter that needs explaining. No filler; slightly terse rather than bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be described. Still, for a tool with zero schema coverage and no annotations, the description omits permission needs, behavior when no station matches, and the meaning of 'active', leaving gaps an agent may hit in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the non-obvious 'parameter' argument (SMHI metobs parameter id, with 1 = air temperature), but leaves lat and lon entirely undocumented beyond their self-evident names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find) and resource (nearest active SMHI observation station) with a clear input scope (a point). It is distinguishable from siblings like get_observation or get_forecast, though it does not name or explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is a station-lookup step before fetching observations, but there is no explicit when-to-use, when-not-to-use, or named alternative. Nothing misleading, but the routing guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hourly SMHI weather forecast for a point (lat 52-72, lon 2-35): temperature, wind, gusts, precipitation, humidity, symbol code.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| hours | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It usefully discloses the data source (SMHI) and the valid coordinate window, but says nothing about behavior outside that window, units, timezone of the hourly steps, or rate limits, and the read-only nature is only implied by 'forecast'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no waste: resource, provider, valid domain and output fields are front-loaded in that order. Nothing could be cut without losing substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be detailed (though they are listed anyway). The geographic constraint closes the highest-risk gap for a coordinate-based call; the only real omission is the 'hours' parameter and any note on behavior at the domain edges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the load. It adds real value by supplying valid lat/lon ranges that the schema lacks, but the third parameter 'hours' (default 24) is never mentioned, leaving its meaning and bounds undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (hourly SMHI weather forecast), the exact physical domain it applies to (lat 52-72, lon 2-35), and the returned variables, so an agent can separate it from get_observation and get_warnings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the resource name: an agent can infer 'forecast = future conditions' vs 'observation = past conditions' vs 'warnings = alerts', but the description never states when to prefer this tool or what prerequisites exist. No explicit alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest-hour observed value at an SMHI station (parameter 1 = air temperature in °C).
| Name | Required | Description | Default |
|---|---|---|---|
| parameter | No | ||
| station_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait beyond the schema — that only the most recent hour is returned, not arbitrary history — and that parameter 1 maps to air temperature in °C. It omits error behavior for stations without data, auth requirements, and any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the resource and its key constraint appear before the parenthetical detail. Nothing needs trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be described. For a simple 2-param lookup the description covers purpose, time scope, and one parameter, but leaves station_id semantics and non-default parameter codes unexplained, which is thin given the 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 2 parameters, so the description must compensate. It documents the meaning and unit of 'parameter' (1 = air temperature in °C) but says nothing about the required station_id or the other parameter codes, leaving half the surface undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (observed value at an SMHI station) and scopes it temporally ('latest-hour'), which distinguishes it from the forecast-oriented sibling get_forecast. It stops short of explicitly naming the alternatives, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus get_forecast, get_warnings, or find_nearest_station, and no prerequisites (e.g., needing a station_id obtained from find_nearest_station). Usage must be inferred from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active SMHI weather warnings. Optional area filter (substring, e.g. 'Skåne'); lang 'sv' or 'en'.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| lang | No | sv |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden alone. It does disclose meaningful behavior — only active warnings are returned (not historical/archived), and area matching is a substring rather than exact — but it says nothing about auth, rate limits, or freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two telegraphic sentences with zero filler, and the core purpose is front-loaded before the parameter notes. Efficient, if slightly clipped in style.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be described, and both parameters are covered in the prose. For a low-risk read tool this is close to complete, though a note that it is read-only would remove the last ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: it explains that 'area' is a substring match with a concrete example ('Skåne') and that 'lang' accepts 'sv' or 'en'. The schema alone would leave both parameters opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieving active SMHI weather warnings. The resource 'warnings' is naturally distinct from the sibling tools (forecast, observation, station), though the description never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives among find_nearest_station, get_observation, or get_forecast. The word 'Active' hints at scope but the agent must infer the rest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_nearest_stationget_forecastget_observationget_warningsScored 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.
Nordic weather: forecasts, warnings, HD radar, rain nowcast, lightning, aurora, satellite AI.
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
MET Norway (api.met.no) MCP — global weather, Nordics specials.
Swiss weather data for AI assistants — forecasts, measurements, stations, pollen.