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., "@Weather MCP Server what's the 5-day forecast for Tokyo in imperial units?"
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.
Reference implementation for ASUS and OEM partners
A simple, production-ready MCP server demonstrating how to integrate external services with AI PCs using the Model Context Protocol.
This sample MCP server demonstrates:
โ How to create an MCP server from scratch
โ How to expose tools (functions) to AI clients
โ How to integrate external APIs (OpenWeather API)
โ Production-ready error handling
โ Clean, well-documented code
Perfect for: OEM partners building AI PC features, developers learning MCP, proof-of-concept projects
Related MCP server: Weather MCP Server
get_current_weather - Get real-time weather for any city
Temperature, conditions, humidity, wind speed
Supports both Celsius and Fahrenheit
get_weather_forecast - Get 5-day forecast
Daily high/low temperatures
Weather conditions per day
Node.js >= 18.0.0
OpenWeather API key (free tier available)
# Clone or download this repository
cd weather-mcp-server
# Install dependencies
npm install
# Configure API key
cp .env.example .env
# Edit .env and add your OpenWeather API keyVisit OpenWeather API
Sign up for free account
Generate API key
Add to .env file
# Start the server
npm start
# Or with auto-reload during development
npm run devAdd to your claude_desktop_config.json:
{
"mcpServers": {
"weather": {
"command": "node",
"args": ["/absolute/path/to/weather-mcp-server/index.js"],
"env": {
"OPENWEATHER_API_KEY": "your_api_key_here"
}
}
}
}Once configured, you can ask your AI assistant:
"What's the weather like in Taipei?"
"Give me a 5-day forecast for Tokyo"
"What's the temperature in New York in Fahrenheit?"The AI will automatically call the appropriate MCP tools!
โโโโโโโโโโโโโโโโโโโ
โ AI Client โ (Claude, ChatGPT, etc.)
โ (Claude Desktop)โ
โโโโโโโโโโฌโโโโโโโโโ
โ MCP Protocol (stdio)
โ
โโโโโโโโโโโโโโโโโโโ
โ Weather MCP โ โ This server
โ Server โ
โโโโโโโโโโฌโโโโโโโโโ
โ HTTPS
โ
โโโโโโโโโโโโโโโโโโโ
โ OpenWeather API โ
โโโโโโโโโโโโโโโโโโโindex.js - Main server implementation
@modelcontextprotocol/sdk - Official MCP SDK
StdioServerTransport - Communicates via stdin/stdout
OpenWeather API - External weather data source
weather-mcp-server/
โโโ package.json # Dependencies and scripts
โโโ index.js # Main MCP server code
โโโ .env.example # Environment variables template
โโโ .env # Your API keys (git-ignored)
โโโ README.md # This file
โโโ README.zh-TW.md # ็น้ซไธญๆ็
โโโ PARTNER-GUIDE.md # Detailed guide for OEM partners
โโโ examples/
โโโ client-example.js # Example client codeThe server is organized into clear sections:
Configuration - API keys, URLs
WeatherServer Class - Main server logic
Tool Registration - Define available tools
Tool Handlers - Implement tool functionality
Error Handling - Robust error management
// 1. Add tool definition in setupToolHandlers()
{
name: 'your_new_tool',
description: 'What this tool does',
inputSchema: {
type: 'object',
properties: {
param1: { type: 'string', description: 'Parameter description' }
},
required: ['param1']
}
}
// 2. Add handler in CallToolRequestSchema
case 'your_new_tool':
return await this.yourNewTool(args.param1);
// 3. Implement the method
async yourNewTool(param1) {
// Your logic here
return {
content: [{
type: 'text',
text: 'Result'
}]
};
}# Test the MCP server directly
npm testUse the included examples/client-example.js to test tool calls programmatically.
get_current_weatherParameters:
city (string, required) - City name (e.g., "Taipei", "Tokyo")
units (string, optional) - "metric" (default) or "imperial"
Returns:
๐ค๏ธ Current Weather in Taipei, TW
Temperature: 25.3ยฐC (feels like 26.1ยฐC)
Condition: Clear - clear sky
Humidity: 65%
Wind Speed: 3.2 m/s
Pressure: 1013 hPa
Visibility: 10.0 km
Last updated: 11/14/2025, 10:30:00 AMget_weather_forecastParameters:
city (string, required) - City name
units (string, optional) - "metric" (default) or "imperial"
Returns:
๐
5-Day Weather Forecast for Taipei, TW
11/14/2025:
High: 26.5ยฐC | Low: 22.1ยฐC
Condition: Clear
11/15/2025:
High: 27.2ยฐC | Low: 23.4ยฐC
Condition: Clouds
...โ API keys stored in environment variables (not in code)
โ Input validation for all parameters
โ Proper error handling (no sensitive data leakage)
โ HTTPS for external API calls
โ Minimal dependencies (reduces attack surface)
๐ Use secrets management system (AWS Secrets Manager, Azure Key Vault)
๐ Implement rate limiting
๐ Add request logging/monitoring
๐ Use TLS for MCP communication if deployed remotely
This server supports multiple languages through the OpenWeather API:
// Add language parameter to API call
const url = `${API_BASE_URL}/weather?q=${city}&units=${units}&lang=zh_tw&appid=${API_KEY}`;Supported languages: en, zh_tw, zh_cn, ja, ko, and 50+ more
"City not found"
Check spelling of city name
Try including country code: "Taipei,TW"
"Weather API error: Unauthorized"
Verify your API key in .env
Check API key is active at openweathermap.org
"Module not found"
Run npm install
Check Node.js version >= 18.0.0
MCP server not detected in Claude
Verify claude_desktop_config.json path
Restart Claude Desktop
Check server logs for errors
See PARTNER-GUIDE.md for:
Detailed integration guide
Deployment options
Customization examples
Production checklist
Support information
Contact: partners@irisgo.ai
MIT License - see LICENSE file
Created by: IrisGo.AI Team
MCP Protocol: Anthropic
Weather Data: OpenWeather
For: ASUS and AI PC OEM partners
Issues: GitHub Issues
Email: support@irisgo.ai
Documentation: docs.irisgo.ai
Last Updated: 2025-11-14 Version: 1.0.0
Get current weather information for a specific city
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., "Taipei", "Tokyo", "New York") | |
| units | No | Temperature units: "metric" (Celsius) or "imperial" (Fahrenheit) | metric |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only indicates a read operation ('Get') but lacks details on data freshness, rate limits, or other behavioral traits.
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?
Single sentence, front-loaded with purpose, no extraneous words. Every part is essential.
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 2 parameters and no output schema, the description covers the purpose and required parameter. However, it lacks usage guidelines and behavioral context, making it barely 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 description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already states (city and units).
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 retrieves current weather for a specific city, with verb 'Get' and resource 'current weather information', and the term 'current' distinguishes it from the sibling tool 'get_weather_forecast'.
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?
No explicit guidance on when to use this tool vs the sibling 'get_weather_forecast'. The usage is implied by the name and description, but no when-not-to or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 5-day weather forecast for a specific city
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., "Taipei", "Tokyo", "New York") | |
| units | No | Temperature units: "metric" (Celsius) or "imperial" (Fahrenheit) | metric |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the 5-day forecast aspect but does not mention any other behaviors (e.g., data source, update frequency, or limitations). There is no contradiction.
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 sentence of 9 words, perfectly concise. It front-loads the verb 'Get' and the key noun 'forecast', making it immediately scannable.
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 2-parameter read tool with no output schema, the description covers the essential purpose and parameter. It could mention that the forecast includes temperature and conditions, but overall it is mostly complete.
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?
Input schema coverage is 100%; both parameters ('city' and 'units') are well described in the schema. The description adds no extra detail beyond what the schema provides, meeting the baseline.
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 action ('Get'), the resource ('5-day weather forecast'), and the target ('specific city'). It effectively distinguishes from the sibling tool 'get_current_weather' by specifying the forecast duration.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The contrast with the sibling tool 'get_current_weather' is implied by the description, but direct advice on selecting between them is absent.
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.
get_current_weatherget_weather_forecastScored across 2 tools
Tools have clearly distinct purposes: one retrieves current weather, the other provides a forecast. No overlap in functionality.
Both tools follow a consistent verb_noun pattern using snake_case: get_current_weather and get_weather_forecast. The pattern is predictable.
With only 2 tools, the set is minimal but borderline for a weather server. A few more (e.g., hourly forecast, alerts) would be more appropriate.
The tool surface covers current weather and a 5-day forecast, but misses common weather operations like hourly forecasts, weather alerts, or location-based queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Get current weather for any city and create images from your prompts. Streamline planning, reportsโฆ
OpenWeather data for AI agents: list feeds, sign up, check balance, get a top-up link, fetch data.
Free, keyless real-time weather and 7-day forecasts for any city worldwide.
Provide real-time and forecast weather information for locations in the United States using naturaโฆ
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lmanchu/weather-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server