Полное управление рекламными кампаниями Яндекс Директа через MCP-протокол. Кампании, объявления, ставки, статистика и многое другое. Поддерживаются несколько OAuth-подключений Яндекса в одном аккаунте LidFly через параметр connection_id.
Подключение Claude Code, Codex, ChatGPT и других MCP-клиентов идёт через единый сервер https://lidfly.ru/mcp/v3 и OAuth-авторизацию в браузере. API-ключ вручную копировать не нужно.
Чтобы добавить кабинет Директа, в LidFly нажмите «Подключить Яндекс», а затем выберите нужный личный профиль или организацию porg-... на странице Яндекса. Вводить логин организации в LidFly не нужно: после проверки через Direct API сохраняется именно выбранный Яндексом логин.
Если выбранный профиль не подключён к Директу (код 513), LidFly предложит повторить подключение и выбрать организацию или другой профиль с кабинетом Директа. Если ранее работавший токен действительно отозван или устарел (код 53), подключение и его связи останутся в списке со статусом «Нужно переподключить».
При кратковременной перегрузке MCP сервер отвечает HTTP 429, заголовком Retry-After и JSON-RPC ошибкой -32002. Клиенту следует повторить запрос после указанной задержки без запуска нескольких параллельных повторов.
Для новых подключений используйте единый endpoint /mcp/v3. Полный provider endpoint /mcp остаётся для legacy/advanced сценариев. Все meta-инструменты из tools/list, включая get_provider_context и resolve_campaign_scope, AI вызывает напрямую; в call_tool/call_write_tool передаются только внутренние инструменты, найденные через search_tools.
Если задача относится к известному ограничению публичного API Яндекса, search_tools добавляет к обычной ранжированной выдаче capability_notice.status=unsupported_by_provider_api с понятным следующим шагом. Предупреждение относится только к неподдерживаемой части задачи: похожие инструменты нельзя использовать вместо неё, но легитимные инструменты из смешанного запроса остаются доступны. Например, контент лендингов Директа на clients.site и турбо-страницах нельзя прочитать или изменить через API: это делается в веб-интерфейсе Директа. Такое ограничение не является ошибкой LidFly и не требует обращения в поддержку.
Личная поддержка доступна через это же MCP-подключение. При неожиданной внутренней ошибке read-only support_prepare_report подготавливает очищенный черновик с incident ID, но ничего не отправляет. ИИ обязан показать черновик и получить явное текстовое согласие; только затем support_send_message может отправить текст до 20 000 символов и до пяти PNG/JPEG/WebP через support_request_image_upload. support_get_messages и support_get_attachment читают только диалог вошедшего пользователя. В v3 все пять инструментов вызываются напрямую; выбранный рекламный кабинет или проект не меняет владельца переписки.
Если подключено несколько Яндекс-логинов или клиентских кабинетов, AI сначала вызывает get_provider_context. query остаётся свободным поиском по проекту, названию и ИНН, а точный логин Директа передаётся отдельно в client_login; оба поля можно указать вместе. Старые клиенты могут продолжать передавать синтаксически допустимый логин в query, но такой вызов всё равно проходит exact live-проверку. Готовый агентский scope с workspace_project_id + connection_id + client_login возвращается только после точного совпадения с каталогом Яндекса. Частичное совпадение не исполняется. Для устаревшей привязки проекта без nested scope_args собственный подтверждённый primary-логин однозначно восстанавливает connection_id без live-каталога; агентский логин проверяется live. Такие read-проверки не меняют данные проекта, выполняются параллельно в общем пятисекундном бюджете, а причины outage, not-found, неоднозначности, отсутствующего подключения и конфликта возвращаются в scope_issues. ИИ может автоматически повторить только помеченный безопасный read-only retry и не должен обходить manual_scope_review догадками.
Если Директ подключён в LidFly, но ещё не привязан к выбранному Пространству, это не конфликт и не сбой. Владелец или администратор проекта получает в provider_link_candidates проверенные кабинеты и готовое действие workspace_upsert_provider_entity. Кандидат пока не исполняем в проекте; ИИ может записать связь только через call_write_tool после выбора точного кабинета и подтверждения. Для основного кабинета передаётся только connection_id, без придуманного client_login. Участникам с доступом только на чтение несвязанные кабинеты владельца не показываются.
Если известна кампания — используется resolve_campaign_scope, который сначала ищет её в Пространствах, а затем умеет выполнить live fallback через подтверждённый project scope, даже когда кабинет отсутствует в локальном списке. В рабочие инструменты передаются только точные workspace_project_id, connection_id и при необходимости client_login из tool_args/scope_arguments. Для primary-кабинета используется только connection_id: числовой ClientId или другой generic account key не подставляется как client_login. Новую Yandex-привязку можно сохранить только из проверенного кабинета с активным OAuth-подключением; workspace_upsert_provider_entity, workspace_sync_campaigns и HTTP API отклоняют непроверенный scope. Частичное обновление имени, статуса или primary-флага существующей привязки сохраняет её scope без повторной live-проверки. Campaign write без workspace_project_id проходит только когда preflight нашёл единственный Workspace/provider scope. Инструменты Метрики используют counter_id, а не client_login.
Для агентских и управляемых Яндекс-аккаунтов список клиентов берётся через get_agency_clients: сначала из AgencyClients.get, а если Яндекс возвращает ошибку 54 — из live-поля Clients.get.ManagedLogins. Ошибка 53 в запросе с client_login сама по себе не отключает OAuth: LidFly проверяет основной кабинет без этого заголовка и переводит подключение в ошибку только если Яндекс отвергает и основной токен. Настоящее агентство с доступным AgencyClients.get стоит 4 990 руб. за 30 дней. Кабинеты из ManagedLogins тарифицируются по количеству: 990 руб. за каждый, максимум 4 990 руб. за одно подключение; пять кабинетов стоят 4 950 руб. Список для расчёта обновляется ежедневно. Если автоматический список пустой, сохраните client_login вручную из «Доступных аккаунтов».
Через публичный API Яндекса — нет. get_turbo_pages возвращает только метаданные опубликованных Турбо-страниц и связанные turbo.site-ссылки, но не каталог лендингов clients.site; get_leads выгружает только отправленные формы. API не отдаёт настройки блоков и не позволяет создать, изменить, опубликовать или удалить контент лендинга.
Откройте лендинг в интерфейсе Яндекс Директа и внесите изменения там. Если ваш ИИ-клиент отдельно умеет управлять уже авторизованным браузером, можно попросить его выполнить действия в интерфейсе с проверкой результата. Изменять вместо этого объявление или кампанию не нужно.
Да, но только в пределах того, что разрешает API Яндекса. Если ИИ не может изменить кампанию из Мастера, это не ограничение LidFly: Яндекс сам не отдаёт управление такими кампаниями через API.
LidFly может находить кампании из Мастера через discover_all_campaigns и смотреть по ним статистику через Reports API: показы, клики, расход, CTR, конверсии.
Через API нельзя создать или отредактировать кампанию из Мастера, изменить бюджет, таргетинг, ставки, получить группы, объявления или ключевые фразы, а также поставить такую кампанию на паузу.
Если вы работаете с собственным ИИ-ассистентом, Мастер кампаний обычно не нужен: это автоматический формат с минимумом рычагов, который часто расходует бюджет менее прозрачно. Для полного контроля через ИИ лучше переходить на кампании режима эксперта: ЕПК (UNIFIED_CAMPAIGN) с товарными или комбинаторными объявлениями либо обычные поисковые кампании, где можно точнее управлять площадками, структурой, минус-словами, ставками и аналитикой.