How do I use Yandex Weather MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Yandex Weather MCP What's the current weather in Moscow?" 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.

Yandex Weather MCP

by aleks-yustas

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Yandex Weather MCP

Локальный MCP-сервер для получения данных из API Яндекс Погоды по координатам. Сервер прячет API-ключ от MCP-клиента, валидирует входные параметры, нормализует ответ API и кэширует запросы на 5-15 минут.

Технический консилиум

Backend-разработчик: на первом этапе нужны четыре инструмента MCP: текущая погода, прогноз, короткая сводка и сравнение двух точек. Запрашивать стоит координаты, язык, лимит дней, почасовой прогноз и расширенные поля. Пользователю полезны температура, ощущается как, состояние, ветер, влажность, давление, осадки, рассвет/закат и служебный признак кэша.

DevOps-инженер: локальный Docker-запуск должен получать секреты только через env, работать не от root и иметь простой healthcheck. Риски: stdio MCP плохо сочетается с обычной HTTP-проверкой, .env легко случайно закоммитить, а сеть из контейнера должна иметь доступ к API.

Специалист по API-интеграциям: клиенту нужен таймаут, понятная обработка 401/403/404/429/400, аккуратный JSON parsing и endpoint, который можно переопределить через env. Для первого этапа не стоит делать агрессивные retry: погодный запрос безопасен, но повтор при 429 только быстрее сожжет лимит.

Специалист по MCP: инструменты лучше возвращать JSON как text content, потому что это совместимо с большинством MCP-клиентов и удобно для отладки. Ошибки возвращаются структурированно в { error: { code, message, details } }.

Специалист по типизации и качеству: TypeScript + Zod дают строгие контракты на входе и нормализацию на выходе. В тестах нужно закрыть координаты, маппинг состояний, отсутствующий ключ, ошибки API, кэш и нормализацию.

Related MCP server: MCP Weather Server

Архитектурное решение

Для первого этапа выбран TypeScript / Node.js. Python быстрее для прототипа, Rust надежнее для production-бинарника, но TypeScript дает лучший баланс MCP-экосистемы, строгих типов, Docker-упаковки и скорости разработки.

Проект устроен так:

src/
  index.ts
  server.ts
  config.ts
  yandexWeatherClient.ts
  tools/
  schemas/
  utils/
Dockerfile
docker-compose.yml
README.md
.env.example

По документации: публично используемый endpoint Яндекс Погоды для прогноза обычно выглядит как https://api.weather.yandex.ru/v2/forecast с ключом в заголовке X-Yandex-API-Key. В коде endpoint вынесен в YANDEX_WEATHER_API_URL, чтобы без изменения сервера перейти на endpoint вашего тарифа, если в личном кабинете доступна другая версия.

Настройка

Получите API-ключ в кабинете Яндекс Погоды / Яндекс API, затем создайте .env:

cp .env.example .env

Заполните:

YANDEX_WEATHER_API_KEY=your_api_key_here
YANDEX_WEATHER_LANG=ru_RU
CACHE_TTL_SECONDS=600
LOG_LEVEL=info
MCP_TRANSPORT=http
HOST=0.0.0.0
PORT=3000

Не храните настоящий ключ в коде, Dockerfile или README.

Локальный запуск

npm install
npm run build
npm start

Для разработки:

npm run dev

Docker

Для серверного запуска используется HTTP transport MCP на /mcp. Создайте .env перед запуском:

cp .env.example .env

Заполните YANDEX_WEATHER_API_KEY, затем запустите:

docker compose up --build

Проверка здоровья:

curl http://localhost:3000/health

MCP endpoint:

http://localhost:3000/mcp

Если нужен локальный stdio-режим для MCP-клиента, запускайте Node напрямую или переопределите MCP_TRANSPORT=stdio:

{
  "mcpServers": {
    "yandex-weather": {
      "command": "npm",
      "args": ["start"],
      "env": {
        "YANDEX_WEATHER_API_KEY": "your_api_key_here"
      }
    }
  }
}

MCP tools

`get_current_weather`

Вход:

