Яндекс Вебмастер MCP: диагностика сайта через AI-агента

Поисковая аналитика Google не описывает всё, что происходит с сайтом в Яндексе. У Вебмастера собственные сведения о страницах в поиске, диагностике, запросах и переобходе. Я написал отдельный MCP-сервер на Go, чтобы работать с этими сведениями из того же диалога с агентом, сохраняя источник данных.

Webmaster MCP — независимый open-source проект. Он использует API Яндекс Вебмастера и один OAuth-токен на установку. Снаружи агент видит Streamable HTTP endpoint и инструменты с описанными входами и результатами. Сервер не является продуктом Яндекса.

Начать с точного host_id

Первый полезный вызов — list_hosts. Полученный host_id нужно передавать буквально: https:example.com:443 и http:example.com:80 обозначают разные хосты. Если придумать идентификатор из доменного имени, можно запросить не тот вариант сайта или получить ошибку доступа.

get_summary возвращает ИКС, количество страниц и сводку проблем. get_diagnostics раскрывает состояния отдельных проверок. get_popular_queries и get_query_history помогают изучать запросы и их историю. Есть также отчёты об индексации, страницах в поиске, ссылках, sitemap и очереди переобхода.

Запуск без настоящего OAuth-токена

git clone https://github.com/tenqz/webmaster-mcp.git
cd webmaster-mcp
docker compose -f compose.demo.yml up -d --build
docker compose -f compose.demo.yml exec mcp /mcp-server --smoke http://127.0.0.1:8080/mcp

Демо работает с синтетическими данными. Для клиента используй http://localhost:8080/mcp и заголовок Authorization: Bearer demo-token. В этом режиме успешный smoke означает работоспособность протокола и демо-инструментов, а не доступ к твоему кабинету Яндекса.

Подключение рабочего аккаунта

Останови демо через docker compose -f compose.demo.yml down. Скопируй .env.example в .env, получи OAuth-токен с доступом к Вебмастеру по инструкции репозитория и задай YANDEX_WEBMASTER_TOKEN. Отдельный MCP_AUTH_TOKEN нужен для подключения клиента. После этого запусти рабочий Compose и smoke:

docker compose up -d --build
docker compose exec mcp /mcp-server --smoke http://127.0.0.1:8080/mcp

Встроенного браузерного OAuth-входа у сервера нет. Токен Яндекса настраивает оператор. Для секретов, смонтированных файлами, поддерживаются YANDEX_WEBMASTER_TOKEN_FILE и MCP_AUTH_TOKEN_FILE. Одновременно задавать файл и соответствующее inline-значение нельзя. Удалённый доступ к endpoint требует HTTPS.

Диагностика должна отличать проблему от неизвестного состояния

Для агента я формулирую задачу так: «Выбери host_id из list_hosts. Получи summary и diagnostics. Перечисли проверки со статусом PRESENT, отдельно покажи UNDEFINED. Укажи время получения отчёта и не называй отсутствие данных исправной проверкой». Это полезнее общего запроса «сделай SEO-аудит»: у вывода есть проверяемое основание.

Состояние ABSENT означает отсутствие конкретной проблемы в отчёте. UNDEFINED не даёт такого вывода. Данные сохраняют даты и семантику Яндекса, поэтому их нельзя безоговорочно складывать с GSC. Различаются не только числа, но и определения отчётов.

Переобход — отдельное действие

submit_recrawl — единственный инструмент записи: он отправляет URL в очередь и расходует дневную квоту. Отправка не означает немедленной индексации. Для автоматического читателя можно установить MCP_READ_ONLY=true: инструмент исчезает из каталога, а прямой вызов также отклоняется. В этом режиме доступно 33 инструмента, в обычном — 34.

Я не повторяю отправку на переобход автоматически после сетевой ошибки. Если запрос уже мог попасть в Яндекс, ответ outcome_unknown означает именно неизвестный исход. Сначала нужно посмотреть очередь. Иначе повторная попытка может расходовать квоту на действие, которое уже принято.

Что хранить вне MCP-сервера

Сам сервер предоставляет доступ к отчётам. Расписание, базу исторических наблюдений и сопоставление с изменениями статей я выношу в отдельный сборщик. Рядом работают GSC MCP и ahref. Так ошибка одного источника не превращается в выдуманный ноль в общем отчёте.

Исходный код Webmaster MCP · Контракты отчётов · Что такое MCP