The LandiWetter MCP Server provides Swiss weather forecast data with these capabilities:
Search for Swiss locations by name using the searchLocation tool
Get detailed weather forecasts for specific locations and dates using the getWeatherForecast tool
Access hourly and daily forecasts with both granular and aggregated weather data
Retrieve weather using URI format weather://{location}/{date} (defaults to today if date not specified)
Integrate with MCP-compatible clients like Claude Desktop for seamless access
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., "@LandiWetter MCP Server What's the weather forecast for Zürich tomorrow?"
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.
This is a Model Context Protocol (MCP) server that provides Swiss weather forecast data from LandiWetter. The server allows you to search for Swiss locations and get detailed weather forecasts.
Search for Swiss locations by name
Get detailed weather forecasts for a specific location and date
Access both hourly and daily forecast data
Use as a tool or resource in MCP-compatible clients
Related MCP server: meteo-swiss-mcp
Clone the repository
Install dependencies:
npm installRun the server with:
npm startThis starts the MCP server using the stdio transport, making it compatible with MCP clients like Claude Desktop.
Open Claude Desktop
Go to Settings > MCP > Add custom server
Configure with the following details:
Name: LandiWetter
Command: node /path/to/landiwetter-mcp/src/index.js
Save and enable the server
Once the server is integrated with Claude Desktop, you can use natural language prompts to access weather forecasts:
To get a weather forecast:
What's the weather forecast for Bern, Switzerland?To get a weather forecast for a specific date:
What's the weather forecast for Zürich on 2025-05-10?Search for Swiss locations by name.
Parameters:
locationName: The name of the location to search for
Example:
Please search for locations named "Zürich"Get a detailed weather forecast for a specific location.
Parameters:
locationId: The location ID (e.g., G2661552)
date (optional): The date for the forecast (yyyy-MM-dd). Defaults to today
Example:
Please get the weather forecast for location ID G2661552Access weather forecasts through a resource URI.
URI Template: weather://{location}/{date}
Where:
location: The name of the location (e.g., "Zürich")
date (optional): The date for the forecast (yyyy-MM-dd). Defaults to today
Example:
Please check the resource at weather://Zürich/2025-05-03| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional: The date for the forecast (yyyy-MM-dd). Defaults to today | |
| locationId | Yes | The location ID (e.g., G2661552) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| locationName | Yes | The name of the location to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0getWeatherForecastsearchLocationScored across 2 tools
The two tools have clearly distinct purposes: getWeatherForecast retrieves weather data, while searchLocation finds geographic locations. There is no overlap or ambiguity between these functions, making it easy for an agent to select the correct tool based on the task.
Both tools use a verb_noun pattern (getWeatherForecast and searchLocation), which is consistent and predictable. The minor deviation is the use of camelCase instead of snake_case, but this does not hinder readability or coherence within the set.
With only 2 tools, the server feels thin for a weather and location domain. While it covers basic retrieval and search, it lacks essential operations like updating preferences, handling alerts, or managing saved locations, making the scope appear incomplete and underdeveloped.
Inferring the domain as weather and location services, the tool set is severely incomplete. It only provides forecast retrieval and location search, missing critical operations such as current weather data, historical forecasts, location management, or user-specific configurations, which are typical for such services.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Swiss weather data for AI assistants — forecasts, measurements, stations, pollen.
Weather forecasts from MET Norway (Yr): geocoding plus hourly forecasts worldwide.
Weather data, forecast API, climate data, historical weather, alerts, agricultural & travel weather.
Free, keyless real-time weather and 7-day forecasts for any city worldwide.