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 Tool what's the weather in London?"
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.
Weather MCP Tool là một ứng dụng NestJS cung cấp thông tin thời tiết thông qua Model Context Protocol (MCP). Ứng dụng sử dụng OpenWeatherMap API để lấy dữ liệu thời tiết thực tế cho các thành phố trên toàn thế giới.
Related MCP server: MCP Weather Data Fetcher
🌤️ Thông tin thời tiết thực tế: Lấy dữ liệu từ OpenWeatherMap API
🌍 Hỗ trợ đa ngôn ngữ: Mô tả thời tiết bằng tiếng Việt
📊 Thông tin chi tiết: Nhiệt độ, độ ẩm, tốc độ gió, nhiệt độ cảm giác
🔧 MCP Tool Integration: Tích hợp với Model Context Protocol
🚀 NestJS Framework: Xây dựng trên NestJS với TypeScript
🐳 Docker Support: Hỗ trợ chạy trong Docker container
# Clone repository
git clone <repository-url>
cd weather-mcp-nest
# Cài đặt dependencies
npm install# Clone repository
git clone <repository-url>
cd weather-mcp-nest
# Build và chạy với Docker Compose
docker-compose up --buildĐăng ký OpenWeatherMap API:
Truy cập: https://openweathermap.org/api
Đăng ký tài khoản miễn phí
Lấy API key
Tạo file .env:
OPENWEATHER_API_KEY=your_api_key_here# Development mode
npm run start:dev
# Production mode
npm run start:prod# Build Docker image
docker build -t weather-mcp .
# Chạy container
docker run -p 3000:3000 --env-file .env weather-mcp
# Hoặc sử dụng Docker Compose
docker-compose upSau khi khởi động server, tool sẽ có sẵn thông qua MCP protocol:
getWeatherMô tả: Lấy thông tin thời tiết cho một thành phố
Tham số:
city (string): Tên thành phố (VD: "Da Nang", "London", "New York")
Ví dụ sử dụng:
{
"name": "getWeather",
"arguments": {
"city": "Da Nang"
}
}Kết quả:
Thời tiết ở Da Nang: mây cụm, nhiệt độ 28°C (cảm giác như 33°C), độ ẩm 82%, gió 3.49 m/s.src/
├── weather/
│ ├── weather.controller.ts # REST API controller
│ ├── weather.service.ts # Weather service logic
│ ├── weather.tool.ts # MCP tool implementation
│ └── weather.module.ts # Weather module
├── app.module.ts # Main application module
└── main.ts # Application entry pointLấy thông tin thời tiết qua REST API
Request Body:
{
"city": "Da Nang"
}Response:
{
"content": {
"type": "text",
"text": "Thời tiết ở Da Nang: mây cụm, nhiệt độ 28°C (cảm giác như 33°C), độ ẩm 82%, gió 3.49 m/s."
}
}Cấu hình MCP trong .cursor/mcp.json:
{
"mcpServers": {
"weather": {
"url": "http://localhost:3000/mcp",
"type": "http"
}
}
}@nestjs/common: NestJS core framework
@rekog/mcp-nest: MCP integration for NestJS
axios: HTTP client for API calls
dotenv: Environment variables management
zod: Schema validation
# Unit tests
npm run test
# E2E tests
npm run test:e2e
# Test coverage
npm run test:covnpm run lint# Build image
docker build -t weather-mcp .
# Chạy container
docker run -p 3000:3000 --env-file .env weather-mcp
# Chạy với Docker Compose
docker-compose up --build# Xem logs
docker-compose logs -f
# Dừng container
docker-compose down
# Restart container
docker-compose restart# Chạy trong development mode
docker-compose -f docker-compose.dev.yml upMIT License - xem file LICENSE để biết thêm chi tiết.
Get the weather for a city
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. It only states 'Get the weather' and does not mention return format, units, timezone, rate limits, or any side effects. This is minimal and lacks essential behavioral context.
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, clear sentence with no redundant words or unnecessary details. It is appropriately sized for a simple tool and front-loads the core intent effectively.
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 simple nature of the tool (one parameter, no output schema), the description is fairly adequate, but it leaves out important context such as what the returned weather data includes (e.g., temperature, conditions). The lack of annotations and output schema means the description should provide more detail to be fully 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?
The schema has one string parameter 'city' with 0% description coverage. The description mentions 'for a city', which aligns with the parameter name but adds no extra detail about expected format (e.g., 'London' vs 'London, UK') or examples. It provides only marginal value beyond the schema itself.
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 uses a specific verb 'Get' and clearly identifies the resource as 'weather for a city'. It is unambiguous and completely conveys the tool's function, even without sibling tools to differentiate from.
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 information on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. There is no guidance on when not to use it, leaving the agent to infer usage solely from the name and schema.
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.
v0.0.1getWeatherScored across 1 tool
With only a single tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined by its name and description.
The single tool uses a consistent verb_noun pattern (get_weather). There are no other tools to introduce inconsistency.
One tool is on the low end but can be acceptable for a very narrow scope. However, a weather server typically warrants more than a single tool, so the count feels thin.
The tool only supports current weather for a city, but a complete weather domain would also include forecasts, historical data, or alerts. These missing operations represent significant gaps that would force agents to rely on external workarounds.
OpenWeather MCP — wraps the OpenWeatherMap API (openweathermap.org)
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
WeatherAPI.com MCP — wraps WeatherAPI.com (api.weatherapi.com)