What can you do with this server?

The geosphere-mcp-server provides high-resolution weather and air quality data for Austria and the Alpine region via Model Context Protocol, with compact emoji-markdown output for LLM pipelines. It offers: * Current weather conditions (get_current_weather): temperature, feels-like, condition, humidity, wind, precipitation, pressure, cloud cover—using INCA, nowcast, and AROME data. * Hourly forecasts (get_hourly_forecast): hour-by-hour forecasts up to ~60 hours, including precipitation probability from C-LAEF; start time and hours configurable. * Storm outlook (get_storm_outlook): peak wind gusts for the next 1 and 12 hours, thunderstorm timing, and peak CAPE over the next 12 hours (no severity verdict). * Air quality (get_air_quality): current NO₂, O₃, PM10, PM2.5 concentrations and European AQI forecast for today, tomorrow, and in two days from WRF-Chem. Coverage is limited to Austria and the Alpine region; points outside return an out-of-coverage notice. There is no multi-day forecast beyond ~60 hours and no geocoder—coordinates must be provided directly.

How do I use geosphere-mcp-server?

1. Click on "Install 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., "@geosphere-mcp-server weather in Vienna" 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.

geosphere-mcp-server

by slettmayer

Overview Schema Related Servers Score Discussions

Python

Remote

geosphere-mcp-server

PyPI Python License: MIT

MCP server for weather: current conditions, hourly forecasts, storm outlooks, and air quality for Austria and the Alpine region, via the Model Context Protocol.

It serves high-resolution GeoSphere Austria data — the AROME numerical forecast, the INCA analysis/nowcast, the C-LAEF ensemble for precipitation probability, and the WRF-Chem air-quality forecast. There is no worldwide fallback: a point outside the AROME grid returns an out-of-coverage notice, so pair this with a global weather source if you need one. Every response states which datasets produced it.

Output is compact emoji-markdown with metric units — built for smart-home and voice-assistant LLM pipelines where a terse, readable answer beats a JSON blob. Weather conditions are derived from physical parameters and reported with the Home Assistant condition vocabulary (sunny, partlycloudy, rainy, snowy, …).

Coverage

Where	`get_current_weather`	`get_hourly_forecast`	`get_storm_outlook`	`get_air_quality`
Austria	INCA + nowcast + AROME	AROME (≤60 h) + C-LAEF probability	AROME, CAPE gated by CIN	WRF-Chem (3 km)
Alps (non-AT)	AROME only	AROME (≤60 h) + C-LAEF probability	AROME, CAPE gated by CIN	WRF-Chem (3 km)
Rest of world	not served	not served	not served	not served

Coverage is decided by the API, not by a bounding box you configure: GeoSphere answers HTTP 400 for a point outside the grid, and the server renders that as

⚠️ Outside coverage — this server only serves Austria and the Alpine region.

That line is deliberately distinct from the transient failures (⚠️ Timeout…, ⚠️ No weather data available): being outside coverage is a permanent property of the location, so retrying will never help. It names no grid on purpose — the forecast tools query AROME (2.5 km) and get_air_quality queries WRF-Chem (3 km), so a point can be inside one and outside the other.

There is no multi-day forecast. GeoSphere publishes nothing beyond AROME's ~60 h, so the longest answer this server can give is roughly two and a half days of hourly rows.

Related MCP server: wetter-mcp-server

Installation

Pass decimal latitude/longitude to every tool. There is no geocoder in the server — the calling LLM geocodes city names to coordinates itself.

Claude Desktop

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "geosphere": {
      "command": "uvx",
      "args": ["geosphere-mcp-server"]
    }
  }
}

Claude Code

claude mcp add geosphere -- uvx geosphere-mcp-server

From source (development)

{
  "mcpServers": {
    "geosphere": {
      "command": "uvx",
      "args": ["--from", "/path/to/geosphere-mcp-server", "geosphere-mcp-server"]
    }
  }
}

Home Assistant

It is a standard stdio MCP server, so it runs anywhere an stdio MCP server can be hosted — including alongside Home Assistant's Assist pipeline (register it the same way as any other stdio MCP server). Give the voice agent the coordinates of the places it should answer for, or let it geocode names.

Tools

`get_current_weather`

Current conditions for a point, from INCA, the 15-minute nowcast, and AROME.

Parameter	Type	Default	Description
`latitude`	float	required	Decimal latitude (e.g. `48.2208`)
`longitude`	float	required	Decimal longitude (e.g. `16.3738`)

# Current Weather at 48.2208, 16.3738

