Skip to main content
Glama
Yarflam

Weather MCP Server

by Yarflam
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

🌤️ Weather MCP Server (Free & Sydney Default)

A Model Context Protocol (MCP) server for retrieving weather data via the free Open-Meteo API. No API key required! Sydney is configured as the default city.

✨ Features

  • 🆓 100% free - Uses Open-Meteo API (no key required)

  • 🇦🇺 Sydney by default - Perfect for Australia

  • 🌍 Global support - All cities worldwide

  • 🗓️ 7-day forecasts - Detailed weather data

  • 🔍 City search - Find coordinates easily

  • 🌐 Multi-language - English interface with French support

Related MCP server: Weather MCP

🚀 Quick Installation

  1. Install dependencies:

cd weather-mcp-server
npm install

  1. Test immediately:

npm start

That's it! No additional configuration needed.

🛠️ Configuration with Claude Desktop

Add this configuration to your claude_desktop_config.json:

Windows

File: %APPDATA%\Claude\claude_desktop_config.json

macOS

File: ~/Library/Application Support/Claude/claude_desktop_config.json

JSON Configuration

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": [
        "YOUR_FULL_PATH_HERE\\weather-mcp-server\\src\\index.js"
      ]
    }
  }
}

Note: Adjust the path according to your installation!

🔧 Available Tools

1. get_current_weather

Current weather (Sydney by default)

  • city (optional): City name (default: Sydney)

  • country (optional): Country code (AU, FR, etc.)

2. get_weather_forecast

7-day forecasts (Sydney by default)

  • city (optional): City name (default: Sydney)

  • country (optional): Country code

  • days (optional): Number of days 1-7 (default: 7)

3. get_weather_by_coordinates

Weather by GPS coordinates (Sydney by default)

  • lat (optional): Latitude (default: -33.8688)

  • lon (optional): Longitude (default: 151.2093)

  • days (optional): Number of days 1-7 (default: 1)

4. search_cities

Search cities worldwide

  • query (required): City name to search

📝 Usage Examples with Claude

Once configured, you can ask Claude:

Default weather (Sydney):

  • "What's the weather?"

  • "Current weather"

  • "Week forecast"

Other cities:

  • "Weather in Paris"

  • "5-day forecast for London"

  • "Temperature in Tokyo"

City search:

  • "Find cities named Melbourne"

  • "Search for Springfield"

By coordinates:

  • "Weather at coordinates 48.8566, 2.3522"

🌟 Open-Meteo Benefits

  • ✅ Completely free - No reasonable usage limits

  • ✅ No registration - Works immediately

  • ✅ Accurate data - Professional weather models

  • ✅ Modern API - Simple and fast JSON

  • ✅ Reliable - Stable European service

🗺️ Why Sydney as Default?

Sydney is configured as the default city because:

  • 🏙️ Major metropolis - Representative of Australia

  • 🌤️ Varied climate - Good weather example

  • 🇦🇺 Unique timezone - GMT+10/+11 depending on season

  • 📍 Exact coordinates - -33.8688°, 151.2093°

🐛 Troubleshooting

"City not found"

  • Check spelling

  • Try with country code: "Paris, FR"

  • Use search_cities to find the correct name

Network error

  • Check your internet connection

  • Open-Meteo is sometimes temporarily unavailable

Server won't start

  • Check Node.js: node --version (≥16 required)

  • Install dependencies: npm install

🔄 Comparison with OpenWeatherMap

Criteria

Open-Meteo

OpenWeatherMap

Price

🆓 Free

🆓 Free (limited)

API Key

❌ None

✅ Required

Registration

❌ None

✅ Mandatory

Forecasts

7 days

5 days (free)

Accuracy

⭐⭐⭐⭐⭐

⭐⭐⭐⭐⭐

Reliability

⭐⭐⭐⭐⭐

⭐⭐⭐⭐

📦 Dependencies

  • @modelcontextprotocol/sdk: Official MCP SDK

  • node-fetch: HTTP client for API requests

No heavy external dependencies!

📄 License

MIT - Use freely in your projects!

🇦🇺 Made with ❤️ for Sydney and the world

🇫🇷 Version Française / French Version

🌤️ Serveur MCP Météo (Gratuit & Sydney par défaut)

