Skip to main content
Glama
AronSoldok

weather_mcp

by AronSoldok
README.md
# Прогноз погоды через MCP

Учебный проект: MCP-сервер ходит в публичный API [Open-Meteo](https://open-meteo.com/), консольный клиент спрашивает город (кириллицей или латиницей) и печатает прогноз на 7 дней.

## Что такое MCP

**MCP (Model Context Protocol)** — открытый стандарт Anthropic (конец 2024). Коротко для собеседования: это «USB-C для ИИ». Один протокол, чтобы подключать к модели внешние системы (API, файлы, БД) без самописного плагина под каждый чат.

Три роли:

- **Host** — приложение, в котором живёт модель (Cursor, Claude Desktop) или, как здесь, наше CLI.
- **Client** — сторона, которая говорит с сервером по протоколу: handshake, список инструментов, вызов.
- **Server** — процесс, который *отдаёт* инструменты. Он не чат и не модель, а розетка с функциями.

Три примитива протокола (в этом проекте только первый):

- **Tools** — функции с JSON Schema аргументов. Методы `tools/list` и `tools/call`. У нас это `get_forecast(city)`.
- **Resources** — данные «как файлы» по URI. Не используем.
- **Prompts** — шаблоны промптов. Не используем.

Связь — **JSON-RPC 2.0**. Локально идёт по **stdio**: клиент запускает сервер как subprocess и пишет JSON-строки в его stdin. Поэтому сервер **нельзя** логировать через `print()` — это попадёт в тот же поток, что и протокол, и сломает его. Логи только в stderr (`logging`).

### Чем этот проект отличается от Cursor

«Классический» хост — Cursor: модель сама решает, какой tool вызвать. Здесь хост — `client.py`: город вводит человек, клиент явно вызывает `get_forecast`. Протокол тот же, LLM нет. Так проще увидеть handshake, `list_tools` и `call_tool` без «магии модели».

### «Зачем MCP, если есть REST?»

REST — как сервер разговаривает с Open-Meteo. MCP — как ИИ-приложение разговаривает с *вашим* сервером: единый каталог инструментов, схемы аргументов, один транспорт. Сервер пишете один раз — его могут вызвать Cursor, Claude Desktop или этот CLI.

Спецификация: [modelcontextprotocol.io](https://modelcontextprotocol.io/).

## Как это устроено здесь

1. Вы запускаете клиент и вводите город (`Москва` или `Moscow`).
2. Клиент поднимает MCP-сервер по stdio и вызывает tool `get_forecast`.
3. Сервер ищет координаты в Geocoding API (кириллица → `language=ru`, иначе `en`) и берёт 7 дней из Forecast API.
4. Клиент печатает таблицу: дата, день недели, погода, мин/макс, осадки, ветер.

Ключ API не нужен.

## Запуск

Нужны Python 3.10+ и [uv](https://docs.astral.sh/uv/).

```powershell
cd Checking_weather_MCP
uv sync
uv run python -m weather_mcp.client
```

Если команда `uv` не находится, тот же CLI ставится через pip: `py -m pip install uv`, дальше `py -m uv sync` и `py -m uv run python -m weather_mcp.client`.

Появится приглашение `Город:`. После ввода — таблица на неделю.

Сервер отдельно обычно не запускают: без клиента он просто ждёт JSON-RPC на stdin. Если нужно вручную:

```powershell
uv run python -m weather_mcp.server
```

TDQS

A3.6/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlap. The single tool's purpose is clearly defined as a 7-day forecast by city name.

Naming Consistency4/5

The tool name get_forecast follows a clear verb_noun convention that would be consistent with a broader weather toolset. However, with only one tool, the naming pattern is not fully demonstrable.

Tool Count1/5

A single tool is far too few for a weather server, which typically requires current conditions, geocoding, unit preferences, and alerts. This feels like an extreme under-scoping of the domain.

Completeness1/5

The tool surface is severely incomplete for a weather service. It only provides a 7-day forecast, leaving out current weather, location search, weather alerts, and other common weather data operations.

Maintenance

ActivityMaintained
ResponsivenessNo issues