🌡️ Temperature: 24.7°C (feels like 24.2°C)
🌤️ Condition: partlycloudy
💧 Humidity: 52%
💨 Wind: 2.9 m/s from 135° (gusts 7 m/s)
🌧️ Precipitation (last hour): 0 mm
📊 Pressure: 1016 hPa
☁️ Cloud cover: 30%
🕐 Timezone: Europe/Vienna (CEST)
📡 Source: GeoSphere (INCA + nowcast + AROME) — observed 15:20

`get_hourly_forecast`

Hour-by-hour forecast from AROME, with C-LAEF precipitation probability, up to ~60 h.

Parameter	Type	Default	Description
`latitude`	float	required	Decimal latitude (e.g. `48.2208`)
`longitude`	float	required	Decimal longitude (e.g. `16.3738`)
`hours`	int	24	Forecast hours (clamped to 1–60)
`start`	string	now	Optional ISO 8601 start (e.g. `2026-07-22T15:00`); forecast begins at/after this instant

# 3-Hour Forecast for 48.2208, 16.3738

AROME model, reference 2026-07-22 12:00 CEST · Source: GeoSphere (AROME + C-LAEF ensemble)

Wed 2026-07-22
  15:00: 24.7°C — partlycloudy, wind 3 m/s
  16:00: 23.9°C — rainy, 1.2 mm (70% chance), wind 4 m/s
  17:00: 22.5°C — cloudy, wind 3 m/s