Un serveur MCP (Model Context Protocol) pour récupérer des données météorologiques via l'API gratuite Open-Meteo. Aucune clé API requise ! Sydney est configuré comme ville par défaut.

✨ Caractéristiques

  • 🆓 100% gratuit - Utilise l'API Open-Meteo (pas de clé requise)

  • 🇦🇺 Sydney par défaut - Parfait pour l'Australie

  • 🌍 Support mondial - Toutes les villes du monde

  • 🗓️ Prévisions 7 jours - Météo détaillée

  • 🔍 Recherche de villes - Trouve les coordonnées facilement

  • 🌐 Interface française - Descriptions en français

🚀 Installation rapide

  1. Installer les dépendances :

cd weather-mcp-server
npm install

  1. Tester immédiatement :

npm start

C'est tout ! Aucune configuration supplémentaire nécessaire.

🛠️ Configuration avec Claude Desktop

Ajoutez cette configuration dans votre claude_desktop_config.json :

Windows

Fichier : %APPDATA%\Claude\claude_desktop_config.json

macOS

Fichier : ~/Library/Application Support/Claude/claude_desktop_config.json

Configuration JSON

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": [
        "REMPLACEZ_PAR_VOTRE_CHEMIN\\weather-mcp-server\\src\\index.js"
      ]
    }
  }
}

Note : Adaptez le chemin selon votre installation !

🔧 Outils disponibles

1. get_current_weather

Météo actuelle (Sydney par défaut)

  • city (optionnel) : Nom de la ville (défaut: Sydney)

  • country (optionnel) : Code pays (AU, FR, etc.)

2. get_weather_forecast

Prévisions sur 7 jours (Sydney par défaut)

  • city (optionnel) : Nom de la ville (défaut: Sydney)

  • country (optionnel) : Code pays

  • days (optionnel) : Nombre de jours 1-7 (défaut: 7)

3. get_weather_by_coordinates

Météo par coordonnées GPS (Sydney par défaut)

  • lat (optionnel) : Latitude (défaut: -33.8688)

  • lon (optionnel) : Longitude (défaut: 151.2093)

  • days (optionnel) : Nombre de jours 1-7 (défaut: 1)

4. search_cities

Recherche de villes dans le monde

  • query (requis) : Nom de la ville à rechercher

📝 Exemples d'utilisation avec Claude

Une fois configuré, vous pouvez demander à Claude :

Météo par défaut (Sydney) :

  • "Quelle est la météo ?"

  • "Météo actuelle"

  • "Prévisions de la semaine"

Autres villes :

  • "Météo à Paris"

  • "Prévisions pour Londres sur 5 jours"

  • "Température à Tokyo"

Recherche de villes :

  • "Trouve les villes appelées Melbourne"

  • "Cherche Springfield"

Par coordonnées :

  • "Météo aux coordonnées 48.8566, 2.3522"

🌟 Avantages d'Open-Meteo

  • ✅ Totalement gratuit - Pas de limite d'usage raisonnable

  • ✅ Pas d'inscription - Fonctionne immédiatement

  • ✅ Données précises - Modèles météo professionnels

  • ✅ API moderne - JSON simple et rapide

  • ✅ Fiable - Service européen stable

🗺️ Pourquoi Sydney par défaut ?

Sydney est configuré comme ville par défaut car :

  • 🏙️ Grande métropole - Représentative de l'Australie

  • 🌤️ Climat varié - Bon exemple météorologique

  • 🇦🇺 Fuseau unique - GMT+10/+11 selon saison

  • 📍 Coordonnées exactes - -33.8688°, 151.2093°

🐛 Dépannage

"Ville non trouvée"

  • Vérifiez l'orthographe

  • Essayez avec le code pays : "Paris, FR"

  • Utilisez search_cities pour trouver le bon nom

Erreur de réseau

  • Vérifiez votre connexion internet

  • Open-Meteo est parfois temporairement indisponible

Le serveur ne démarre pas

  • Vérifiez Node.js : node --version (≥16 requis)

  • Installez les dépendances : npm install

🔄 Comparaison avec OpenWeatherMap

Critère

Open-Meteo

OpenWeatherMap

Prix

🆓 Gratuit

🆓 Gratuit (limité)

Clé API