{
  "lat": 55.7558,
  "lon": 37.6173,
  "lang": "ru_RU"
}

Возвращает location, current и meta.

`get_weather_forecast`

Вход:

{
  "lat": 55.7558,
  "lon": 37.6173,
  "lang": "ru_RU",
  "days": 3
}

Возвращает прогноз по дням, частям суток и почасовым данным, если они доступны для тарифа/API.

`get_weather_summary`

Вход:

{
  "lat": 55.7558,
  "lon": 37.6173
}

Пример ответа:

{
  "summary": "Сейчас +18°C, ощущается как +16°C. Пасмурно, ветер 4 м/с, влажность 78%.",
  "advice": "Вероятность осадков повышенная, стоит взять зонт или дождевик."
}

`compare_weather`

Вход:

{
  "first": { "lat": 55.7558, "lon": 37.6173, "name": "Москва" },
  "second": { "lat": 59.9386, "lon": 30.3141, "name": "Санкт-Петербург" },
  "lang": "ru_RU"
}

Возвращает две нормализованные погодные карточки и сравнение по температуре, ветру и влажности.

Деплой на VDS

Требования

Docker 24+ и Docker Compose V2 (docker compose)
Открытый порт на сервере (например 3000) или Nginx как reverse proxy

Шаги

# 1. Клонировать репозиторий на сервер
git clone <url> yandex-weather-mcp
cd yandex-weather-mcp

# 2. Создать директорию для базы данных планировщика
mkdir -p data

# 3. Создать .env и вписать ключ
cp .env.example .env
nano .env   # выставить YANDEX_WEATHER_API_KEY и, если нужно, PORT

# 4. Запустить
docker compose up -d --build

# 5. Проверить
curl http://localhost:3000/health

После этого MCP endpoint доступен на http://<vds-ip>:3000/mcp.

Nginx reverse proxy (рекомендуется)

Позволяет закрыть прямой доступ к порту 3000 и выставить наружу только 443/80.

server {
    listen 443 ssl;
    server_name weather-mcp.example.com;

    ssl_certificate     /etc/letsencrypt/live/weather-mcp.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/weather-mcp.example.com/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_read_timeout 30s;
    }
}

После этого можно держать порт 3000 закрытым в firewall и обращаться к https://weather-mcp.example.com/mcp.

Firewall

Если Nginx не используется и порт открыт напрямую — ограничьте доступ по IP:

# UFW пример
ufw allow from <trusted-ip> to any port 3000
ufw deny 3000

Управление контейнером

# Посмотреть логи (включая тики планировщика)
docker compose logs -f

# Перезапустить
docker compose restart

# Обновить после git pull
git pull && docker compose up -d --build

# Остановить (данные БД сохраняются в ./data/)
docker compose down

# Остановить и удалить данные БД
docker compose down && rm -rf data/

Контейнер настроен на restart: unless-stopped — поднимается автоматически после перезагрузки сервера.

Персистентность базы данных планировщика

Планировщик хранит историю наблюдений в SQLite (weather.db). Без volume файл живёт внутри контейнера и пропадает при docker compose down или пересборке образа.

docker-compose.yml уже настроен на монтирование ./data/weather.db — достаточно создать директорию перед первым запуском:

mkdir -p data

Путь к файлу управляется переменной WEATHER_DB_PATH в .env. Менять не нужно, если устраивает ./data/weather.db.

MCP endpoint для клиента

{
  "mcpServers": {
    "yandex-weather": {
      "url": "http://<vds-ip>:3000/mcp"
    }
  }
}

Или с Nginx:

{
  "mcpServers": {
    "yandex-weather": {
      "url": "https://weather-mcp.example.com/mcp"
    }
  }
}

Ошибки

Ошибки возвращаются в едином формате:

{
  "error": {
    "code": "AUTH_ERROR",
    "message": "Yandex Weather API rejected the API key",
    "details": {}
  }
}

