weather_mcp
# Прогноз погоды через 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
Scored across 1 tool
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.
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.
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.
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.