Выгрузка Яндекс Директа и Метрики по расписанию через MCP

Днём обсуждаете рекламу с ИИ, ночью сервер собирает статистику. Разбираем схему двух подключений на примере обращения в поддержку.

6 сентября 2026 · LidFly

Выгрузка Яндекс Директа и Метрики нужна к утру, а ноутбук с ИИ-клиентом вечером выключается. Главный вопрос: сможет ли сервер получить отчёты сам или придётся держать чат открытым? С такой задачей пользователь пришёл в поддержку LidFly: Ubuntu-сервер, ночной сбор статистики, PostgreSQL и витрина в Metabase.

В LidFly можно совместить оба способа работы. ИИ-клиент подключается для интерактивного анализа, серверный агент или обычный скрипт — для вызовов по расписанию. Оба обращаются к одному аккаунту одновременно. OAuth можно оставить в клиенте, а на сервере использовать статический ключ; если клиент поддерживает Bearer-авторизацию, ключ подойдёт и для него.

Что выяснили в поддержке

Пользователь уже перешёл со статического ключа на OAuth и хотел сохранить автоматический сбор без участия человека. Его интересовали совместная работа двух подключений, срок OAuth-сессии и изменения параметров инструментов. После ответа оператора он подтвердил, что вопросы закрыты.

Это разбор реального вопроса о подключении, а не кейс с готовыми цифрами. Переписка не подтверждает, что система уже запущена, и не содержит результатов внедрения. Ниже описаны поддерживаемая схема доступа и план сборщика, который разработчик реализует на своей стороне.

MCP-клиент может быть серверным скриптом

MCP задаёт способ обмена с инструментами. Программа может заранее знать, какой отчёт запросить и с какими параметрами. Для этого ей не нужно отправлять промпт языковой модели или ждать сообщения в чате.

LidFly отдаёт данные подключённых источников через свои инструменты. Ваш скрипт задаёт период и поля, проверяет результат и сохраняет его в вашу БД. Расписание, таблицы PostgreSQL и дашборд Metabase принадлежат вашей системе: одно MCP-подключение не создаёт их автоматически.

Интерактивный ИИ-клиент → OAuth или ключ → LidFly /mcp/v3
Скрипт на Ubuntu → ключ → LidFly /mcp/v3
                              ↓
                    Яндекс Директ + Метрика
                              ↓
                  проверка данных вашим скриптом
                              ↓
                    PostgreSQL → Metabase

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

OAuth и API-ключ работают на одном адресе

Для новых подключений используйте https://lidfly.ru/mcp/v3 с транспортом Streamable HTTP. Этот endpoint принимает OAuth и API-ключ LidFly в Bearer-авторизации. Legacy-адрес /mcp остаётся совместимым, но переходить на него ради серверного скрипта не требуется.

OAuth-вход не удаляет статический ключ. Его можно скопировать в кабинете: Настройки → API-ключ → Скопировать ключ. Не перегенерируйте ключ ради копирования: перегенерация заменит значение YOUR_API_KEY, и интеграции со старым ключом перестанут работать.

В одном OAuth-подключении не задавайте одновременно статический заголовок Authorization: он может мешать клиенту отправлять OAuth-токен. Разделите настройки: интерактивное подключение со своим OAuth, серверное — со своим способом Bearer-авторизации. Актуальные инструкции для конкретного клиента находятся в быстром старте LidFly.

Ключ LidFly не является токеном Яндекса. Подключение Яндекса и его доступы настраиваются в LidFly; ключ серверного сборщика храните как секрет. Для доступа коллег используйте предусмотренные права команды и Пространств, а не публикацию общего ключа.

Сценарий 1. Ночной сбор в PostgreSQL и Metabase

Исходная задача из обращения: ежедневная статистика должна попадать в собственную систему отчётности без открытого ИИ-клиента. Начните с небольшого периода и одного кабинета. Сначала получите проверяемую таблицу, затем включайте расписание.

Команда для подготовки плана с ИИ

