How do I use smhi-weather-forcast-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@smhi-weather-forcast-mcp-server What's the 10-day weather forecast for Stockholm?" 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.

smhi-weather-forcast-mcp-server

by ribomation

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

SMHI Weather Forecast MCP Server

A Model Context Protocol (MCP) server that provides access to SMHI (Swedish Meteorological and Hydrological Institute) weather data, including forecasts and historical observations.

Disclaimer 😳

This project is the result of an experiment of using Claude Code AI plus Wispr Flow, where I mostly talk via Wispr to Claude, which then implements an MCP server connecting to the Swedish weather data service (SMHI). You can find my article (in Swedish) at this url https://www.ribomation.se/blog/2026/sa-har-kopplar-du-smhi-till-claude-ai/

The main objective is the journey, not the end result. That means, read the article, use Claude and follow along with the prompts and recreate your own weather service MCP.

Related MCP server: mcp-danish-weather

Features

🌤️ Weather Forecasts - Get 10-day weather forecasts for any location in Sweden
📊 Historical Data - Access weather observations from 996+ SMHI stations
🏢 Station Listings - Browse available weather stations by parameter
📋 Parameter Catalog - List all 40+ available weather parameters

Installation

Prerequisites

Node.js 18.0.0 or higher
npm

Setup

Clone the repository:

git clone https://github.com/ribomation/smhi-weather-forecast-mcp-server.git
cd smhi-weather-forecast-mcp-server

Install dependencies:

npm install

Build the server:

npm run build

Usage

With Claude Desktop

Add this to your Claude Desktop configuration file:

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "smhi-weather": {
      "command": "node",
      "args": [
        "/path/to/smhi-weather-forcast-mcp-server.js"
      ]
    }
  }
}

Then restart Claude Desktop.

With Other MCP Clients

The server uses stdio transport and can be integrated with any MCP client that supports stdio.

Available Tools

1. `get-weather-forecast`

Get weather forecast for a specific location.

Parameters:

longitude (number, required): Longitude coordinate (-180 to 180)
latitude (number, required): Latitude coordinate (-90 to 90)
category (string, optional): Forecast category (default: "pmp3g")

Example:

{
  "longitude": 18.0686,
  "latitude": 59.3293
}

Returns: Complete forecast data for ~10 days with hourly weather parameters.

2. `get-weather-observations`

Get historical weather observations from a SMHI station.

Parameters:

stationId (number, required): SMHI station ID
parameterId (number, required): Parameter ID (see common parameters below)
period (string, optional): Time period - one of:
- "latest-hour" (default)
- "latest-day"
- "latest-months"
- "corrected-archive"

Example:

{
  "stationId": 188790,
  "parameterId": 1,
  "period": "latest-hour"
}

Returns: Historical observation data with timestamps, values, and quality codes.

3. `list-weather-stations`

List available SMHI weather stations for a specific parameter.

Parameters:

parameterId (number, required): Parameter ID to filter stations

Example:

{
  "parameterId": 1
}

Returns: List of stations with ID, name, coordinates, elevation, and active status.

4. `list-weather-parameters`

List all available weather parameters.

Parameters: None

Returns: Complete list of queryable weather parameters with IDs and descriptions.

Common Weather Parameters

Parameter	ID	Description
Temperature	1	Air temperature (°C)
Wind Direction	3	Wind direction (degrees)
Wind Speed	4	Wind speed (m/s)
Precipitation	5	Precipitation (mm)
Humidity	6	Relative humidity (%)
Snow Depth	8	Snow depth (cm)
Pressure	9	Air pressure (hPa)
Visibility	12	Visibility (km)

Development

Scripts

npm run build - Build the project with tsup
npm run dev - Run in development mode with watch
npm run type-check - Type check without building
npm start - Start the built server

Project Structure

src/
├── index.ts              # Entry point
├── server.ts             # MCP server setup
├── services/
│   ├── smhi-api.ts       # SMHI API client
│   ├── types.ts          # TypeScript types
│   └── test-api.ts       # API test script
└── (tools/, utils/ - for future expansion)

dist/                     # Build output (generated)

API Documentation

This server uses the SMHI Open Data API:

Forecast API: https://opendata.smhi.se/apidocs/metfcst/
Observations API: https://opendata.smhi.se/apidocs/metobs/
Main Portal: https://opendata.smhi.se/

Important Notes

⚠️ API Changes: SMHI is modernizing their APIs during spring 2026. The current APIs used by this server may be deprecated. Monitor SMHI's updates page for changes.

Examples

Get Stockholm Weather Forecast

Ask Claude:

"What's the weather forecast for Stockholm?"

Claude will use get-weather-forecast with Stockholm's coordinates (18.0686, 59.3293).