❌ Aucune

✅ Requise

Inscription

❌ Aucune

✅ Obligatoire

Prévisions

7 jours

5 jours (gratuit)

Précision

⭐⭐⭐⭐⭐

⭐⭐⭐⭐⭐

Fiabilité

⭐⭐⭐⭐⭐

⭐⭐⭐⭐

📦 Dépendances

  • @modelcontextprotocol/sdk : SDK officiel MCP

  • node-fetch : Client HTTP pour les requêtes API

Pas de dépendance externe lourde !

📄 Licence

MIT - Utilisez librement dans vos projets !

🇦🇺 Fait avec ❤️ pour Sydney et le monde entier

Available Tools

4 tools
get_current_weatherC

Récupère la météo actuelle pour une ville (Sydney par défaut)

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNoNom de la ville (optionnel, Sydney par défaut)Sydney
countryNoCode pays optionnel (ex: AU, FR, US)

TDQS

C2.9/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 of behavioral disclosure. It states the tool retrieves current weather, implying a read-only operation, but doesn't cover important aspects like rate limits, error handling, data freshness, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence in French that conveys the core purpose and default behavior without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., temperature, conditions), potential errors, or how it differs from sibling tools. For a tool with no structured output and zero annotation coverage, more contextual information is needed to guide effective use.

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 documentation for both parameters (city and country). The description adds minimal value beyond the schema: it mentions the default city (Sydney) and that the city parameter is optional, but this is already covered in the schema. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Récupère la météo actuelle pour une ville' (Retrieves current weather for a city). It specifies the verb ('récupère') and resource ('météo actuelle'), and mentions the default city (Sydney). However, it doesn't explicitly differentiate from sibling tools like get_weather_by_coordinates or get_weather_forecast, which prevents a score of 5.

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 minimal usage guidance: it mentions the default city (Sydney) but offers no explicit advice on when to use this tool versus alternatives like get_weather_by_coordinates or get_weather_forecast. There's no context on prerequisites, limitations, or comparisons to siblings, leaving the agent with little direction.

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

get_weather_by_coordinatesC

Récupère la météo selon les coordonnées géographiques

ParametersJSON Schema
NameRequiredDescriptionDefault
latNoLatitude (-33.8688 pour Sydney par défaut)
lonNoLongitude (151.2093 pour Sydney par défaut)
daysNoNombre de jours de prévision (1-7)

TDQS

C2.9/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 of behavioral disclosure. It states the tool retrieves weather but doesn't disclose any behavioral traits such as rate limits, authentication needs, error handling, or what the output looks like (e.g., current conditions, forecast details). For a tool with no annotations, this is a significant gap in transparency.

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, efficient sentence in French that directly states the tool's function. It's front-loaded with the core purpose and has no wasted words. This is appropriately concise for a simple retrieval tool.

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?

Given the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on output format (e.g., what weather data is returned), behavioral aspects like error cases, and differentiation from siblings. Without annotations or output schema, the description should provide more context to be fully helpful.

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?

The input schema has 100% description coverage, with clear documentation for 'lat', 'lon', and 'days' including defaults and constraints. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain coordinate formats, units, or how 'days' affects the output. Given high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Récupère la météo selon les coordonnées géographiques' (Retrieves weather based on geographic coordinates). It specifies the verb ('récupère') and resource ('météo'), and while it doesn't explicitly distinguish from siblings like 'get_current_weather' or 'get_weather_forecast', the mention of coordinates provides some differentiation. However, it's not fully specific about scope (e.g., current vs. forecast) compared to siblings.

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 like 'get_current_weather' or 'get_weather_forecast'. It doesn't mention any prerequisites, exclusions, or contextual factors (e.g., use this for coordinates-based queries, use others for city names). The lack of usage context leaves the agent to infer based on tool names alone.

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

get_weather_forecastC