Помоги спроектировать ночную выгрузку Директа и Метрики через LidFly MCP.
Сначала уточни кабинет Директа, счётчик Метрики и нужные цели.
Найди актуальные схемы инструментов отчётности и предложи поля,
период, ключи строк и проверки полноты для PostgreSQL.
Раздели то, что делает LidFly, и то, что должен делать мой сборщик.
Подготовь план первого пробного отчёта без изменений рекламы.

1. Уточните источник. Для Директа получите контекст через get_provider_context и используйте подтверждённые connection_id и, когда нужен клиентский кабинет, client_login. Счётчик Метрики выберите из metrika_get_counters. Если работа идёт в выбранном Пространстве, сохраняйте тот же workspace_project_id.
2. Найдите отчёты и их схемы. Через search_tools найдите get_custom_report, get_search_queries и metrika_get_report; через get_tool_schema получите актуальные параметры. Используйте только необходимые отчёты.
3. Выполните пробное чтение. После инициализации MCP вызывайте внутренние read-инструменты через call_tool. Это MCP-вызовы, а не отдельные REST-адреса вида «/get_custom_report».
4. Проверьте результат. Сверьте кабинет, даты, часовой пояс, поля, ошибки и полноту. Для Метрики согласуйте цели и модель атрибуции: одинаково названные показатели из двух систем нельзя автоматически считать одним и тем же.
5. Сохраните и перечитайте. Ваш код записывает проверенные данные в PostgreSQL, затем сверяет число строк, диапазон дат и контрольные суммы показателей. Повторный запуск за тот же период должен обновлять нужные строки без дублей.
6. Включите расписание. После проверки пробной таблицы настройте cron или другой планировщик на своём сервере. В Metabase показывайте время последней успешной загрузки, чтобы вчерашний отчёт не выглядел сегодняшним.

Результат первого этапа — таблица за выбранный период, сверенная с ответом источника. После подключения расписания исчезает ручной перенос отчётов. Определения показателей, обработка ошибок и контроль свежести остаются частью вашего процесса.

Какие срезы доступны и для чего они нужны, разобрано в статье об отчётах Яндекс Директа через API и LidFly. Здесь фокус на регулярной доставке этих данных в вашу систему.

Сценарий 2. Утренний разбор с ИИ при работающем сборщике

Типовой сценарий: отчёт обновился, расходы выросли, а число заявок осталось прежним. Вы открываете ИИ-клиента, подключённого к тому же аккаунту через OAuth, и просите прочитать свежие данные Директа и Метрики. Серверное подключение по ключу продолжает работать.

Сравни расходы Директа и целевые заявки Метрики за два последних
полных периода одинаковой длины. Уточни кабинет, счётчик и цели.
Проверь изменения по кампаниям и поисковым запросам.
Покажи источники, даты и ограничения сравнения.
Подготовь список причин для проверки. Рекламу пока не меняй.

ИИ читает нужные отчёты через LidFly, отделяет подтверждённые изменения от гипотез и готовит список проверок. Например, предлагает посмотреть поисковые запросы кампании с выросшими расходами или сопоставить выбранные цели. Проверяемый результат — отчёт с периодами, источниками и основаниями выводов.

Одно лишь подключение LidFly не даёт ИИ доступа к вашей PostgreSQL. Для сравнения с хранилищем передайте безопасную выгрузку или отдельно подключите разрешённый инструмент чтения БД. Сборщик и ИИ-клиент используют общий аккаунт, но каждый выполняет свою часть работы.

Если анализ приведёт к изменению рекламы, сначала согласуйте конкретный план, затем подтвердите действие и перечитайте состояние кампании. Для нескольких клиентов заранее разделите контекст по Пространствам, чтобы отчёт одного бизнеса не попал в выводы другого.

Сколько живут OAuth и статический ключ

