Как подключить Meta MCP

За последние месяцы AI-агенты добрались и до рекламных кабинетов: вместо того чтобы дёргать Ads Manager руками или писать обёртку над Graph API, всё больше команд подключают LLM напрямую к Marketing API через протокол MCP (подробнее, что такое MCP разбирали в этой статье) . У Meta для этого есть официальный сервер — https://mcp.facebook.com/ads, который можно подключить к Claude (и другим MCP-клиентам) буквально за пять минут.

Но для агентства или ad-tech команды, которая работает не только со своими аккаунтами, а с десятками клиентских кабинетов, есть нюанс: то, что вы подключили MCP и он «просто заработал», не отменяет правил доступа Meta к Marketing API. Если вы хотите не просто дергать чужие кабинеты руками через готовый коннектор, а строить на этом собственный продукт или интеграцию, вам придётся разобраться в уровнях доступа (Access Levels) и пройти App Review. В этой статье — обе части: как подключить MCP Meta и что нужно знать про доступ к чужим рекламным аккаунтам на уровне платформы.

Часть 1. Что такое MCP Meta и как его подключить

Что это вообще такое

MCP Meta Ads — это официальный удалённый MCP-сервер Meta, который даёт LLM-агенту (Claude, и не только) доступ к Marketing API: кампании, группы объявлений, объявления, креативы, кастомные аудитории, товарные каталоги, пиксели и конверсии, инсайты и бенчмарки, поиск по Ads Library. По факту это тонкая обёртка над Graph API Marketing, но с интерфейсом инструментов (tools), которые модель может вызывать напрямую, без написания кода.

Важный момент с точки зрения безопасности: сервер работает через ваш аккаунт Facebook Login и наследует ровно те права, которые есть у подключённого пользователя в его Business Portfolio (Business Manager). Если у вас в портфеле есть клиентские рекламные кабинеты, расшаренные через Business Manager, коннектор получит доступ и к ним — это не отдельная песочница только для «своих» аккаунтов. Именно поэтому в агентской модели к подключению стоит относиться так же серьёзно, как к выдаче доступа новому сотруднику.

Как подключить

Есть два пути — в зависимости от того, появился ли коннектор у вас в каталоге по умолчанию, или его нужно добавлять вручную.

Вариант А — через каталог коннекторов (если уже доступен в организации)

1. Откройте настройки Claude → раздел Connectors. Для Team/Enterprise аккаунтов коннекторы сначала должен разрешить владелец организации в Admin settings → Capabilities — обычные участники команды сами включить незнакомый коннектор не смогут.
2. Найдите в каталоге Meta Ads и нажмите Connect.
3. Пройдите OAuth-флоу: вход через Facebook Login, выбор Business Portfolio и подтверждение прав доступа. На этом шаге стоит внимательно посмотреть, какие именно бизнес-аккаунты и рекламные кабинеты запрашивает доступ — если их несколько, будут перечислены все.

Вариант Б — как custom remote MCP-сервер (если коннектора нет в каталоге)

1. В настройках Claude выберите добавление собственного remote MCP-сервера.
2. Задайте произвольное имя (например, «Meta Ads»).
3. В поле URL укажите официальный адрес сервера Meta: https://mcp.facebook.com/ads.
4. Сохраните — вас перенаправит на авторизацию Meta, дальше процесс идентичен варианту А (выбор портфеля, подтверждение прав, включение в чате).

Требования по тарифу: по опыту сообщества, добавление кастомного MCP-сервера и работа с ним доступны на платных планах Claude (Pro/Max для отдельных пользователей, Team/Enterprise — с включением на уровне организации). Для бесплатного аккаунта такой возможности может не быть.

Частая проблема при подключении. Если вы пробуете подключить сервер через Claude Code CLI, а не через веб/десктоп-интерфейс, можно упереться в ошибку OAuth вида «redirect_uris not registered» — сервер Meta ожидает redirect URI, зарегистрированный для клиентского приложения, и не все клиенты по умолчанию у него зарегистрированы. Если это ваш случай — подключайте коннектор через основной интерфейс Claude (веб или десктоп), а не через CLI, пока проблема не будет закрыта на стороне интеграции.

Что появляется в наборе инструментов

После подключения агент получает доступ к инструментам по нескольким блокам:

• Структура кампаний — создание и обновление кампаний, групп объявлений, объявлений, статусов (активировать/приостановить).
• Креативы — загрузка изображений и видео, создание и обновление креативов, предпросмотр объявлений.
• Аудитории — создание, обновление и удаление кастомных аудиторий, привязка look-alike.
• Каталоги и товарные фиды — управление product catalog, product sets, диагностика фидов.
• Пиксели и конверсии — события, кастомные конверсии, параметры датасетов.
• Аналитика — insights, бенчмарки по индустрии и аукциону, детект аномалий, тренды эффективности.
• Ads Library — поиск объявлений конкурентов.

Важная деталь для безопасности: действия, которые создают или меняют кампании, по умолчанию создают их в статусе «на паузе» — агент не запускает трату бюджета сам, активация остаётся отдельным осознанным шагом. Тем не менее это не отменяет базовую гигиену: включайте коннектор только в тех диалогах, где он реально нужен, и не давайте агенту инструкции вида «просто исправь всё, что найдёшь» без ревью результата — багованный промпт с write-доступом к десяткам клиентских кабинетов может обойтись дорого.

Часть 2. Уровни доступа к Marketing API

