Skip to main content
Glama
Domt301

Weather MCP Server

by Domt301
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Weather MCP Server

A Model Context Protocol (MCP) server that provides weather information and time utilities for AI assistants and applications.

Overview

This MCP server implements a simple weather service with two main tools:

  • Weather Information: Get current weather data for any city

  • Time Service: Retrieve the current timestamp

Built with TypeScript and the official MCP SDK, this server demonstrates how to create custom tools that can be used by Claude Desktop and other MCP-compatible clients.

Related MCP server: Weather MCP Server

Features

  • 🌤️ Weather Data: Fetch weather information for any city worldwide

  • ⏰ Time Service: Get current timestamp in ISO format

  • 🔒 Input Validation: Robust parameter validation using Zod schemas

  • 🚀 TypeScript: Full type safety and modern JavaScript features

  • 📡 stdio Transport: Communicates via standard input/output for seamless integration

Installation

Prerequisites

  • Node.js 18+

  • npm or yarn package manager

Setup

  1. Clone the repository

    git clone <repository-url>
cd my-mcp-server

  2. Install dependencies

    npm install

  3. Build the project

    npm run build

Usage

Development

Run the server in development mode:

npm run dev

Production

Start the built server:

npm start

Integration with Claude Desktop

Add this server to your Claude Desktop configuration:

{
  "mcpServers": {
    "weather-server": {
      "command": "node",
      "args": ["/path/to/my-mcp-server/build/index.js"]
    }
  }
}

Available Tools

get_weather

Retrieves weather information for a specified city.

Parameters:

  • city (string, required): The city to get weather for

  • units (string, optional): Temperature units - "metric" or "imperial" (defaults to "metric")

Example Response:

Weather in London:
Temperature: 18°C
Conditions: Partly cloudy
Humidity: 65%

get_time

Returns the current timestamp in ISO 8601 format.

Parameters: None

Example Response:

Current time: 2025-01-08T14:30:25.123Z

Project Structure

my-mcp-server/
├── index.ts          # Main server implementation
├── package.json      # Project dependencies and scripts
├── tsconfig.json     # TypeScript configuration
├── build/           # Compiled JavaScript output
└── README.md        # This file

Technical Details

Dependencies

  • @modelcontextprotocol/sdk: Official MCP SDK for server implementation

  • axios: HTTP client for external API calls

  • zod: Runtime type validation and parsing

Architecture

The server follows the MCP specification:

  1. Tool Registration: Tools are registered via ListToolsRequestSchema handler

  2. Tool Execution: Tool calls are handled via CallToolRequestSchema handler

  3. Error Handling: Proper MCP error codes and validation

  4. Transport: Uses stdio transport for communication

Weather Data

Currently returns mock weather data for demonstration purposes. To integrate with a real weather API:

  1. Sign up for a weather service (e.g., OpenWeatherMap)

  2. Replace the mock data generation in the get_weather case

  3. Add proper API key handling and HTTP requests

Scripts

  • npm run build - Compile TypeScript to JavaScript

  • npm run dev - Build and run in development mode

  • npm start - Run the compiled server

Contributing

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Make your changes

  4. Build and test (npm run build)

  5. Commit your changes (git commit -m 'Add amazing feature')

  6. Push to the branch (git push origin feature/amazing-feature)

  7. Open a Pull Request

License

This project is open source and available under the MIT License.

Learn More

Built with ❤️ using TypeScript and the Model Context Protocol

Available Tools

2 tools
get_timeA

Get the current time

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get the current time' implies a read-only, non-destructive operation, but it does not specify timezone, return format, or other behavioral details. The description is sufficient for a zero-parameter tool but lacks depth.

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 sentence with no unnecessary words. It is front-loaded and conveys the tool's purpose efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (zero parameters, no output schema), the description is largely complete. It states what the tool does, but omits details like timezone or return type, which might be relevant in some contexts. Still, for a simple time fetcher, it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline score is 4 per the rubric. The description does not need to explain parameter semantics, and the empty input schema is consistent with the tool's simplicity.

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

Purpose5/5

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

The description 'Get the current time' uses a specific verb ('get') and resource ('time'), clearly distinguishing it from the sibling tool get_weather. It is unambiguous and directly states the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternative guidance is provided. The sibling tool get_weather implies differentiation, but the description does not state when to use this over get_weather or any other tool. Usage is implied rather than explicitly guided.

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

get_weatherB

Get current weather information for a city

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYesThe city to get weather for
unitsNoTemperature units (metric or imperial)metric

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action and gives no insight into error handling, return format, defaults, or side effects.

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 sentence that is front-loaded and to the point, with no unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but with no output schema and no annotations, the description lacks detail about return values and usage context. It is minimally viable but leaves gaps.

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 schema provides 100% coverage for both parameters, including descriptions and a default for units, so the description adds no extra parameter meaning. Baseline 3 is appropriate.

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

Purpose5/5

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

The description 'Get current weather information for a city' uses a specific verb and resource, and clearly differs from the sibling tool get_time. It immediately conveys the tool's purpose without ambiguity.

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?

No guidance is provided about when to use this tool versus alternatives. The sibling tool get_time is not mentioned, and there is no context about suitable use cases or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedget_time
    • First observedget_weather
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: get_weather retrieves current weather data, while get_time retrieves the current time. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow the same get_<noun> pattern with snake_case, creating a predictable and consistent naming convention.

Tool Count3/5

With only 2 tools, the server feels thin for its stated weather domain. While not extreme, the count is borderline and the inclusion of get_time suggests a broader utility scope than the name implies.

Completeness2/5

The weather domain is significantly under-covered—only current conditions are included, with no forecast, historical data, or location search. The get_time tool is also unrelated to weather, leaving obvious gaps for any weather-related workflow.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Weather MCP Server

    wudongjie
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides real-time weather information and forecasts, connecting AI assistants with live weather data for current conditions and multi-day forecasts for any location worldwide.
    -

  • Weather MCP Server

    jefercort
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to fetch current weather conditions and forecasts for any city using the Open-Meteo API. Provides temperature, precipitation, and hourly forecast data through natural language queries.
    -

  • Weather MCP Server

    njohnsn
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides weather information through OpenWeather API, enabling users to get current weather conditions, 5-day forecasts, and perform temperature conversions for any city. Offers a secure interface for AI assistants to access comprehensive weather data including temperature, humidity, wind, and pressure information.
    -

  • OpenWeather MCP Server

    ProjectAtlantis-dev
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides real-time weather data and forecasts for locations worldwide using the OpenWeatherMap API. It enables AI assistants to retrieve current conditions, temperature, and forecasts through a simple tool-based interface.
    MIT