The hours are grouped under a day-divider header (%a %Y-%m-%d in the point's local timezone) that repeats whenever the local date changes, so a window crossing midnight stays unambiguous. Requesting more hours than the AROME horizon provides appends a note naming where the horizon ends — there is nothing further ahead to reach for. Dry hours omit the precipitation and probability parts.

`get_storm_outlook`

Severe-weather outlook: peak gusts and thunderstorm timing. Reports figures, never a severity verdict — what counts as dangerous is the caller's judgement.

Parameter	Type	Default	Description
`latitude`	float	required	Decimal latitude (e.g. `48.2208`)
`longitude`	float	required	Decimal longitude (e.g. `16.3738`)

# Storm Outlook for 48.2208, 16.3738

AROME model, reference 2026-08-10 14:00 CEST · Source: GeoSphere (AROME)

💨 Max gust next 1 h: 12 m/s (at Mon 2026-08-10 17:00)
💨 Max gust next 12 h: 24 m/s (at Mon 2026-08-10 20:00)
⛈️ Thunderstorm expected next 1 h: no
⚡ Next thunderstorm: Mon 2026-08-10 20:00 (CAPE 1800 J/kg)
🌡️ Max CAPE next 12 h: 1800 J/kg
🕐 Timezone: Europe/Vienna (CEST)

Two behaviours are worth knowing before you build on this:

Horizons round up to whole hours. The window starts at the top of the current hour, so the "next 1 h" figure covers the hour already under way plus the next one, and can report an event up to ~2 h out. Compare the returned timestamps yourself if you need a strict 60-minute answer.
Next thunderstorm can be in the past, by up to 59 minutes, when the storm hour is the one already under way. That means a storm is in progress — clamp a negative lead time to zero rather than assuming the stamp is in the future.
An all-clear names its horizon (none in the next 54 h). AROME nominally runs ~60 h, but a stale or truncated run reaches less far, so the span is measured from the rows actually returned. It is not an all-clear beyond the stated span.

A thunderstorm hour is one whose derived condition is lightning/lightning-rainy, or one where CAPE ≥ 1000 J/kg with weak inhibition and precipitation is forecast — the second branch catches thundersnow and hours with missing cloud data, and requires precipitation so that a dry high-CAPE afternoon does not raise a signal. Thunderstorm expected and Next thunderstorm both report unknown rather than a confident answer when the forecast holds no usable hour.

`get_air_quality`

Pollutant concentrations now, plus the European Air Quality Index for today, tomorrow and in two days.

Parameter	Type	Default	Description
`latitude`	float	required	Decimal latitude (e.g. `48.2208`)
`longitude`	float	required	Decimal longitude (e.g. `16.3738`)

# Air Quality at 48.2208, 16.3738

🏷️ European AQI: 2 (fair) today · 3 (moderate) tomorrow · 2 (fair) in 2 days
🌫️ Concentrations (16:00): NO₂ 18 µg/m³ · O₃ 92 µg/m³ · PM10 21 µg/m³ · PM2.5 12 µg/m³
🕐 Timezone: Europe/Vienna (CEST)
📡 Source: GeoSphere (WRF-Chem + daily AQI, 3 km)

The AQI is reported as its 1–6 EEA band (1 good … 6 extremely poor), which is what GeoSphere publishes — there is no underlying numeric index to show alongside it. These are model forecasts, not station measurements — expect them to track a nearby monitoring station without matching it.

A point inside the 3 km grid can still come back empty when a WRF-Chem run is stale or incomplete; the response then says No air-quality data available for this location and still names the source, which is a different answer from being out of coverage.

Data sources & attribution

GeoSphere Austria Dataset API — AROME forecast, INCA analysis/nowcast, C-LAEF ensemble, WRF-Chem air quality. Data licensed under CC-BY 4.0. © GeoSphere Austria.

The API is keyless and intended for non-commercial use. When you redistribute its data, keep the attribution.

Rate limits

The GeoSphere Dataset API allows 5 requests/second and 240 requests/hour. Each call issues a small burst of concurrent requests (three for current weather, two for hourly and air quality, one for the storm outlook); on an HTTP 429 the server retries once (when the API asks for a short wait) and otherwise returns a rate-limit notice.

Development

# Install dependencies (creates .venv from the locked versions)
uv sync

# Lint & format
ruff check .
ruff format .

# Run unit tests
pytest -m "not integration"

# Run integration tests (hits the live GeoSphere API)
pytest -m integration

License

MIT

Available Tools

4 tools

get_air_qualityA

Get air quality for a location: pollutants now and the AQI outlook.

Reports current NO₂, O₃, PM10 and PM2.5 surface concentrations plus the
European Air Quality Index (1-6 EEA bands) for today, tomorrow and in two
days.

GeoSphere's WRF-Chem forecast (3 km) serves Austria and the Alpine region
only; a point outside that grid returns an out-of-coverage notice. These
are model forecasts, not station measurements.

An in-coverage point can still come back empty when a WRF-Chem run is
stale or incomplete — the response then says so and names the source that
drew the blank, which is a different answer from being out of coverage.

Args:
    latitude: Decimal latitude (e.g. 48.2208 for Vienna). Geocode city
        names to coordinates yourself.
    longitude: Decimal longitude (e.g. 16.3738 for Vienna).

ParametersJSON Schema

Name	Required	Description	Default
`latitude`	Yes
`longitude`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries full burden and excels: it discloses the geographic coverage limitation, the model-forecast nature, the possibility of an empty response due to stale/incomplete runs, and that an out-of-coverage notice differs from a blank response. This goes well beyond basic behavior.

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 dense but well-structured: a one-line summary, followed by output specifics, coverage/limitations, edge-case behavior, and parameter notes. Every sentence adds relevant information without redundancy, achieving conciseness through organization rather than brevity for its own sake.

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

Completeness5/5

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

Given the tool's moderate complexity and the existence of an output schema (which covers return values), the description covers all necessary context: what it returns, geographic coverage, data source caveats, how to handle edge cases, and parameter preparation. It leaves no obvious gaps for an agent to misuse the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. The Args section provides decimal examples for latitude/longitude (Vienna coordinates) and explicitly states 'Geocode city names to coordinates yourself,' giving meaningful semantic guidance beyond the bare number type in the schema.

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 opens with a specific verb and resource: 'Get air quality for a location: pollutants now and the AQI outlook.' It further details the exact pollutants (NO₂, O₃, PM10, PM2.5) and the European Air Quality Index bands, making it unmistakably distinct from sibling weather/storm tools.

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?

It provides clear context and restrictions: 'serves Austria and the Alpine region only,' 'model forecasts, not station measurements,' and instructs users to geocode city names themselves. However, it does not explicitly name alternatives or state when not to use this tool versus its siblings, stopping 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_current_weatherA

Get current weather conditions for a location.

High-resolution GeoSphere Austria data (AROME/INCA/nowcast). Serves Austria
and the Alpine region only; a point outside that grid returns an
out-of-coverage notice. The response states which datasets served it.

Args:
    latitude: Decimal latitude (e.g. 48.2208 for Vienna). Geocode city
        names to coordinates yourself.
    longitude: Decimal longitude (e.g. 16.3738 for Vienna).

ParametersJSON Schema

Name	Required	Description	Default
`latitude`	Yes
`longitude`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description fully discloses the data source (AROME/INCA/nowcast), the out-of-coverage notice behavior, and that the response indicates which datasets served it. This goes beyond a simple read-only claim and gives the agent a concrete model of the tool's behavior.

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 compact and front-loaded with the main purpose. The 'Args' section adds example values without redundant explanation, and every sentence contributes useful information. No filler or vague language is present.

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

Completeness5/5

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

For a two-parameter read-only tool with an output schema available, the description covers the essential aspects: geographic coverage, data source, parameter format, and error behavior. It does not need to explain return values because the output schema exists, and the description satisfies all other contextual needs.

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 only lists 'latitude' and 'longitude' with no descriptions, so the description must add meaning. It does so by specifying 'Decimal latitude' and providing concrete examples (48.2208 for Vienna), plus instructing the agent to geocode city names. This compensates fully for the 0% 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 opens with 'Get current weather conditions for a location,' clearly naming the verb and resource. Since sibling tools cover hourly forecast, storm outlook, and air quality, this tool is distinctly positioned as the current-conditions option.

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 explicitly states the geographic limitation ('Austria and the Alpine region only') and instructs the agent to geocode city names to coordinates itself. It does not explicitly reference sibling tools, but the scope and parameter requirements give clear guidance on when this tool is appropriate.

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

get_hourly_forecastA

Get an hour-by-hour weather forecast for a location.

High-resolution GeoSphere AROME data (up to ~60 h, with C-LAEF
precipitation probability). Serves Austria and the Alpine region only; a
point outside that grid returns an out-of-coverage notice.

Args:
    latitude: Decimal latitude (e.g. 48.2208 for Vienna). Geocode city
        names to coordinates yourself.
    longitude: Decimal longitude (e.g. 16.3738 for Vienna).
    hours: Number of forecast hours (default 24, clamped to 1–60).
    start: Optional ISO 8601 start time (e.g. "2026-07-22T15:00"); the
        forecast begins at/after this instant instead of now.

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No
`start`	No
`latitude`	Yes
`longitude`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/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 key behaviors: the data source (AROME/C-LAEF), forecast horizon (up to ~60 h), hours clamping (1–60), and the start parameter semantics ('begins at/after this instant'). It also warns about out-of-coverage responses. It doesn't mention auth, rate limits, or side effects, but for a read-only forecast tool these are less critical; the provided behavioral details exceed what a title/schema alone would offer.

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 well-structured: a one-sentence purpose, a brief context sentence with data source and coverage, a note on out-of-coverage behavior, and a clearly separated Args section. It is concise enough for a 4-parameter tool, and every sentence contributes either purpose, constraints, or parameter semantics. No filler or redundancy.

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

Completeness5/5

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

The tool is moderately complex with 4 parameters and an output schema. The description covers all necessary aspects: what it does, where it works, parameter details, and edge-case behavior (out-of-coverage). Since an output schema exists, the description doesn't need to explain return values. The coverage is complete for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain parameters. It does: latitude/longitude with a concrete example, hours with default and clamp range, and start with an ISO 8601 example and behavior ('forecast begins at/after this instant'). Every parameter in the schema is accounted for, and the description adds meaningful constraints and formats beyond the bare type definitions.

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 opens with a specific verb+resource: 'Get an hour-by-hour weather forecast for a location.' This clearly distinguishes it from sibling tools like get_current_weather (current conditions) and get_storm_outlook (storm alerts). The mention of 'hour-by-hour' and 'forecast' makes the tool's unique scope obvious.

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 states clear usage context: it serves Austria and the Alpine region only, and explicitly notes that a point outside the grid returns an out-of-coverage notice. It also instructs the agent to geocode city names to coordinates itself, implying a prerequisite. It does not name alternative tools explicitly, but the geographic constraint and hour-by-hour nature create clear usage boundaries.

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

get_storm_outlookA

Get the severe-weather outlook for a location: gusts and thunderstorms.

Reports the peak wind gust within the next hour and the next 12 hours,
whether a thunderstorm is expected within the next hour, when the next
thunderstorm is expected across the whole forecast horizon, and the peak
CAPE over the next 12 hours. Deliberately reports no severity verdict —
what counts as dangerous is the caller's judgement.

High-resolution GeoSphere AROME data, whose CAPE is gated by convective
inhibition. Serves Austria and the Alpine region only; a point outside that
grid returns an out-of-coverage notice.

The thunderstorm scan covers the AROME horizon, nominally ~60 h but shorter
when a run is stale or truncated. A "none in the next N h" answer names the
horizon it actually covered; it is not an all-clear beyond that.

Horizons round up to whole hours: the "next hour" window covers the hour
already under way plus the next one. A thunderstorm timestamp at or before
the current time means one is already in progress.

Args:
    latitude: Decimal latitude (e.g. 48.2208 for Vienna). Geocode city
        names to coordinates yourself.
    longitude: Decimal longitude (e.g. 16.3738 for Vienna).

ParametersJSON Schema

Name	Required	Description	Default
`latitude`	Yes
`longitude`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains the data source (GeoSphere AROME), the CAPE gating by convective inhibition, the thunderstorm scan horizon and its caveats, the rounding of time windows, and the meaning of timestamps for ongoing thunderstorms.

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 moderately long but every sentence adds unique value. It is structured with a clear opening, a list of returned metrics, data-source context, coverage caveats, and parameter details. No fluff or repetition.

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

Completeness5/5

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

Despite the tool's complexity, the description covers the returned values, edge cases (stale or truncated runs, out-of-coverage notices), and interpretation of results. An output schema is present, but the description goes beyond it to explain behavioral nuances, making it complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides no descriptions for latitude and longitude (0% coverage), but the description fully compensates by giving decimal examples ('48.2208 for Vienna') and instructing the user to geocode city names to coordinates themselves. This adds clear meaning beyond the bare schema.

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 opens with 'Get the severe-weather outlook for a location: gusts and thunderstorms', which names a specific verb (get), a resource (severe-weather outlook), and the content (gusts and thunderstorms). This clearly distinguishes it from sibling tools like get_current_weather and get_hourly_forecast.

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 for when to use the tool, such as the geographic scope (Austria and the Alpine region) and the note that it deliberately reports no severity verdict, leaving judgment to the caller. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a full 5.

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. Dates show when Glama detected each change.

3 tool updatesv0.4.0Aug 12, 2026
- Addedget_air_quality
- Removedget_daily_forecast
- Addedget_storm_outlook
3 tool updatesv0.1.0Jul 31, 2026
- First observedget_current_weather
- First observedget_daily_forecast
- First observedget_hourly_forecast

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a distinct weather aspect: current conditions, hourly forecast, storm outlook, and air quality. Even the current weather and hourly forecast have clear boundaries (present vs. future), and the storm outlook is specialized for severe weather with distinct outputs.

Naming Consistency5/5

All tool names follow the same 'get_' prefix followed by a descriptive noun phrase, using snake_case consistently. There are no mixed conventions or vague verbs, making the naming pattern predictable and easy to infer for new tools.

Tool Count5/5

Four tools is well-scoped for a specialized weather data server covering Austria and the Alpine region. Each tool provides a distinct and necessary data product without redundancy, and the count is within the ideal 3-15 range.

Completeness4/5

The tool surface covers the core needs of a weather data API: current conditions, short-term forecast, severe weather outlook, and air quality. A long-term (beyond 60 hour) forecast or historical data is missing, but such features are not clearly implied by the server's stated purpose of high-resolution data for the Alpine region.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

weather-mcp A
io.github.darshan0548
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
Weather Services Location Services
51
weather-mcp
io.github.kulybaba
An MCP server for weather information by @kulybaba
Weather Services Location Services
2
Weather MCP
io.github.kulybaba
An MCP server for weather information by @kulybaba
Weather Services Location Services
2
Open Meteo A
io.github.pipeworx-io
Open-Meteo MCP — weather forecast + historical reanalysis + sister APIs
Weather Services Open Data
372

Related MCP Servers

MCP Weather Server
Weather Services AI & Machine Learning
dolgova
F
license
Not graded
quality
D
maintenance
MCP server that provides current weather and forecasts via Open-Meteo API, with an optional ML-based next-day max temperature prediction.
Updated 7 months ago (2026-02-10 07:52 UTC)
-
wetter-mcp-server
Weather Services Location Services
Schimmilab
A
license
A
quality
B
maintenance
MCP server for weather forecasts via Open-Meteo (no API key needed), providing current weather, hourly, and daily forecasts with geocoding support.
Updated 22 days ago (2026-08-15 03:55 UTC)
3
MIT
weather-mcp
Weather Services Location Services
idrabenia
A
license
Not graded
quality
C
maintenance
MCP server providing weather data via the Open-Meteo API, including geocoding, current conditions, daily and hourly forecasts, and city lookup. No API key required, with support for multiple units and transport types.
Updated a month ago (2026-08-01 12:59 UTC)
1
MIT
Weather-mcp-server
Weather Services Location Services
SOTA9
F
license
Not graded
quality
C
maintenance
MCP server that provides current weather, multi-day forecasts, umbrella recommendations, severe weather alerts (US), and side-by-side city comparisons using Open-Meteo and NWS APIs, with no API key required.
Updated a month ago (2026-08-09 12:20 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/slettmayer/geosphere-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server