Здесь важно разделить две вещи. Использование готового MCP-коннектора Meta — это работа через уже одобренное Meta приложение (сам MCP-сервер), и на этом уровне вам не нужно проходить App Review самостоятельно: вы просто авторизуетесь и работаете в рамках прав, которые Meta уже выдала своему официальному клиенту. App Review и уровни доступа, о которых пойдёт речь дальше, актуальны, если вы (как ad-tech компания) строите собственное приложение или интеграцию поверх Marketing API — свой сервис, бота, дашборд, автоматизацию — а не просто пользуетесь чужим готовым MCP.

Два уровня

Исторически у Marketing API было два уровня доступа — Standard Access и Advanced Access. С 4 мая 2026 года Meta переименовала их для ясности:

Вместе с переименованием Meta снизила порог входа: раньше для получения повышенного доступа приложение должно было делать от 1500 вызовов Marketing API за 30 дней с ошибкой не выше 10%; сейчас порог — от 500 вызовов за последние 15 дней при доле ошибок не выше 15%. Требования теперь видны прямо в App Dashboard, и записывать скринкаст работы приложения (как раньше) больше не нужно.

Практический вывод для ad-tech команды: если вы разрабатываете внутренний инструмент, который работает только с вашими собственными рекламными кабинетами (или кабинетами, куда вас как пользователя явно добавили админом), Limited Access может быть вполне достаточен на старте. Но как только вы хотите предлагать интеграцию клиентам — то есть работать с кабинетами, которыми управляют другие люди/бизнесы, а не пользователи вашего приложения — вам нужен Full Access, а значит, и App Review.

Часть 3. App Review для работы с чужими аккаунтами

Какие разрешения требуют ревью

Ключевые разрешения для работы с рекламой почти всегда требуют прохождения App Review, если вы хотите использовать их не только с тестовыми пользователями:

• ads_management — чтение и управление кампаниями (создание, редактирование, запуск/остановка). Официальная документация Meta прямо говорит: доступ к «живым» данным требует успешного прохождения App Review.
• ads_read — доступ только на чтение, для отчётности и аналитики.
• business_management — управление активами Business Manager: клиентами, рекламными кабинетами, страницами, каталогами.

Без ревью эти разрешения работают только в «песочнице» — для пользователей, у которых есть роль в вашем приложении (администратор, разработчик, тестировщик). То есть вы можете спокойно разрабатывать и тестировать интеграцию на своих аккаунтах, но не сможете подключить к ней реального внешнего клиента, пока не пройдёте ревью.

Business Verification — обязательный шаг до ревью

Прежде чем подавать заявку на App Review для рекламных разрешений, Meta требует пройти Business Verification — подтверждение юридического лица, стоящего за приложением (документы компании, подтверждение домена и т.д.). Без этого заявку на ads_management и подобные разрешения просто не примут к рассмотрению. Дополнительно Meta оставляет за собой право потребовать подписания отдельных договоров (data use agreements) в зависимости от того, какие данные и в каком объёме планирует обрабатывать приложение.

Как проходит сам App Review

1. Подготовка use case. Нужно чётко описать, зачем приложению конкретное разрешение и как именно оно используется в продукте — общие формулировки «для управления рекламой» отклоняют.
2. Доступность приложения для тестирования. Ревьюер должен иметь возможность реально протестировать заявленный сценарий в вашем интерфейсе. Недоступное или нерабочее приложение — стопроцентный повод для отказа.
3. Режим Live. Приложение должно быть переведено из Development в Live mode — в деве расширенные разрешения не выдаются.
4. Подтверждение через использование. Как было выше — после того, как приложение отработало на Limited Access и набрало нужную статистику по вызовам (сейчас: 500+ вызовов Marketing API за 15 дней, ошибок не больше 15%), можно подавать заявку на повышение до Full Access.
5. Решение Meta. После одобрения разрешение становится доступно для запроса у любого пользователя, а не только у тех, кто явно привязан к приложению — то есть у ваших клиентов.

Как это работает для агентства на практике

Если агентство управляет рекламой десятков клиентов, типичная схема выглядит так:

• Клиент через Business Manager расшаривает свой рекламный кабинет вашему Business Portfolio (как партнёру) или создаёт System User с нужной ролью.
• Это даёт вам ручной доступ к кабинету в интерфейсе Ads Manager и через API — но объём и стабильность этого доступа на уровне API всё ещё регулируются вашим App Review статусом, если вы работаете через собственное приложение, а не через ручной интерфейс Meta.
• Если объём кабинетов и запросов растёт (типичная ситуация для агентства с десятками клиентов), Limited Access довольно быстро упирается в лимиты — отсюда необходимость Full Access и, соответственно, ревью и верификации бизнеса.
• Если же вы просто пользуетесь официальным MCP-коннектором Meta (Часть 1) от имени сотрудника, у которого есть доступ к клиентским кабинетам через Business Manager, — вы работаете в рамках уже одобренного приложения Meta и своего личного доступа, без необходимости проходить ревью самим. Ограничение здесь другое: коннектор увидит и потенциально сможет менять все аккаунты, которые доступны подключённому сотруднику, а не только один нужный.

Коротко: что делать по шагам

1. Для повседневной работы с рекламой через AI-агента — подключите официальный MCP Meta (через каталог коннекторов Claude или как custom remote MCP-сервер https://mcp.facebook.com/ads), пройдите OAuth и включите коннектор в нужном чате.
2. Если вы просто пользуетесь этим коннектором в рамках своего личного/агентского доступа к клиентским кабинетам — отдельного App Review проходить не нужно, но стоит трезво оценивать, какие аккаунты станут доступны агенту вместе с вашим доступом.
3. Если вы разрабатываете собственную интеграцию или продукт поверх Marketing API для работы с внешними (клиентскими) аккаунтами — закладывайте время на Business Verification и App Review для ads_management, ads_read, business_management, и планируйте архитектуру с учётом лимитов Limited Access, пока не наберёте статистику для перехода на Full Access.