Отдельного официального MCP-сервера Яндекс Вебмастера в документации сервиса сейчас нет. Практический вариант — MCP-адаптер над официальным Webmaster API 4.1. Он превращает методы API в ограниченный набор инструментов для ассистента: получить сайты, прочитать статистику, проверить важные URL или поставить страницу в очередь переобхода.
Что должен делать MCP-адаптер
MCP описывает ресурсы и инструменты, которые клиент может вызывать структурированно. Для Вебмастера полезны безопасные операции чтения: список сайтов, сводка, поисковые запросы, внешние ссылки и важные URL. Действия изменения — добавление сайта, удаление или переобход — должны быть отделены и защищены подтверждением.
Официальные MCP-серверы Yandex Cloud для документации и облачных ресурсов не дают автоматически доступ к Яндекс Вебмастеру. Совпадение бренда не означает общий API или область разрешений.
Что подготовить до начала
- Рабочее OAuth-приложение и протестированный прямой доступ к Webmaster API.
- Выбран MCP SDK и транспорт, совместимый с вашим клиентом.
- Список разрешённых host-id и операций для каждой команды.
- Секреты хранятся на стороне MCP-сервера, а не в prompt или конфигурации репозитория.
Как подключить MCP
- Опишите минимальные read-only tools: list_sites, get_summary, get_queries и inspect_important_urls.
- Добавьте OAuth-хранилище и сопоставление пользователя MCP с токеном Яндекса.
- Валидируйте host-id и URL на сервере до обращения к API.
- Для recrawl, add и delete добавьте отдельные tools с явным подтверждением пользователя.
- Подключите сервер к клиенту MCP и проверьте журнал каждого вызова без вывода токена.
Какие инструменты давать агенту
Начинайте с чтения. Изменяющие вызовы добавляйте только после стабильного аудита.
| Сигнал или статус | Что он означает | Что делать |
|---|---|---|
| list_sites | Показывает доступные сайты | Возвращайте адрес, host-id и роль без секретов |
| get_summary | Читает сводные показатели | Передавайте период и дату обновления |
| get_queries | Получает поисковые показатели | Ограничивайте строки, фильтры и диапазон дат |
| submit_recrawl | Меняет очередь переобхода | Требуйте подтверждение и проверяйте квоту |
Риски MCP-интеграции
Главная угроза — не модель, а слишком широкие полномочия инструмента и утечка токена через логи.
| Проблема | Вероятная причина | Исправление |
|---|---|---|
| Токен попал в prompt | Секрет передаётся как аргумент tool | Храните его только на сервере по идентификатору сессии |
| Агент видит все сайты | Нет allowlist host-id | Ограничьте ресурсы на уровне сервера |
| POST выполняется без подтверждения | Read и write смешаны | Разделите инструменты и добавьте approval |
| Сторонний MCP принят за официальный | Не проверен владелец проекта | Аудируйте код, релизы, зависимости и OAuth-redirect |
Контроль результата и приёмка работы
Перед контрольным прогоном подготовьте всё, от чего зависит результат: Рабочее OAuth-приложение и протестированный прямой доступ к Webmaster API; Выбран MCP SDK и транспорт, совместимый с вашим клиентом; Список разрешённых host-id и операций для каждой команды; Секреты хранятся на стороне MCP-сервера, а не в prompt или конфигурации репозитория. Проверьте не только основной пример, но и второй URL или ресурс того же типа. В отчёте сохраните время, адрес проверяемого объекта, аккаунт и роль, фактический статус в интерфейсе, а для технической операции — HTTP-код и конечный URL.
list_sites означает: показывает доступные сайты. Контрольное действие: возвращайте адрес, host-id и роль без секретов. get_summary означает: читает сводные показатели. Контрольное действие: передавайте период и дату обновления. get_queries означает: получает поисковые показатели. Контрольное действие: ограничивайте строки, фильтры и диапазон дат. submit_recrawl означает: меняет очередь переобхода. Контрольное действие: требуйте подтверждение и проверяйте квоту.
Если воспроизводится «Токен попал в prompt», проверьте гипотезу «Секрет передаётся как аргумент tool» и выполните следующее: храните его только на сервере по идентификатору сессии. Если воспроизводится «Агент видит все сайты», проверьте гипотезу «Нет allowlist host-id» и выполните следующее: ограничьте ресурсы на уровне сервера. Если воспроизводится «POST выполняется без подтверждения», проверьте гипотезу «Read и write смешаны» и выполните следующее: разделите инструменты и добавьте approval. Если воспроизводится «Сторонний MCP принят за официальный», проверьте гипотезу «Не проверен владелец проекта» и выполните следующее: аудируйте код, релизы, зависимости и oauth-redirect.
Порядок приёмки для «MCP для Яндекс Вебмастера: как подключить и использовать»: Еженедельная сводка по сайтам и новым диагностическим сигналам; Сравнение запросов и URL между периодами с сохранёнными фильтрами; Проверка статуса важных страниц после релиза; Подготовка очереди переобхода с обязательным подтверждением перед отправкой. Отдельно укажите, что уже подтверждено live-проверкой, а что появится только после следующего обхода или обновления отчёта. Это не даст повторять отправку ради одного статуса в панели и сохранит воспроизводимую историю изменений.
Рабочие сценарии
- Еженедельная сводка по сайтам и новым диагностическим сигналам.
- Сравнение запросов и URL между периодами с сохранёнными фильтрами.
- Проверка статуса важных страниц после релиза.
- Подготовка очереди переобхода с обязательным подтверждением перед отправкой.
Частые вопросы
Есть ли официальный MCP Яндекс Вебмастера?
На момент проверки отдельный официальный сервер для Вебмастера не опубликован. Есть API Вебмастера и отдельные MCP-продукты Yandex Cloud для других задач.
Можно ли подключить готовый сервер с GitHub?
Можно после аудита кода, зависимостей, владельца, OAuth redirect и модели хранения токенов. Не выдавайте ему больше прав, чем нужно.
MCP ускорит индексацию?
Он может автоматизировать отправку и анализ статусов, но не меняет решение поискового робота.