Поддержанные коды: CONFIGURATION_ERROR, VALIDATION_ERROR, AUTH_ERROR, RATE_LIMITED, NOT_FOUND, TIMEOUT, NETWORK_ERROR, INVALID_JSON, UNEXPECTED_RESPONSE, UNSUPPORTED_API_PARAMETER, YANDEX_API_ERROR.

Тестирование

npm test
npm run typecheck

Тесты покрывают:

валидацию координат;
маппинг погодных состояний;
отсутствующий API-ключ;
ошибку API;
работу кэша;
нормализацию ответа Яндекс Погоды.

Ограничения

Сервер не делает геокодинг по названию города.
Набор полей зависит от тарифа и endpoint Яндекс Погоды.
Кэш хранится только в памяти процесса.
HTTP healthcheck проверяет живой процесс и конфигурацию, но не дергает внешний API Яндекс Погоды.

Roadmap второго этапа

геокодинг по названию города;
хранение избранных локаций;
Prometheus-метрики;
Grafana dashboard;
rate limiting;
persistent cache через SQLite/Redis;
поддержка нескольких weather-провайдеров;
алерты: дождь, мороз, сильный ветер;
интеграция с Home Assistant.

Available Tools

4 tools

compare_weatherC

Compare current weather in two locations

ParametersJSON Schema

Name	Required	Default
`lang`	No	ru_RU
`first`	Yes
`second`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, permissions required, or what it returns, leaving the agent uninformed about 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loaded with the purpose, but it sacrifices necessary detail, making it minimally adequate rather than optimally structured for clarity.

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

Completeness2/5

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

Given the complexity of nested objects, multiple parameters, and lack of output schema, the description fails to provide essential context on how to specify locations, the language option, or the response format, leaving significant gaps.

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

Parameters2/5

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

The description does not add meaning to the parameters beyond stating 'two locations'; the schema has no descriptions (0% coverage), and parameters like 'lang' and nested lat/lon/name are not explained, which is insufficient for correct invocation.

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 clearly states the verb 'compare' and the resource 'current weather' with two locations, distinguishing it from siblings like get_current_weather which likely handles one location.

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 explicit guidance on when to use this tool versus alternatives; the description only states what it does without mentioning when not to use it or how it differs from siblings.

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

get_current_weatherB

Get current weather by coordinates

ParametersJSON Schema

Name	Required	Default
`lat`	Yes
`lon`	Yes
`lang`	No	ru_RU

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states the basic function without mentioning output format, authentication requirements, rate limits, or any side effects. This minimal disclosure is insufficient for an agent to understand the tool's full impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at five words, which is efficient. However, it lacks any structure (e.g., separate sentences for purpose, parameters, output) and could be slightly expanded for clarity without losing conciseness.

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?

Given the tool's simplicity (3 parameters, no output schema), the description covers the core purpose but omits expected return values (e.g., temperature, conditions). This gap could confuse an agent needing to interpret results. It is adequate but not fully complete.

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

Parameters2/5

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

With 0% schema description coverage, the description adds little beyond parameter names. It mentions 'coordinates' but does not explain each parameter's role, format (e.g., decimal degrees), or the optional 'lang' parameter. The agent gains no extra meaning from the description.

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 by coordinates' specifies a clear verb ('Get'), resource ('current weather'), and method ('by coordinates'). It effectively distinguishes from sibling tools like 'get_weather_forecast' (future) and 'compare_weather' (comparison).

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 on when to use this tool versus siblings or when not to use it. The description does not mention any prerequisites, exclusions, or alternative tools, leaving the agent to infer usage context implicitly.

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

get_weather_forecastC

Get weather forecast by coordinates

ParametersJSON Schema

Name	Required	Default
`lat`	Yes
`lon`	Yes
`days`	No
`lang`	No	ru_RU

TDQS

C2.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic function without mentioning data freshness, time range, units, or return format. Minimal transparency beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise but at the cost of necessary information. It is under-specified for a tool with 4 parameters and sibling tools.

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

Completeness1/5

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

Given 4 parameters, no output schema, and no annotations, the description is highly incomplete. It fails to explain what the forecast includes, how 'days' works, or any other contextual details.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no explanation of parameters (lat, lon, days, lang). The input schema defines constraints but the description does not elaborate on how these parameters affect the forecast.

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

