Weather MCP Server - Clean Architecture

A Model Context Protocol (MCP) server for weather information, built using Clean Architecture principles.

Architecture

This project follows Clean Architecture with clear separation of concerns:

┌─────────────────────────────────────┐
│     Weather.Presentation (MCP)     │  ← Entry point
├─────────────────────────────────────┤
│    Weather.Infrastructure (API)    │  ← External services
├─────────────────────────────────────┤
│   Weather.Application (Use Cases)  │  ← Business logic
├─────────────────────────────────────┤
│      Weather.Domain (Entities)     │  ← Core domain
└─────────────────────────────────────┘

Layers

• Domain: Core business entities and value objects (no dependencies)
• Application: Use cases and interfaces (depends only on Domain)
• Infrastructure: External service implementations (depends on Application)
• Presentation: MCP server and tools (depends on Application & Infrastructure)

Project Structure

weather/
├── src/
│   ├── Weather.Domain/
│   │   ├── Entities/
│   │   │   ├── WeatherAlert.cs
│   │   │   └── WeatherForecast.cs
│   │   ├── ValueObjects/
│   │   │   ├── StateCode.cs
│   │   │   └── Coordinates.cs
│   │   └── Weather.Domain.csproj
│   │
│   ├── Weather.Application/
│   │   ├── Interfaces/
│   │   │   └── IWeatherService.cs
│   │   ├── UseCases/
│   │   │   ├── GetWeatherAlertsUseCase.cs
│   │   │   └── GetWeatherForecastUseCase.cs
│   │   └── Weather.Application.csproj
│   │
│   ├── Weather.Infrastructure/
│   │   ├── Services/
│   │   │   └── WeatherGovService.cs
│   │   └── Weather.Infrastructure.csproj
│   │
│   └── Weather.Presentation/
│       ├── Tools/
│       │   └── WeatherTools.cs
│       ├── Program.cs
│       └── Weather.Presentation.csproj
│
└── Weather.CleanArchitecture.sln

Building

dotnet build Weather.CleanArchitecture.sln

Or build the presentation project directly:

dotnet build src/Weather.Presentation

Running

dotnet run --project src/Weather.Presentation

Available Tools

• GetAlerts: Get weather alerts for a US state
• GetForecast: Get weather forecast for coordinates

Benefits of This Architecture

1. Testability: Each layer can be tested independently
2. Maintainability: Clear separation of concerns
3. Flexibility: Easy to swap implementations (e.g., change weather API provider)
4. Domain Focus: Business logic isolated from infrastructure
5. Scalability: Can easily add new features or data sources
6. Dependency Inversion: Core logic doesn't depend on external services

Key Design Decisions

• Value Objects: StateCode and Coordinates validate inputs and prevent invalid states
• Domain Entities: WeatherAlert and WeatherForecast encapsulate weather data with formatting logic
• Use Cases: Each use case has a single responsibility and clear input/output
• Dependency Injection: All dependencies are injected, making testing straightforward
• Interface Segregation: IWeatherService defines only the operations needed by the application layer