Récupère les prévisions météo sur 7 jours (Sydney par défaut)

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNoNom de la ville (optionnel, Sydney par défaut)Sydney
countryNoCode pays optionnel
daysNoNombre de jours de prévision (1-7)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves forecasts but lacks critical details: whether it's a read-only operation, any rate limits, authentication requirements, error handling, or response format. For a tool with no annotation coverage, this leaves significant behavioral gaps unaddressed.

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 extremely concise—a single sentence in French that efficiently conveys the core functionality. It's front-loaded with the main purpose and includes key details (7-day forecast, Sydney default) without any fluff or redundant information. Every word earns its place.

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?

Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the forecast data includes (e.g., temperature, precipitation), how results are structured, or any limitations beyond the 7-day range. Without annotations or output schema, the description should provide more context about behavior and returns.

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%, so the schema fully documents all three parameters (city, country, days) with descriptions, defaults, and constraints. The description adds marginal value by mentioning the 7-day forecast scope and Sydney default, but doesn't provide additional semantic context beyond what's already in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Récupère les prévisions météo sur 7 jours' (Retrieves 7-day weather forecasts). It specifies the verb ('récupère'), resource ('prévisions météo'), and scope ('sur 7 jours'). However, it doesn't explicitly differentiate from sibling tools like 'get_current_weather' or 'get_weather_by_coordinates' beyond implying a forecast vs. current weather distinction.

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 minimal usage guidance. It mentions 'Sydney par défaut' (Sydney by default), which hints at optional city parameter usage, but offers no explicit when-to-use rules, no comparison to alternatives like 'get_current_weather' for current vs. forecast data, and no prerequisites or exclusions. The agent must infer usage from context alone.

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

search_citiesC

Recherche des villes par nom pour obtenir leurs coordonnées

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNom de la ville à rechercher

TDQS

C2.9/5.0
Behavior2/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. While it indicates this is a search operation that returns coordinates, it doesn't describe important behavioral aspects like whether this is a read-only operation, what format the coordinates are returned in, whether there are rate limits, how partial matches are handled, or what happens when no cities are found. The description provides basic functionality but lacks operational context.

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

Conciseness4/5

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

The description is a single, efficient sentence in French that clearly states the tool's purpose. It's appropriately concise without being overly brief, though it could potentially be more front-loaded with additional context about when to use the tool. There's no wasted language or redundancy.

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?

For a search tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the coordinates are returned in (latitude/longitude pairs, geojson, etc.), whether results are paginated, how many results are returned, or what happens with ambiguous queries. The description provides basic functionality but leaves too many operational questions unanswered for effective agent use.

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?

The description mentions searching by city name, which aligns with the single 'query' parameter in the schema. Since schema description coverage is 100% and the schema already documents the parameter as 'Nom de la ville à rechercher' (Name of the city to search for), the description adds minimal value beyond what's already in the structured data. The baseline score of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: searching for cities by name to obtain their coordinates. It specifies both the verb ('search') and resource ('cities'), and indicates the outcome ('obtain coordinates'). However, it doesn't explicitly differentiate from sibling tools like get_current_weather, which are weather-related rather than city search tools.

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 doesn't mention sibling tools like get_current_weather or explain that this tool is for finding city coordinates rather than weather data. There's no information about prerequisites, limitations, or appropriate contexts for use.

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

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

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: get_current_weather for current conditions by city, get_weather_by_coordinates for current conditions by coordinates, get_weather_forecast for multi-day forecasts, and search_cities for city lookup. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: get_current_weather, get_weather_by_coordinates, get_weather_forecast, and search_cities. The naming is predictable and readable throughout.

Tool Count5/5

With 4 tools, this is well-scoped for a weather server. Each tool serves a distinct and necessary function (current weather by location, current weather by coordinates, forecasts, and city search), making the count appropriate without being too sparse or bloated.

Completeness4/5

The tool set covers core weather operations well: retrieving current weather (by city and coordinates), forecasts, and city search for location resolution. A minor gap is the lack of historical weather data or more granular forecast options, but agents can work effectively with the provided tools for most use cases.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Weather MCP Server

    isdaniel
    A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol server that retrieves current weather information for specified cities using the Open-Meteo API, requiring no API key.
    8
    59
    Apache 2.0

  • Weather MCP

    kaisumi
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides current weather information and 3-day forecasts for specified cities using the Open-Meteo API.
    1

  • Weather MCP

    LiuKeTong713
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables natural language weather queries for global cities, integrating with OpenWeather API to provide real-time weather information in an easy-to-read format.
    1

Appeared in Searches

Latest Blog Posts

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/Yarflam/weather-mcp-server'

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