Purpose4/5

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

The description clearly states the tool retrieves a weather forecast using coordinates. It uses a specific verb ('Get') and resource ('weather forecast'), and 'by coordinates' indicates the input method. While it doesn't explicitly distinguish from siblings like 'get_current_weather', the purpose is clear enough.

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 given on when to use this tool versus its siblings ('compare_weather', 'get_current_weather', 'get_weather_summary'). The description lacks context about the intended use case.

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

get_weather_summaryC

Build a short human-readable weather summary

ParametersJSON Schema

Name	Required	Default
`lat`	Yes
`lon`	Yes
`lang`	No	ru_RU

TDQS

C2.3/5.0

Behavior1/5

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

With no annotations provided, the description must disclose behavioral traits. It only states the general purpose, failing to mention limitations, data sources, or any side effects. Essential for a tool that produces a derived output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While concise (one sentence), it is under-specified. The description lacks necessary details to be appropriately sized, sacrificing completeness for brevity.

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

Completeness1/5

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

Given no output schema, the description should clarify what the summary contains (e.g., temperature, conditions, time range). It does not, leaving the agent without enough information to judge the tool's suitability.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. No explanation of what lat/lon represent or how lang affects output, leaving the agent to infer from schema constraints alone.

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?

Clearly states it builds a short human-readable weather summary, distinguishing it from siblings like get_current_weather or get_weather_forecast by focusing on a summary output.

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 on when to use this tool versus alternatives like compare_weather or get_current_weather. Lacks any context about prerequisites or exclusions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation5/5

Each tool has a distinct purpose: current weather, forecast, comparison between two locations, and a human-readable summary. No overlapping functionality.

Naming Consistency4/5

Three tools follow the 'get_weather_*' pattern, while 'compare_weather' uses a different verb but still follows verb_noun convention. The naming is mostly consistent.

Tool Count5/5

Four tools is an appropriate count for a weather server, covering core needs without being excessive or sparse.

Completeness4/5

Covers essential weather operations (current, forecast, comparison, summary). Missing historical data or alerts, but these are minor gaps that agents can work around.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

weather-mcp
io.github.kulybaba
An MCP server for weather information by @kulybaba
Weather Services Location Services
2
Weather MCP
io.github.kulybaba
An MCP server for weather information by @kulybaba
Weather Services Location Services
2
weather-mcp A
io.github.darshan0548
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
Weather Services Location Services
51
weather-mcp
io.github.sercanmetalore
Open-Meteo tabanlı anahtarsız hava durumu tahmin MCP sunucusu.
Weather Services Open Data
1

Related MCP Servers

MCP Weather Server
Weather Services Search Open Data
damerakd
A
license
B
quality
D
maintenance
Provides tools to retrieve current weather conditions and daily forecasts for cities worldwide using the Open-Meteo API. This Python-based server enables MCP-compatible clients to access real-time meteorological data through a standardized interface.
Updated 6 months ago (2026-03-11 04:50 UTC)
2
MIT
MCP Weather Server
Weather Services AI & Machine Learning
dolgova
F
license
Not graded
quality
D
maintenance
MCP server that provides current weather and forecasts via Open-Meteo API, with an optional ML-based next-day max temperature prediction.
Updated 7 months ago (2026-02-10 07:52 UTC)
wetter-mcp-server
Weather Services Location Services
Schimmilab
A
license
A
quality
B
maintenance
MCP server for weather forecasts via Open-Meteo (no API key needed), providing current weather, hourly, and daily forecasts with geocoding support.
Updated 20 days ago (2026-08-15 03:55 UTC)
3
MIT
Weather MCP Server
Weather Services Open Data
newcoast27-hub
F
license
Not graded
quality
C
maintenance
An MCP server providing worldwide weather via the free Open-Meteo APIs (no API key needed). Runs fully self-contained in Docker as a streamable-HTTP MCP service.
Updated 2 months ago (2026-07-14 02:35 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aleks-yustas/yandex-weather-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server