Provides environment variable management for storing the OpenWeatherMap API key securely in a .env file
Runtime environment required to execute the MCP server (v14 or higher)
Package manager used for installing dependencies and running the test suite
Click on "Deploy 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., "@Weather MCP Server what's the weather like in Tokyo right now?"
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.
A Model Context Protocol (MCP) server that provides weather information using the OpenWeatherMap API.
Node.js (v14 or higher)
npm
OpenWeatherMap API key
Related MCP server: mcp-weather
Clone or download this repository
Install dependencies:
npm installCreate a .env file in the root directory:
touch .envAdd your OpenWeatherMap API key to the .env file:
OPENWEATHER_API_KEY=your_openweathermap_api_key_hereYou can get a free API key from OpenWeatherMap.
Add this server to your MCP configuration file:
{
"weather": {
"command": "node",
"args": ["index.js"],
"cwd": "/path/to/weather-mcp-server"
}
}getWeather: Get current weather information for any city
Run the test suite:
npm testVariable | Description | Required |
| Your OpenWeatherMap API key | Yes |
Once configured with Claude Code, you can ask for weather information:
"What's the weather in London?"
"Get me the current weather in Tokyo"
"How's the weather in New York?"
Get current weather for a city
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Name of the city |
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. It states the tool gets current weather but doesn't mention any behavioral traits like rate limits, authentication requirements, data freshness, error conditions, or response format. This leaves significant gaps for an agent to understand how to use it effectively.
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 extremely concise (5 words) and front-loaded with the essential information. Every word earns its place, and there's no wasted verbiage or unnecessary complexity.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what weather data is returned, how current 'current' is, or any operational constraints. For a tool that presumably returns structured data, more context about the response would be helpful for an agent.
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?
The input schema has 100% description coverage, with the 'city' parameter clearly documented. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current weather for a city'), making the purpose immediately understandable. It doesn't need to distinguish from siblings since there are none, but it could be more specific about what weather data is returned (e.g., temperature, conditions).
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 provides no guidance on when to use this tool versus alternatives, prerequisites, or limitations. It simply states what the tool does without any context about appropriate usage scenarios or constraints.
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.
getWeatherScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'getWeather' has a clear and distinct purpose that cannot be confused with any other tool in this set.
The naming follows a consistent verb_noun pattern with 'getWeather', and since there is only one tool, there are no deviations or mixed conventions to evaluate. The naming is straightforward and predictable.
A single tool for a weather server is too few for the apparent scope, as it only provides current weather retrieval. This lacks essential operations like forecasts, historical data, or location-based queries, making it feel thin and incomplete for typical weather-related tasks.
The tool surface is severely incomplete for a weather domain. It only covers current weather retrieval, with significant gaps such as missing forecast data, historical weather information, or multi-location queries. This will likely cause agent failures when broader weather-related needs arise.
The official Model Context Protocol server for Ambee. It gives any MCP-compatible AI assistant — Claude, ChatGPT, Cursor, VS Code, Ollama, and more direct access to live air quality, pollen, and weather data. To get started, including information on signing up and obtaining your Ambee key, check out the Ambee documentation on https://docs.ambeedata.com
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
OpenWeather MCP — wraps the OpenWeatherMap API (openweathermap.org)