Find Temperature Stations

Ask Claude:

"List all active temperature measurement stations in Sweden"

Claude will use list-weather-stations with parameterId: 1 (temperature).

Get Historical Data

Ask Claude:

"Show me the temperature readings from Abisko station for the last hour"

Claude will:

Use list-weather-stations to find Abisko's station ID
Use get-weather-observations to fetch the temperature data

License

MIT

Built with Model Context Protocol by Anthropic.

Available Tools

4 tools

get-weather-forecastA

Get weather forecast for a specific location from SMHI. Returns forecast data for approximately 10 days ahead.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Forecast category (default: pmp3g for point forecast)	pmp3g
`latitude`	Yes	Latitude coordinate (-90 to 90)
`longitude`	Yes	Longitude coordinate (-180 to 180)

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool 'Returns forecast data for approximately 10 days ahead,' which is useful. However, it omits details like return format, coordinate system, potential errors, or any limitations, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, immediately stating the core function and a key detail (10-day horizon). No redundant words or filler, making it highly concise and front-loaded.

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

Completeness2/5

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

There is no output schema and no annotations, so the description must compensate. It mentions forecast duration but lacks critical details like temporal granularity (hourly/daily), units, response structure, or prerequisites (e.g., valid SMHI coverage areas). This is insufficient for an agent to properly invoke and interpret the result.

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%, with clear descriptions for longitude, latitude, and category. The description adds no further parameter context (e.g., how category affects the forecast), so it provides no value beyond the schema, matching the baseline of 3.

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?

The description clearly states the tool's function: 'Get weather forecast for a specific location from SMHI.' The verb 'get' and resource 'weather forecast' are specific, and mentioning SMHI and 'specific location' distinguishes it from siblings like 'list-weather-stations' and 'get-weather-observations.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by saying 'for a specific location' and 'from SMHI,' implying this is for point-based forecasts rather than station lists or observations. However, it does not explicitly mention alternatives or when not to use the tool, so it falls short of a 5.

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

get-weather-observationsA

Get historical weather observations from a SMHI weather station.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Time period to fetch observations for	latest-hour
`stationId`	Yes	SMHI station ID
`parameterId`	Yes	Parameter ID (1=temperature, 3=wind direction, 4=wind speed, 5=precipitation, 6=humidity, 8=snow depth, 9=pressure, 12=visibility)

TDQS

A3.5/5.0

Behavior2/5

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 only states the basic read operation and does not disclose response format, pagination, data units, or any other behavioral details a caller might need.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the purpose with no wasted words.

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

Completeness3/5

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

The tool is simple with well-documented parameters, but it has no output schema and the description does not explain what the returned observations look like, leaving a gap in completeness for an agent invoking it.

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?

All parameters are documented in the input schema with descriptions (100% coverage), and the tool description adds no additional parameter context. This matches the baseline score of 3 for high schema coverage.

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?

The description clearly states the verb 'Get' and the resource 'historical weather observations from a SMHI weather station', which distinguishes it from the sibling tools get-weather-forecast (forecast vs historical) and the list-* tools (list vs get).

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?

The word 'historical' implies that this tool is for past observations rather than forecasts, but the description does not explicitly mention alternatives or when to prefer this tool over get-weather-forecast or list-weather-stations.

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

list-weather-parametersA

List all available weather parameters that can be queried from SMHI.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It states the action and scope ('List all available weather parameters'), which is adequate for a simple read-only list operation, but it does not disclose the return format, whether the list is exhaustive or filtered by endpoint, or any potential constraints. This is minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the verb 'List' and the object, and contains no unnecessary words. It effectively communicates the tool's purpose without bloat.

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 low complexity (no parameters, no output schema), the description is mostly complete for an agent to understand the function. However, it lacks any hint about how these parameters relate to sibling tools (e.g., that they are used to construct forecast or observation queries), which would provide fuller context for selection and invocation.

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?

The input schema has zero parameters, and the description correctly implies none are needed. Per the rubric, 0 parameters earns a baseline of 4. There is nothing to add beyond what the schema already conveys, and the description does not introduce conflicting param expectations.

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?

