Click on "Install 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., "@vedurstofa-mcp what's the weather in Reykjavik?"
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.
MCP server for Icelandic weather, forecasts, warnings, and earthquakes. Data comes from the Icelandic Meteorological Office (Veðurstofa Íslands, vedur.is). Works with Claude Desktop, Claude Code, and any other MCP client.
Six tools:
Tool | What it returns |
| Current AWS observations per station (temperature, wind, pressure, humidity, precipitation). |
| Per-station multi-day forecasts scraped from vedur.is. Falls back to the text forecast if scraping fails. |
| Prose weather forecasts and text warnings (national, multi-day, or warnings), in English or Icelandic. |
| Structured CAP v1 severe-weather alerts. |
| Recent earthquakes with region presets (Reykjanes, Katla, Bárðarbunga, Tjörnes, Askja, Hekla, Grímsvötn) and arbitrary lat/lon radius filters. |
| Station catalog for ID/name lookups. |
Station inputs accept IDs ("1470") or names with or without diacritics ("Reykjavík", "reykjavik"). Unknown names return a typo-tolerant "did you mean..." error.
Related MCP server: smhi-mcp
Read this section if you're an AI agent picking tools from this server.
No auth, no API key, no setup. Just run npx vedurstofa-mcp over stdio.
All data is Icelandic. If the user asks about weather outside Iceland, stop — this server can't help.
Every response is a JSON envelope with attribution, source, fetched_at, data, and optionally errors, degraded, truncated. Always cite the attribution field when surfacing data to users.
Units are metric. °C, m/s, hPa, mm, km. Convert only when the user asks.
Timestamps are ISO 8601 UTC. Iceland is on UTC year-round (no DST).
User asks about… | Use |
Current temperature, wind, pressure at a location |
|
Hourly forecast for the next hours/days at a location |
|
Narrative / prose forecast (national outlook, multi-day, text warnings) |
|
Severe-weather alerts, storm warnings, structured hazard data |
|
Recent earthquakes — volcanic regions, lat/lon radius, magnitude |
|
"Which stations are there?" / resolving a place name to a station ID |
|
"What's the weather like in Iceland today?" → get_weather_now for the user's city + get_weather_warnings to surface any active alerts. Add get_weather_text with category: "national" only if the user wants a narrative.
"Should I drive from Reykjavík to Akureyri tomorrow?" → get_weather_forecast for both endpoints + get_weather_warnings. Don't pull get_weather_now unless the user asks about right now.
"Are there any earthquakes near me?" → get_earthquakes with region preset if the user names a volcanic system (Reykjanes, Katla, etc.), otherwise near: { lat, lon, radius_km }.
get_weather_forecast scrapes HTML and can fail when the upstream site changes. When this happens, the response carries degraded: true and degraded_reason, and falls back to the national text forecast. Surface this to the user rather than pretending the structured forecast is available.
Node 18+ required.
# Latest
npx -y vedurstofa-mcp
# Version-pinned (recommended for configs that shouldn't drift)
npx -y vedurstofa-mcp@1.0.0The server speaks MCP over stdio, so you won't see interactive output. Plug it into a client.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"vedurstofa": {
"command": "npx",
"args": ["vedurstofa-mcp"]
}
}
}claude mcp add vedurstofa -- npx vedurstofa-mcp~/.cursor/mcp.json:
{
"mcpServers": {
"vedurstofa": {
"command": "npx",
"args": ["vedurstofa-mcp"]
}
}
}In VS Code, open the Cline extension → MCP servers → Edit MCP settings, and add:
{
"mcpServers": {
"vedurstofa": {
"command": "npx",
"args": ["vedurstofa-mcp"]
}
}
}ChatGPT's MCP support (Developer Mode, Plus/Pro and higher) currently accepts only remote MCP servers exposed over an SSE URL, not local stdio servers like this one. To use vedurstofa-mcp with ChatGPT you'd need to wrap it behind an stdio→SSE bridge (e.g. mcp-proxy, supergateway) and point ChatGPT at the bridge URL. See OpenAI's MCP docs for setup.
get_weather_now with stations: ["Reykjavík"]:
{
"attribution": "Icelandic Met Office (vedur.is), CC BY-SA 4.0. ...",
"source": "https://api.vedur.is/weather/observations/aws/hour/latest",
"fetched_at": "2026-04-15T21:00:00.000Z",
"data": {
"observations": [
{
"station_id": "1470",
"station_name": "Reykjavík",
"observed_at": "2026-04-15T20:50:00.000Z",
"temperature_c": 4.2,
"wind_speed_ms": 7.1,
"wind_direction_deg": 230,
"wind_direction_cardinal": "SW",
"pressure_hpa": 1008.4,
"humidity_pct": 82,
"precipitation_mm": 0.0
}
]
}
}get_earthquakes with region: "reykjanes" returns a sorted list of events with timestamp, latitude, longitude, depth_km, magnitude, magnitude_type, location, reviewed. Fields default to null when upstream omits them.
"What's the weather in Reykjavík right now?"
"Compare current conditions in Akureyri, Ísafjörður and Höfn."
"Any weather warnings active for Iceland?"
"Earthquakes near Grindavík in the last 24 hours above magnitude 2."
"Show me the Icelandic multi-day text forecast."
Data comes from the Icelandic Meteorological Office under CC BY-SA 4.0. Every response includes an attribution field. The MIT license in this repo covers the server code only, not the data.
Forecast scraping is fragile. Per-station forecasts are extracted from inline JavaScript on vedur.is pages. When the HTML changes, the scraper falls back to the national text forecast and marks the response degraded: true. File an issue when you see it.
Forecast station coverage is limited to ~13 major named stations. Others share a regional page or have no scrapeable forecast.
Units are metric: °C, m/s, hPa, mm, km. Claude converts on request.
Timestamps are ISO 8601 UTC. Iceland is on UTC year-round (no DST).
npm install
npm run typecheck
npm run test
npm run buildVEDURSTOFA_DEBUG=1 enables debug-level logs on stderr. Stdout is reserved for the MCP protocol.
MIT for the server code. Data is the property of the Icelandic Meteorological Office under CC BY-SA 4.0.
Get recent earthquakes in Iceland with magnitude, location, depth, and timestamp. Filter by named region preset (reykjanes, mydalsjokull, bardarbunga, tjornes, katla, askja, hekla, grimsvotn) or a custom lat/lon radius. Defaults to the last 48 hours and excludes automatic (unreviewed) detections.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | Custom point + radius filter. Mutually exclusive with 'region'. | |
| hours | No | Time window in hours. Max 168 (7 days). Defaults to 48. | |
| region | No | Named region preset. Mutually exclusive with 'near'. Useful for monitoring specific volcanic systems. | |
| min_magnitude | No | Minimum magnitude (Mlw). Defaults to 0 (all events). | |
| include_unreviewed | No | Include automatic unreviewed detections. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers default behavior, filtering options, and mutual exclusivity, but could mention data source or latency for full transparency.
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 concise sentences with no waste; front-loads the purpose and efficiently conveys key behavior.
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?
Despite no output schema, description lists return fields and covers all necessary usage context, making it fully adequate.
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 has 100% coverage, but description adds value by stating defaults and context for region presets (volcanic systems), exceeding the baseline 3.
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 clearly states the tool gets recent earthquakes in Iceland with specific fields (magnitude, location, depth, timestamp), distinguishing it from sibling weather tools.
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?
Provides explicit defaults (48 hours, exclude unreviewed), explains mutual exclusivity of region and near, and suggests volcanic system monitoring for region presets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multi-day hourly weather forecasts for locations in Iceland. Returns hour-by-hour predictions for temperature, wind, precipitation, cloud cover, and dew point. Forecasts are regional (covering one of 10 IMO forecast regions) and scraped from vedur.is; if scraping fails the response falls back to the national text forecast and is marked 'degraded'.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language for the text-forecast fallback. Defaults to 'en'. | |
| hours | No | How many hours of forecast to return, starting from now. Defaults to 72 (3 days). Max 240 (10 days). Keep this tight when the user asks about a specific near-term time. | |
| stations | No | Station IDs or names. Defaults to ['Reykjavík']. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses key behaviors: data source (scraped from vedur.is), regional coverage, and fallback to national text forecast with a 'degraded' marker on failure. No destructive or side effects are omitted.
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?
The description is a single, well-structured paragraph. The first sentence states the primary purpose, and every subsequent sentence adds essential detail (variables, scope, fallback) without redundancy.
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?
For a tool with no output schema, the description lists returned variables and mentions the fallback behavior. It is mostly complete but lacks explicit details on output structure or station ID usage, though the schema covers the latter.
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 100% with each parameter already documented (lang, hours, stations). The tool description adds minimal extra meaning beyond reiterating the fallback language, so baseline score of 3 is appropriate.
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 clearly states it retrieves multi-day hourly forecasts for Iceland, specifies the variables (temperature, wind, etc.), and distinguishes it from siblings by highlighting the granularity and regional scope.
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?
The description implies use for detailed hourly forecasts but does not explicitly state when to use this tool instead of siblings like get_weather_now or get_weather_text. No exclusion criteria or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current weather observations for locations in Iceland. Returns temperature (°C), wind speed and direction (m/s, cardinal + degrees), pressure (hPa), humidity (%), precipitation (mm/h), and snow/visibility data when available. Accepts station IDs or names — call list_weather_stations to discover available stations.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language for description fields. Defaults to 'en'. | |
| stations | No | Station IDs or names, e.g. ['1470', 'Akureyri']. Diacritics optional. Defaults to ['Reykjavík'] when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Lists return data but lacks disclosures about error handling, rate limits, or behavior on invalid stations. Adequate but not thorough.
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 sentences with no redundancy. First sentence states core purpose and data; second covers parameters and discovery. Highly efficient.
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?
No output schema, so description should explain return format. It lists fields and notes 'when available'. Could describe response structure (e.g., per station, time of observation) but sufficient for a simple tool.
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 100% so baseline 3. Description adds meaning: explains stations accept IDs or names, diacritics optional, default to Reykjavík; lang default is 'en'. This enriches schema definitions.
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?
Description clearly states verb 'get current weather observations' for a specific location (Iceland) and lists the returned data fields. Distinguishes from siblings by specifying temporal scope ('now') and references list_weather_stations for discovery.
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?
Provides clear context for when to use (get current weather) and hints at alternative (list_weather_stations for station discovery). Could explicitly contrast with siblings like get_weather_forecast for future data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get written (prose) weather forecasts for Iceland from the Icelandic Meteorological Office. Use for narrative forecasts and text weather warnings. For structured per-station observations use get_weather_now. For structured warnings use get_weather_warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language. Icelandic versions are often more detailed. Defaults to 'en'. | |
| category | No | Which text forecast to fetch. Defaults to 'national'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the source and nature of output (prose, narrative), but does not mention error handling or rate limits. Adequate for a simple read tool.
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?
Three sentences with no fluff. Purpose stated first, followed by usage guidance and alternatives. Efficiently structured.
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?
For a simple tool with two enum parameters and no output schema, the description provides sufficient context: source, content type, and distinctions from siblings. Missing details about return format are not critical.
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 100% with enums. Description adds useful context (Icelandic versions more detailed, defaults) beyond schema definitions.
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 clearly states it gets written/prose weather forecasts from the Icelandic Met Office, distinguishing it from sibling tools that provide structured data.
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?
Explicitly states when to use (narrative forecasts, text warnings) and provides specific alternatives for structured observations and warnings (get_weather_now, get_weather_warnings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active severe-weather warnings (CAP alerts) for Iceland from the Icelandic Meteorological Office. Returns structured alert metadata including severity, certainty, urgency, effective/expiry times, affected areas, and multilingual headlines + descriptions. For narrative text warnings use get_weather_text with category='warnings'.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Filter to info blocks in this language. Default returns all. | |
| include_expired | No | Include expired alerts (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses it returns structured alert metadata, mentions active alerts, and optional parameters. Lacks details on rate limits or authentication, but sufficient for a read-only weather tool.
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 sentences, no wasted words. First sentence captures purpose and outputs, second provides alternative tool reference.
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?
Two optional parameters, outputs clearly described, sufficient for agent to use correctly. No output schema needed for this level of detail.
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 100%, so description adds no extra parameter info beyond schema. Baseline 3 is appropriate.
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?
Clearly states it gets active severe-weather warnings for Iceland from a specific source, lists returned fields (severity, certainty, urgency, etc.), and distinguishes from sibling tool get_weather_text.
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?
Explicitly tells when to use this tool vs get_weather_text for narrative warnings, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List weather stations in Iceland with their IDs, names, types, and coordinates. Use this to look up station IDs for get_weather_now and get_weather_forecast, or to help users discover stations near a region. Stations are loaded from the Icelandic Meteorological Office (api.vedur.is).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stations to return. Defaults to all. | |
| region | No | Case-insensitive substring match against the station's region label (e.g. 'north', 'capital', 'westfjords'). Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions data source ('stations are loaded from the Icelandic Meteorological Office (api.vedur.is)'), which adds transparency. However, it does not disclose behavioral details such as whether results are cached, update frequency, rate limits, or that it is a read-only operation. The mention of 'Defaults to all' for limit is implied but not clearly stated as a default behavior. Overall adequate but lacks deeper behavioral context.
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 sentences, zero wasted words. The first sentence tells exactly what the tool does and what it returns. The second sentence gives usage guidance. Every part earns its place. Well front-loaded.
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?
There is no output schema, so the description should explain the return structure. It lists return fields (IDs, names, types, coordinates) which is helpful. However, it does not explicitly state that the tool returns a list, mention any default ordering, or explain pagination behavior implied by the limit parameter. For a simple two-parameter tool, this is mostly complete but could add a note about sorting or the fact that 'all' is returned when limit is omitted.
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 100%—both parameters (limit and region) already have detailed descriptions including defaults and case-insensitivity. The description restates some of this (e.g., 'Defaults to all' for limit, 'Case-insensitive substring match' for region) but does not add new information beyond the schema. With full coverage, baseline 3 is appropriate; no extra value added.
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 clearly states the tool lists weather stations in Iceland with specific fields (IDs, names, types, coordinates). It explicitly mentions two use cases: looking up station IDs for sibling tools (get_weather_now, get_weather_forecast) and helping users discover stations near a region. This distinguishes it from siblings and gives specific verb+resource scope.
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?
The description explicitly states when to use the tool: to look up station IDs for other tools or to discover stations near a region. It does not explicitly state when not to use it, but the context from sibling names (all weather-related tools) implies this is purely a lookup tool. The region filter hint ('e.g., 'north', 'capital', 'westfjords') provides additional guidance.
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. Dates show when Glama detected each change.
v1.0.1get_earthquakesget_weather_forecastget_weather_nowget_weather_textget_weather_warningslist_weather_stationsEach tool serves a distinct purpose: current observations, multi-day forecast, prose warnings, structured CAP alerts, earthquake data, and station listing. No overlap or ambiguity.
Most tools use 'get_weather_*' or 'get_earthquakes' pattern, but 'list_weather_stations' deviates with 'list_' instead of 'get_'. The naming is generally clear and predictable.
6 tools cover the core functionalities of an Icelandic weather server (observations, forecast, text alerts, structured alerts, earthquakes, station discovery) without bloat or deficiency.
Covers essential weather and earthquake data needs. Minor gaps like historical data or radar imagery are not critical for a basic weather server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server for weather information by @kulybaba
An MCP server for weather information by @kulybaba
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
Geospatial MCP server for earthquake, tsunami, volcano, disaster, and FX data queries.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sandsower/vedurstofa-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server