Стандартный access token OAuth LidFly действует 15 минут. Клиент с поддержкой refresh token получает новые токены автоматически. Сама авторизация имеет абсолютный срок 90 дней, который обновление не продлевает; 30 дней неактивности также завершают её. После истечения нужен повторный вход. Отзыв доступа может потребовать его раньше.

Это сроки авторизации в LidFly, а не подключения Яндекса. У статического API-ключа нет такого календарного срока: для его работы должны сохраняться сам ключ, доступ к аккаунту и источникам, а для платных возможностей — активный доступ. Поэтому серверный сценарий по ключу не зависит от периодического интерактивного OAuth-входа, но всё равно должен контролировать ошибки доступа.

Как не записать половину отчёта

Вопрос «хватит ли лимитов на несколько вызовов в сутки» не определяет надёжность сборщика. Несколько тяжёлых запросов за большой период могут дать слишком объёмный результат или пересечься с другой нагрузкой того же аккаунта.

Обычный успешный текстовый результат v3 ограничен 80 000 символов. При превышении появляется отметка об обрезке. Такой ответ нельзя считать полной исторической выгрузкой. Разбивайте её по периодам, полям или страницам только теми параметрами, которые объявлены в схеме конкретного инструмента. Не все отчёты поддерживают одинаковую пагинацию.

• Проверяйте isError, ожидаемый формат и полноту данных до записи в основную таблицу. Ошибка источника не означает нулевые расходы.
• Храните последний успешно завершённый период. Не сдвигайте его после частичного ответа.
• Учитывайте Retry-After при временном ограничении нагрузки и не запускайте множество повторов одновременно.
• Для исторической загрузки сначала проверьте небольшой интервал, затем обрабатывайте остальные части с контролируемой параллельностью.
• Уведомляйте о пропуске загрузки и показывайте свежесть данных на дашборде.

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

Версия MCP не заменяет проверку схем

По состоянию на 6 сентября 2026 года отдельный публичный changelog сигнатур инструментов и гарантированный срок предварительного уведомления об их изменении не заявлены. Версия и digest skills относятся к пакету инструкций. Адрес /mcp/v3 не закрепляет неизменный формат каждого отчёта.

Сохраняйте входные схемы из get_tool_schema, на которые опирается сборщик, и сравнивайте их перед обновлением. Ответы валидируйте отдельно: неизменная входная схема не доказывает, что формат результата тоже остался прежним. Полезно хранить обезличенный пример ответа и проверять преобразование на нём перед обновлением кода.

Частые вопросы

Можно ли работать через MCP без открытого чата?

Да. Серверный скрипт сам выступает MCP-клиентом и вызывает инструменты по расписанию. Для заранее заданного отчёта участие языковой модели не требуется.

Могут ли OAuth-клиент и сервер по ключу работать одновременно?

Да. Оба подключения могут обращаться к /mcp/v3 от одного аккаунта. Ключ можно использовать и в ИИ-клиенте, если он поддерживает Bearer-авторизацию. Технические ограничения нагрузки и API при этом сохраняются.

Нужно ли переходить на /mcp ради статического ключа?

Нет. Рекомендуемый для новых подключений адрес /mcp/v3 принимает как OAuth, так и API-ключ LidFly. Legacy-адрес не нужен для серверной автоматизации.

Истекает ли API-ключ через 90 дней, как OAuth?

У статического ключа нет такого календарного срока. Его работа зависит от сохранения ключа, доступа к аккаунту и источникам, а для платных возможностей — активного доступа. Перегенерация заменяет старый ключ.

Можно ли считать ответ MCP полной выгрузкой?

Только после проверки ошибок, периода, страниц и полноты результата. Текстовый ответ v3 может быть обрезан до 80 000 символов с явной отметкой. Такой отчёт нужно запросить меньшими частями.

Начните с одного проверенного отчёта

Подключите источники в кабинете LidFly, оставьте удобный ИИ-клиент для анализа и настройте отдельное серверное подключение по ключу. Сначала сверяйте небольшой отчёт, затем запись в БД и повторную загрузку без дублей. После этого включайте расписание.