The description uses the specific verb 'List' with the resource 'all available weather parameters', and adds 'from SMHI' for domain context. This clearly distinguishes it from sibling tools like 'list-weather-stations' (stations) and 'get-weather-forecast' (forecast data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool compared to alternatives. It simply states what it does, with no mention of related tools like 'get-weather-forecast' or 'get-weather-observations' that would consume these parameters, nor any qualifications like 'use this before querying forecasts.'

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

list-weather-stationsB

List available SMHI weather stations for a specific parameter.

ParametersJSON Schema

Name	Required	Description	Default
`parameterId`	Yes	Parameter ID to filter stations by (e.g., 1 for temperature)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'List available' without specifying what 'available' means, whether the result is filtered by current status, or what the response structure looks like (e.g., station IDs, names, coordinates). No behavioral traits are disclosed beyond the basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler or redundancy. It directly states the primary action and scope, making it highly concise and focused.

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

Completeness3/5

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

The tool is simple (one parameter, no output schema), and the description provides a clear purpose, but it lacks details about the return format and the meaning of 'available'. Given the lack of annotations and output schema, the description is minimally viable but leaves some ambiguity.

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% and the parameter description already explains the parameter is a filter for stations by ID, with an example. The description's phrase 'for a specific parameter' adds minimal value beyond the schema, so the baseline of 3 is appropriate.

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?

The description uses a specific verb ('List') and clearly identifies the resource ('SMHI weather stations') with a scope ('for a specific parameter'). It effectively distinguishes itself from sibling tools like list-weather-parameters, which lists parameters, and get-weather-forecast/observations, which retrieve data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this tool might be a prerequisite for fetching forecasts or observations, nor does it explain the typical workflow of selecting stations for a parameter.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Aug 10, 2026
- First observedget-weather-forecast
- First observedget-weather-observations
- First observedlist-weather-parameters
- First observedlist-weather-stations

Deploy Server

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

TDQS

A4/5.0

Scored 2026-08-10 08:55 across 4 tools

Disambiguation5/5

Each tool targets a distinct resource and action: listing stations, listing parameters, fetching forecasts, and fetching observations. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with lowercase and hyphens: list-weather-stations, list-weather-parameters, get-weather-forecast, get-weather-observations. The naming is uniform and predictable.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose. It covers metadata discovery and the two main data fetch operations without unnecessary bloat or thinness.

Completeness5/5

The tool surface covers the essential SMHI workflow: discover parameters, discover stations, get forecast, get observations. No critical dead ends are apparent for the stated domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

met-mcp A
io.github.trondbjoroy
Weather forecasts from MET Norway (Yr): geocoding plus hourly forecasts worldwide.
Weather Services Location Services
81
Meteostat A
io.github.pipeworx-io
Meteostat MCP — historical weather from 11k+ stations (no auth)
Weather Services Open Data
342
open-meteo-mcp-server A
io.github.cyanheads
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
Weather Services Location Services
1127
Fmi A
io.github.pipeworx-io
Finnish Meteorological Institute open data (forecast, observations, warnings)
Weather Services Open Data
352

Related MCP Servers

KNMI MCP Server
dstotijn
A
license
A
quality
D
maintenance
Provides access to Dutch weather data (current conditions, forecasts, alerts, and historical data) via the KNMI API, with automatic location name resolution for Dutch cities.
Updated a year ago (2025-07-19 20:14 UTC)
1
13 npm
1
Apache 2.0
mcp-danish-weather
Weather Services Location Services Open Data
robobobby
A
license
A
quality
D
maintenance
Provides access to Danish weather data from the Danish Meteorological Institute, enabling users to retrieve current conditions, hourly forecasts, and historical records. It supports location lookups via city names, postal codes, and coordinates for any Danish region.
Updated 7 months ago (2026-02-17 00:03 UTC)
3
5 npm
MIT
mcp-swedish-weather
Weather Services Government Data Open Data
robobobby
A
license
B
quality
D
maintenance
Provides access to current weather conditions and hourly forecasts for any location in Sweden using the SMHI Open Data API. It supports built-in city lists, coordinate inputs, and geocoding fallback to deliver detailed meteorological data without requiring authentication.
Updated 7 months ago (2026-02-22 00:05 UTC)
2
5 npm
MIT
meteo-swiss-mcp
Weather Services Open Data
cuolm
A
license
Not graded
quality
D
maintenance
Exposes Swiss weather forecast data as MCP tools, including rainfall, sunshine, temperature, wind, and more, with local caching.
Updated a year ago (2025-09-19 07:17 UTC)
1
Apache 2.0

SMHI Weather Forecast MCP Server

Disclaimer 😳

Features

Installation

Prerequisites

Setup

Usage

With Claude Desktop

With Other MCP Clients

Available Tools

1. get-weather-forecast

2. get-weather-observations

3. list-weather-stations

4. list-weather-parameters

Common Weather Parameters

Development

Scripts

Project Structure

API Documentation

Important Notes

Examples

Get Stockholm Weather Forecast

Find Temperature Stations

Get Historical Data

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `get-weather-forecast`

2. `get-weather-observations`

3. `list-weather-stations`

4. `list-weather-parameters`