MCP в SMM-панели: подключение ИИ-ассистента к аккаунту

MCP (Model Context Protocol) это открытый протокол, по которому ИИ-ассистент подключается к внешнему сервису и работает с ним не текстом, а набором инструментов, а применительно к Panel Follows это означает, что ассистент может искать услуги в каталоге, считать стоимость, оформлять заказы и смотреть их статусы прямо в вашем аккаунте. Никаких копий данных, никакой отдельной интеграции: ассистент вызывает те же операции, что и панель, только от вашего имени и в пределах прав, которые вы ему выдали.

Практически это выглядит так. Вы пишете в чат: «Найди мне самые дешёвые просмотры для TikTok с рефиллом, посчитай тысячу штук и скажи, хватит ли баланса». Ассистент вызывает поиск по каталогу, читает карточку услуги, вызывает предварительный расчёт стоимости, показывает вам сумму и остаток баланса после списания, и только после вашего явного согласия оформляет заказ. Всё, что он делает, записывается в журнал, а любое подключение вы можете разорвать одной кнопкой.

Этот материал разбирает механику целиком: чем MCP-сервер отличается от обычного API реселлера, какие 18 инструментов открыты клиентскому ассистенту, как проходит подключение через OAuth 2.1 без копирования ключей, что именно отключает режим «Только просмотр», сколько живут токены, что попадает в журнал аудита и какие ошибки встречаются чаще всего. Названия инструментов, параметров и экранов приведены ровно так, как они есть в системе, поэтому текст можно читать и одновременно проверять на своём аккаунте.

Сразу одна честная оговорка. MCP не делает продвижение умнее и не добавляет к услугам никаких гарантий. Это способ управления заказами, а не новый вид трафика. Возможность рефилла и отмены по-прежнему зависит от конкретной услуги, а не от того, оформили вы заказ руками или через ассистента.

Что такое MCP и зачем он нужен SMM-панели?

MCP это стандартный способ дать языковой модели доступ к внешней системе через описанный список действий. Сервер публикует свои инструменты (у каждого есть имя, описание и схема параметров), клиент запрашивает этот список, а модель выбирает нужный инструмент и вызывает его с конкретными аргументами. Ответ возвращается модели обратно, и она продолжает рассуждать уже с реальными данными на руках.

До появления такого протокола любая интеграция с ИИ была самоделкой. Каждый клиент описывал функции по-своему, каждый сервис писал собственный адаптер, а перенести настройку с одного ассистента на другой было невозможно. MCP убирает эту работу: сервер описывает себя один раз, а любой совместимый клиент подключается к нему одинаково.

Для SMM-панели ценность конкретная и приземлённая. Каталог у панели большой и живой, в нём тысячи позиций, десятки категорий и разные типы услуг с разными наборами полей. Человек тратит время на то, чтобы отфильтровать список, сравнить пять похожих услуг, посмотреть минимумы и максимумы, прикинуть сумму. Ассистент делает эту черновую часть за несколько секунд, а решение о списании денег всё равно остаётся за вами.

Второй сценарий это операционка. Если вы ведёте не один аккаунт, а десяток клиентских, вопросы вроде «какие заказы за неделю ушли в частичное выполнение», «где остаток не добрался до нуля», «по каким выполненным заказам можно запросить рефилл» отнимают заметную часть дня. Через MCP это один вопрос в чате, а не пятнадцать кликов по фильтрам. Про операционную нагрузку в агентстве мы отдельно писали в материале масштабирование SMM-агентства.

Третий сценарий это обучение. Новичок, который впервые видит каталог, обычно не понимает, чем услуга с пометкой рефилла отличается от услуги без неё и почему у одной позиции поле количества редактируется, а у другой нет. Ассистент, который читает карточку услуги напрямую из панели, объясняет это на конкретном примере, а не общими словами. Базовую механику панели без ИИ мы разобрали в руководстве как пользоваться Panel Follows.

Важно понимать границу. MCP это транспорт и набор действий, а не автономный робот. Модель ничего не делает по собственной инициативе: она отвечает на ваш запрос в чате и вызывает инструменты внутри этого ответа. Если вы не пишете ассистенту, он не оформляет заказы сам по себе.

Чем MCP отличается от обычного API реселлера?

Обычный API реселлера рассчитан на программиста: вы читаете документацию, пишете код, обрабатываете ошибки, деплоите интеграцию. MCP рассчитан на человека, который просто разговаривает с ассистентом, а весь слой «прочитать документацию и собрать запрос» берёт на себя модель.

Разница видна в трёх местах. Первое: описание. В API вы сами ищете, какие параметры принимает создание заказа для услуги с комментариями. В MCP инструмент get_service возвращает список полей заказа (fields) для конкретной услуги, и модель читает его прямо перед вызовом, а не угадывает по памяти. Второе: ошибки. В API ошибка это код, который вы обрабатываете в коде. В MCP ошибка инструмента возвращается моделью как читаемый текст с признаком isError: true, поэтому модель может прочитать причину и исправиться сама, не роняя диалог. Третье: подключение. API требует скопировать ключ и вставить его в конфигурацию, MCP умеет подключаться через браузерное подтверждение, вообще без копирования секретов.

При этом под капотом никакой магии нет. Инструменты пользовательского MCP-сервера это зеркало эндпоинтов API v3: имена параметров совпадают буквально, включая service, link, quantity, runs, interval, comments, username, posts, min, max, usernames, hashtag, hashtags, answer_number, groups, keywords и media. Если вы уже знаете документацию API, вы знаете и MCP: это тот же набор операций, поданный в другом виде.

Признак	API v3	MCP
Кому адресован	разработчику, пишущему код	человеку, который пишет ассистенту
Формат обращения	HTTP-запросы к эндпоинтам	JSON-RPC вызовы инструментов
Как узнать поля заказа	из документации	ассистент читает get_service перед вызовом
Подключение	скопировать ключ pf_live_	браузерное подтверждение или тот же ключ
Ограничение прав	ключ всегда полный	OAuth-подключение можно сделать только для чтения
Обработка ошибок	вы пишете код	модель читает текст ошибки и корректирует вызов
Лимит запросов	600 в минуту на аккаунт	тот же лимит, счётчик общий

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

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

В панели два MCP-сервера: какой из них для кого?

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

	Пользовательский сервер	Управляющий сервер
Адрес	POST /api/mcp/user	POST /api/mcp
Кто подключается	клиент панели	владелец панели
Аутентификация	токен OAuth 2.1 либо API-ключ аккаунта	один секретный ключ (MCP_SECRET)
Область прав	только свой аккаунт, 18 инструментов	вся панель, 57 инструментов
Журнал аудита	aiAuditLog, поле пользователя заполнено	aiAuditLog, поле пользователя пустое

Оба сервера построены на одном ядре транспорта, поэтому формат запросов, поведение при ошибках и правила работы с протоколом у них одинаковые. Отличаются они только тем, кого пускают и что дают делать.

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

Различие важно ещё и с точки зрения безопасности. Пользовательский токен физически не может дотянуться до чужих данных: сервер получает идентификатор аккаунта из токена, а не из аргументов вызова, поэтому попросить ассистента «посмотреть заказы другого пользователя» невозможно, такого параметра просто нет ни в одном инструменте. Аналогично управляющий секрет не выдаётся клиентам ни при каких условиях и живёт только в переменных окружения сервера.

Если управляющий секрет не задан, эндпоинт /api/mcp полностью закрыт и отвечает кодом 503. То есть по умолчанию административная поверхность выключена, а не открыта.

Как устроен транспорт: почему работает только POST?

Пользовательский MCP-сервер использует Streamable HTTP в режиме без состояния: каждый вызов это самостоятельный POST-запрос с телом в формате JSON-RPC 2.0, идентификатор сессии на сервере не хранится. Такой режим удобен тем, что не требует держать соединение и переживает перезапуски без потери контекста.

Отсюда следует главное практическое правило: потока SSE у сервера нет. Если вы откроете адрес https://panelfollows.com/api/mcp/user в браузере обычным переходом, то есть GET-запросом, вы получите HTTP 405 и сообщение о том, что SSE не поддерживается и для JSON-RPC нужно использовать POST. Это не поломка и не признак того, что сервер лежит: браузер просто отправил не тот метод.

Поддерживаемые методы протокола перечислены ниже.

Метод	Что делает
initialize	рукопожатие, согласование версии протокола
tools/list	список инструментов со схемами параметров
tools/call	вызов конкретного инструмента
prompts/list	список готовых команд
prompts/get	получение текста готовой команды
ping	проверка доступности
resources/list	отвечает пустым списком
resources/templates/list	отвечает пустым списком

Родная версия протокола это 2025-06-18. Для совместимости сервер принимает и более ранние 2025-03-26 и 2024-11-05: версия согласовывается на шаге initialize, поэтому клиент постарше подключится без правок конфигурации.

Ещё несколько деталей поведения, которые полезно знать заранее:

1. Пакетные запросы поддерживаются. Клиент может отправить массив JSON-RPC вызовов одним телом, и сервер обработает их вместе.
2. Тело только из уведомлений возвращает HTTP 202 без содержимого. Это нормальный ответ, а не пустой сбой.
3. Ошибка инструмента не является ошибкой протокола. Она приходит текстом с флагом isError: true, чтобы модель прочитала причину и попробовала иначе, а не оборвала диалог.
4. Вывод инструмента обрезается на 100 000 символов. Огромные выборки не забьют контекст модели целиком.
5. Каждый инструмент помечен подсказками readOnlyHint и destructiveHint. Клиент видит по списку, какой вызов только читает, а какой изменяет данные, и может спросить у вас подтверждение перед вторым.

Последний пункт особенно важен: часть клиентов показывает отдельное окно подтверждения именно для инструментов с пометкой разрушающего действия. То есть даже при полном доступе у вас остаётся ещё один барьер на уровне самого клиента.

Какие 18 инструментов доступны ассистенту?

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

Область	Инструменты
Аккаунт	get_account
Каталог	list_platforms, list_categories, search_services, get_service
Заказы	preview_order, create_order, create_orders_bulk, list_orders, get_order, cancel_order, refill_order
Рефиллы	list_refills, get_refill
Автоматизация	list_events, list_webhooks, create_webhook, delete_webhook

Что важно знать про каждый из них по существу.

get_account возвращает идентификатор аккаунта, электронную почту, доступный баланс в долларах и текущий лимит запросов. Это первое, что ассистент обычно вызывает, когда вы спрашиваете «сколько у меня денег».

list_platforms и list_categories дают структуру каталога: список площадок и список категорий. Они нужны модели, чтобы сузить поиск, а не перебирать тысячи позиций подряд.

search_services это рабочая лошадка. Фильтры: search (текстовый запрос), platform, category, type, refill, cancel, dripfeed, min_rate и max_rate. Размер страницы по умолчанию 20, максимум 50. То есть запрос «покажи услуги для YouTube дешевле определённой цены и только с поддержкой рефилла» превращается в один вызов с тремя фильтрами.

get_service возвращает карточку конкретной услуги: цену, минимум и максимум, поддержку рефилла, отмены и постепенной подачи, среднее время выполнения и, что важнее всего, список полей заказа в поле fields. Именно поэтому модель не выдумывает, какие поля обязательны для услуги с голосованием или упоминаниями: она их читает.

preview_order проверяет заказ не оформляя его. В ответе приходят charge (сумма списания), balance_after (остаток после списания) и sufficient_balance (хватает ли денег). Это ключевой инструмент всей схемы: он позволяет назвать вам точную сумму до того, как что-либо произойдёт.

create_order создаёт настоящий заказ, тратит реальные деньги и не отменяется обратной командой. create_orders_bulk делает то же самое пачкой, максимум 50 заказов за один вызов. Позиции обрабатываются по очереди, и если одна не прошла, остальные всё равно оформляются: каждая возвращает свой результат.

list_orders отдаёт список заказов с фильтром по статусу: pending, in_progress, completed, partial, canceled, refunded, failed. По умолчанию 20 записей, максимум 100. get_order возвращает один заказ подробно.

cancel_order работает только если услуга поддерживает отмену (признак features.cancel) и заказ ещё не завершён. Если поддержки нет, инструмент вернёт cancel_not_supported, и ассистент честно скажет об этом, а не будет обещать невозможное.

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

list_refills и get_refill показывают историю запросов на рефилл и состояние конкретного запроса.

list_events, list_webhooks, create_webhook и delete_webhook относятся к автоматизации, им отведён отдельный раздел ниже.

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

Чем отличаются инструменты чтения и инструменты записи?

Из 18 инструментов 12 только читают и 6 изменяют данные. Разделение это не косметика: от него зависит, что покажет клиент в окне подтверждения и что вообще увидит ассистент, подключённый в режиме просмотра.

Категория	Инструменты	Что происходит при вызове
Только чтение (12)	get_account, list_platforms, list_categories, search_services, get_service, preview_order, list_orders, get_order, list_refills, get_refill, list_events, list_webhooks	данные не меняются, деньги не списываются
Запись, не разрушающая (2)	refill_order, create_webhook	создают запрос или подписку, баланс не трогают
Запись, разрушающая (4)	create_order, create_orders_bulk, cancel_order, delete_webhook	тратят деньги, отменяют заказ или удаляют подписку

Обратите внимание, что preview_order находится в списке чтения. Это сделано намеренно: расчёт стоимости не создаёт заказ, не резервирует деньги и ничего не меняет. Поэтому ассистент может свободно считать варианты, сравнивать пять услуг по цене и показывать вам таблицу, не рискуя списать ни цента.

refill_order отнесён к записи, но не к разрушающим действиям, потому что рефилл бесплатный и в худшем случае просто не даст результата. create_webhook тоже создаёт объект, но не тратит деньги.

Четыре разрушающих инструмента это те, из-за которых стоит читать сообщения ассистента внимательно. create_order и create_orders_bulk тратят баланс, cancel_order прекращает работу по заказу, delete_webhook удаляет подписку вместе с ожидающими доставками.

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

Как подключить ИИ-ассистента к панели за три шага?

Страница подключения находится в кабинете и называется «AI Ассистент», адрес /ru/dashboard/mcp. Она состоит из четырёх блоков: адрес подключения и три шага, примеры настройки под разные клиенты, перечень того, что ассистент может и чего не может, и список уже подключённых ассистентов.

Базовая схема подключения выглядит так:

1. Скопируйте адрес подключения. Для основной панели это https://panelfollows.com/api/mcp/user. Клиенты дочерних панелей используют адрес своего домена, об этом отдельный раздел ниже.
2. Добавьте сервер в своего ИИ-клиента. Способ зависит от клиента: где-то это команда в терминале, где-то строка в файле настроек.
3. Подтвердите доступ в браузере. Клиент откроет страницу подтверждения панели, вы войдёте (если ещё не вошли) и нажмёте кнопку подтверждения. Ключи копировать не нужно.

Команда для клиента с поддержкой HTTP-транспорта выглядит так:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user

Клиенты, которые настраиваются файлом конфигурации, принимают такой блок:

{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }

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

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

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
  --header "Authorization: Bearer pf_live_..."

Проверить, что сервер отвечает, можно и без ИИ-клиента, обычным запросом:

curl -s https://panelfollows.com/api/mcp/user \
  -H "Authorization: Bearer pf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

В ответ придёт список инструментов со схемами параметров. Если он пришёл, значит транспорт, ключ и права в порядке, и дальше проблема (если она есть) уже на стороне клиента.

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

Что именно происходит в OAuth 2.1 в фоновом режиме?

OAuth 2.1 это то, что позволяет подключить ассистента без копирования секретов. Пользователь видит только браузерное окно подтверждения, но за ним стоит цепочка из шести шагов, полностью соответствующая современным спецификациям.

1. Клиент делает запрос без удостоверения и получает 401. В ответе приходит заголовок WWW-Authenticate: Bearer error="...", resource_metadata=".../.well-known/oauth-protected-resource/api/mcp/user". Это механизм из RFC 9728: сервер сам подсказывает, где лежит описание защиты.
2. Клиент читает метаданные. Сначала /.well-known/oauth-protected-resource, оттуда попадает на /.well-known/oauth-authorization-server (RFC 8414) и узнаёт адреса всех эндпоинтов авторизации.
3. Клиент регистрируется динамически. Запрос POST /api/mcp/oauth/register (RFC 7591) создаёт публичного клиента без собственного секрета: подлинность подтверждается механизмом PKCE. Регистрация ограничена десятью попытками в час с одного IP-адреса.
4. Открывается браузер. Клиент ведёт вас на GET /api/mcp/oauth/authorize, а тот перенаправляет на собственный экран подтверждения панели по адресу /mcp/connect. Если вы не авторизованы, вас сначала отправят на форму входа и после успешного входа вернут на тот же экран подтверждения.
5. Вы подтверждаете доступ. При желании отмечаете флажок «только просмотр». После нажатия кнопки подтверждения браузер возвращает клиента обратно с одноразовым кодом.
6. Код меняется на токен. Запрос POST /api/mcp/oauth/token обменивает код на access-токен и refresh-токен. PKCE в варианте S256 обязателен, вариант plain не принимается вовсе: это требование OAuth 2.1.

Несколько технических подробностей, которые объясняют, почему что-то может не сработать:

• Верификатор PKCE должен быть длиной от 43 до 128 символов. Клиенты генерируют его сами, но если вы пишете свою интеграцию, это ограничение придётся соблюсти.
• В списке зарегистрированных адресов возврата (redirect_uris) допускаются https-адреса, петлевые http-адреса (127.0.0.1 и localhost) и собственные схемы клиентов вроде cursor:// или vscode://. Обычный http на внешний адрес отклоняется.
• Адрес возврата должен совпадать с зарегистрированным. Единственная поблажка это номер порта у петлевого адреса, как предписывает RFC 8252 для настольных приложений.
• Документ обнаружения сообщает клиенту точный набор возможностей: response_types_supported: ["code"], grant_types_supported: ["authorization_code", "refresh_token"], token_endpoint_auth_methods_supported: ["none"], code_challenge_methods_supported: ["S256"], authorization_response_iss_parameter_supported: true (RFC 9207) и resource_indicators_supported: true (RFC 8707).
• Все адреса в метаданных строятся из источника самого запроса. Это значит, что клиент дочерней панели, подключающийся со своего домена, увидит в метаданных именно свой домен, и адрес основной панели ему нигде не показывается.

Отозвать доступ можно двумя путями: запросом POST /api/mcp/oauth/revoke со стороны клиента либо одной кнопкой в кабинете. Второй способ надёжнее, потому что не зависит от того, работает клиент или нет.

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

Когда разумнее подключиться по API-ключу?

Не каждый клиент умеет открывать браузер и проходить OAuth. Некоторые инструменты просто отправляют заголовок и ждут ответа. Для них предусмотрен второй путь: подключение по ключу.

Сервер принимает в заголовке Authorization: Bearer три вида значений:

Вид значения	Префикс	Откуда берётся
Токен OAuth	pf_mcp_	выдаётся автоматически при браузерном подтверждении
Ключ API v3	pf_live_	выпускается вами на странице «API» в кабинете
Реселлерский ключ прежнего формата	64 шестнадцатеричных символа	ключ старой интеграции реселлера

Заголовок X-Api-Key тоже принимается, если вашему клиенту так удобнее. Какой именно способ использован, сервер определяет исключительно по префиксу значения, никаких дополнительных полей указывать не нужно.

Здесь есть один момент, который стоит осознать до подключения. Подключение по ключу всегда полноправное. Ограничение прав до режима просмотра существует только в OAuth: у ключа нет области действия, он даёт весь набор из 18 инструментов. Если вам важно ограничить ассистента чтением, единственный рабочий путь это браузерное подтверждение с отметкой «только просмотр».

Когда какой путь уместнее:

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

И общая гигиена: ключ это пароль. Его нельзя вставлять в общие чаты, в публичные репозитории и в конфигурации, которые синхронизируются между людьми. Токен OAuth в этом смысле безопаснее, потому что живёт ограниченное время и привязан к конкретному зарегистрированному клиенту. Если ключ утёк, перевыпустите его на странице «API»: старый мгновенно перестанет работать.

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

Что вы видите на экране подтверждения?

Экран подтверждения это единственное место, где вы принимаете решение о доступе. Он открывается по адресу /mcp/connect, и попасть туда осмысленно можно только из потока, который начал ИИ-клиент: сама по себе эта страница ничего не подтверждает, а поисковым системам она закрыта.

На экране показаны:

• Название клиента, который просит доступ. Это то имя, которое клиент сообщил при динамической регистрации.
• Адрес электронной почты аккаунта, к которому будет привязано подключение. Если почта не та, которую вы ожидали, значит вы вошли не в тот аккаунт.
• Адрес возврата, куда браузер отправит результат. Это полезно сверить: он должен вести на ваш локальный клиент или на его собственную схему, а не на посторонний сайт.
• Список запрашиваемых разрешений простым языком.
• Флажок «выдать разрешение только на просмотр».
• Две кнопки: «Подтвердить подключение» и «Отклонить».

Что стоит проверять глазами каждый раз. Первое: имя клиента должно соответствовать программе, которую вы прямо сейчас настраиваете. Если вы не начинали подключение, а экран открылся, ничего не подтверждайте. Второе: адрес возврата. Легальный клиент возвращает вас на петлевой адрес (127.0.0.1 с каким-то портом) или на собственную схему. Третье: почта аккаунта.

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

Одноразовый код, который выдаётся после подтверждения, живёт 10 минут. Если вы подтвердили доступ, ушли пить кофе и вернулись через полчаса, клиент, скорее всего, уже получит ответ о просроченном запросе. Ничего страшного не произошло: запустите подключение заново из клиента, весь путь займёт меньше минуты.

И последнее: подтверждение это не подписка и не платёж. Само по себе подключение ассистента ничего не стоит и никак не влияет на баланс. Деньги списываются только за реальные заказы, ровно как при работе руками.

Что на самом деле отключает режим «Только просмотр»?

В системе всего две области прав: account:read и account:write. Если клиент при регистрации ничего конкретного не просит, ему выдаются обе. Если вы отмечаете на экране подтверждения флажок ограничения, токену достаётся только account:read.

Дальше самое интересное, потому что реализовано это жёстче, чем можно ожидать. Сервер не просто отклоняет попытки записи. Он вообще не показывает инструменты записи такому подключению: список инструментов фильтруется, и в ответе tools/list остаются только 12 читающих. Ассистент физически не видит, что существует create_order, поэтому не может ни вызвать его, ни пообещать вам заказ.

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

Что доступно	Полный доступ	Только просмотр
Смотреть баланс и данные аккаунта	да	да
Искать услуги и читать карточки	да	да
Считать стоимость через preview_order	да	да
Смотреть заказы, рефиллы и события	да	да
Оформлять заказы	да	нет, инструмента нет в списке
Отменять заказы	да	нет, инструмента нет в списке
Запрашивать рефилл	да	нет, инструмента нет в списке
Создавать и удалять вебхуки	да	нет, инструмента нет в списке

Незнакомые области прав, которые клиент может запросить по привычке (openid, profile, email), молча отбрасываются. Панель не хранит и не выдаёт ничего из профиля сверх того, что нужно инструментам.

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

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

В каком порядке ассистент оформляет заказ?

У сервера есть встроенная инструкция, которую модель получает при подключении. В ней прописан обязательный порядок действий перед созданием заказа, и он не оставляет места для угадывания.

1. Найти услугу. Вызов search_services с подходящими фильтрами, из результата берётся идентификатор услуги.
2. Прочитать карточку. Вызов get_service: минимум и максимум, поддержка рефилла и отмены, среднее время выполнения, обязательные поля заказа.
3. Посчитать сумму. Вызов preview_order. Модель обязана назвать вам charge и сказать, хватает ли баланса (sufficient_balance).
4. Получить явное согласие. Не намёк, не «ну давай», а прямое подтверждение от вас.
5. Оформить заказ. Вызов create_order и сообщение вам номера заказа.

Как это выглядит в переписке (пример условный, цифры вымышленные, реальные смотрите в панели):

Вы: нужно 2000 просмотров на ролик в TikTok, ссылка такая-то, желательно с рефиллом

Ассистент: нашёл три подходящие услуги. Беру ту, у которой есть рефилл и минимум ниже вашего количества. По карточке: минимум 100, максимум 100 000, среднее время выполнения указано в панели, отмена поддерживается. Считаю: списание составит столько-то, после списания на балансе останется столько-то, средств достаточно. Оформлять?

Вы: да

Ассистент: заказ создан, номер такой-то. Статус сейчас «в ожидании», проверить можно через список заказов.

Обратите внимание на два места, где схема защищает вас от лишних трат. Во-первых, шаг с preview_order обязателен, поэтому вы всегда видите сумму до списания, а не после. Во-вторых, шаг подтверждения отделён от шага заказа: между «посчитал» и «оформил» стоит ваше слово.

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

Что касается ошибок, инструкция тоже однозначна: коды ошибок фиксированные (например, insufficient_balance или quantity_out_of_range), а текст сообщения приходит на вашем языке. Модель обязана передать сообщение как есть и не выдумывать обходных путей. Если баланса не хватает, правильный ответ это «не хватает столько-то», а не «попробую оформить половину и посмотрим».

Как читать цену: разница между per_1000 и per_order

Это место, где ошибаются и люди, и модели, поэтому оно вынесено в инструкцию сервера отдельным пунктом. В ответе с ценой есть поле pricing.unit, и у него два значения.

Значение pricing.unit	Что означает цена	Как считается заказ
per_1000	цена за 1000 единиц	количество делится на 1000 и умножается на цену
per_order	цена за весь пакет целиком	количество не влияет, платится вся сумма пакета

Ошибка выглядит так. Услуга стоит, условно, 22 доллара, и у неё pricing.unit равен per_order. Если прочитать это как «22 доллара за тысячу штук», получится оценка в 0,022 доллара за штуку, то есть в тысячу раз меньше реальной цены. Модель, не проверившая единицу измерения, назовёт вам цифру, которая расходится с реальностью на три порядка.

Как понять, что перед вами пакет, не заглядывая в поля: у таких услуг максимальное количество обычно равно единице, а поле количества в интерфейсе панели вообще не редактируется. В самой панели плитка всё равно подписана как цена за 1000, потому что подпись общая для всего каталога, и это давняя ловушка ручного заказа. Мы разбирали её подробно в руководстве как пользоваться Panel Follows.

Хорошая новость в том, что в схеме MCP эта ловушка закрывается сама собой. Модель обязана вызвать preview_order перед заказом, а preview_order возвращает уже посчитанную сумму charge, независимо от единицы измерения. То есть даже если модель неправильно рассуждала про цену вслух, итоговая сумма приходит от сервера, а не из её арифметики.

Практический совет: если ассистент называет вам сумму, но не упоминает, что делал предварительный расчёт, попросите его посчитать явно. Формулировка «посчитай через предварительный расчёт и покажи сумму списания и остаток» заставляет вызвать нужный инструмент.

Отдельно про услуги с комментариями. Для них параметр количества не передаётся вообще: количество определяется числом строк в списке комментариев, по одному комментарию на строку. Если попросить ассистента «сделай 50 комментариев», он должен сгенерировать или запросить у вас 50 строк, а не подставить число в поле количества.

Массовые заказы, постепенная подача и специальные типы услуг

Пакетное оформление делается инструментом create_orders_bulk. Ограничение: не более 50 заказов за один вызов. Позиции обрабатываются последовательно, и это важно для понимания результата: если третья позиция не прошла проверку, первые две уже оформлены, а остальные продолжат оформляться. Каждая позиция возвращает свой собственный результат, поэтому в ответе вы видите, что прошло, а что нет.

Такая семантика удобна для реальной работы (не рушится весь пакет из-за одной опечатки в ссылке), но требует внимания: частично исполненный пакет это норма, а не сбой. Если ассистент сообщает «оформлено 47 из 50», значит три позиции надо разбирать отдельно, а не пересылать весь список заново, иначе вы оплатите 47 заказов дважды.

Постепенная подача передаётся параметрами runs и interval, ровно как в API. Смысл тот же, что и в интерфейсе панели: заказ делится на несколько партий и доставляется с интервалом. И ключевая особенность здесь та же самая: количество указывается на одну партию, а не на весь заказ. Общий объём это количество, умноженное на число партий, и оплата считается от общего объёма. Разница между «1000 в десять партий» и «1000 всего» это разница в десять раз по деньгам.

Поскольку модель обязана вызывать предварительный расчёт, у вас есть страховка: сумма из preview_order уже учитывает партии. Но проговорить это вслух всё равно стоит: формулируйте задачу как «всего 5000, разбей на 5 партий», а не «1000 по 5 раз», и просите ассистента подтвердить итоговый объём перед оформлением. Что даёт и чего не даёт растянутая доставка, разобрано в материале постепенная подача и автоуслуги.

Специальные типы услуг работают через дополнительные параметры с теми же именами, что и поля формы заказа:

Параметр	Для чего
comments	список комментариев, по одному на строку
username	целевое имя пользователя или владелец, без символа @
usernames	список имён для упоминаний по своему списку
hashtag, hashtags	хэштег или список хэштегов для соответствующих типов
answer_number	номер варианта в услугах голосования
groups	список групп для приглашений
keywords	ключевые слова для SEO-услуг
media	ссылка на медиа для упоминаний по лайкнувшим
posts, min, max	параметры услуг типа подписок

Модель не угадывает, какие из них нужны: get_service возвращает список обязательных полей fields для конкретной услуги, и правильно работающий ассистент сначала читает его, а потом спрашивает у вас недостающее. Если ассистент пытается оформить заказ, не спросив, например, номер варианта для голосования, это признак того, что он пропустил шаг чтения карточки. Попросите его перечитать услугу.

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

Чего ассистент сделать не может?

Границы у клиентского MCP-сервера жёсткие, и они заданы не инструкцией, а самим набором инструментов: чего нет в списке, того сделать нельзя.

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

Ассистент не может вывести деньги. Никаких операций вывода в наборе нет вовсе.

Ассистент не может изменить цены. Наценки, множители и прайс это административная область, к которой клиентский сервер отношения не имеет.

Ассистент не может открыть тикет в поддержку. Обращения создаются только вами через раздел поддержки.

Ассистент не может увидеть ваш пароль. Пароль не хранится в виде, пригодном для чтения, и не выдаётся ни одному инструменту. Токен доступа тоже не даёт доступа к паролю.

Ассистент не может дотянуться до чужого аккаунта. Идентификатор аккаунта берётся из токена, а не из аргументов вызова. Параметра «чужой пользователь» нет ни в одном из 18 инструментов.

Ассистент не может отменить заказ, если услуга этого не поддерживает. Инструмент вернёт cancel_not_supported. Это свойство услуги, а не настройка панели.

Ассистент не может запросить рефилл по незавершённому заказу или по услуге без гарантии рефилла. Правило то же самое, что и в интерфейсе.

Формулировки на самой странице подключения звучат коротко и по делу: ассистент «ищет услуги, считает цену, показывает ваши заказы и баланс»; «оформляет заказы, отменяет их, создаёт запросы на рефилл» и «просит у вас подтверждение перед оформлением заказа»; и при этом «не может пополнить баланс, вывести деньги, увидеть ваш пароль и получить доступ к другим аккаунтам».

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

Безопасность: пароль, токены и сроки их жизни

Все секреты в системе устроены одинаково: 32 случайных байта (256 бит), закодированные в base64url, с понятным префиксом в начале. По префиксу видно, что за секрет перед вами, и это же позволяет серверу выбрать правильный путь проверки.

Секрет	Префикс	Срок жизни
Код авторизации	pf_mca_	10 минут, одноразовый
Токен доступа	pf_mcp_	8 часов
Токен обновления	pf_mcr_	90 дней, меняется при каждом использовании
Идентификатор клиента	mcpc_	бессрочно
Ключ API v3	pf_live_	до отзыва

Главное свойство: в базе данных хранится только отпечаток HMAC-SHA256, открытый текст не сохраняется нигде. Ключ для отпечатка (pepper) берётся из отдельной серверной переменной, а при её отсутствии выводится из главного секрета приложения. Практический смысл в том, что даже полный доступ к таблице токенов не позволяет восстановить сами токены.

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

Третье свойство это ротация. Токен обновления не постоянный: при каждом использовании выдаётся новый, а старый становится недействительным. Клиент этим занимается сам, и вам ничего делать не нужно, пока всё работает.

Что это значит на практике для обычного пользователя:

1. Токен доступа живёт 8 часов. Через 8 часов клиент сам обновит его по токену обновления, и вы этого не заметите.
2. Если клиент долго не использовался (больше 90 дней) или токен обновления был отозван, подключение придётся пройти заново. Это одна минута.
3. Отзыв подключения из кабинета работает мгновенно и не зависит от состояния клиента.
4. Пароль от аккаунта в этой схеме не участвует ни на одном шаге и никуда не передаётся.

И общее правило гигиены, которое стоит соблюдать независимо от MCP: включите двухфакторную аутентификацию на аккаунте. Она защищает вход в кабинет, а значит и сам экран подтверждения подключений. Инструкция по включению есть в разделе про аккаунт в руководстве как пользоваться Panel Follows.

Что записывает журнал аудита при каждом вызове?

Каждый вызов инструмента попадает в таблицу журнала aiAuditLog. Это не опция и не настройка: запись идёт всегда, для обоих серверов, и именно она позволяет потом ответить на вопрос «этот заказ оформил я руками или ассистент».

В записи сохраняются:

Поле записи	Что в нём
Клиент	строка User-Agent, по которой видно программу
Аккаунт	идентификатор пользователя (для управляющего сервера пусто)
Инструмент	имя вызванного инструмента
Аргументы	параметры вызова в формате JSON
Результат	ответ инструмента (для читающих инструментов не пишется)
Ошибка	текст ошибки, если вызов не удался
Длительность	время выполнения вызова

Три правила, объясняющие, почему журнал остаётся читаемым и не превращается в свалку.

Секретоподобные аргументы маскируются. Поля с именами apikey, api_key, secret, password, passphrase и token заменяются на *** перед записью. То есть даже если клиент по ошибке передаст ключ в аргументах, в журнале он не окажется.

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

JSON аргументов и результата обрезается на 8 000 символов. Длинный список комментариев не раздует таблицу.

Ещё одно свойство, о котором стоит знать: запись в журнал делается по принципу «постараться». Если по какой-то причине лог не записался, основной поток не ломается, и ваш заказ всё равно оформляется. Журнал это наблюдение, а не блокирующий этап.

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

Как посмотреть подключённых ассистентов и отключить лишнего?

Список подключений находится на той же странице «AI Ассистент», в блоке подключённых ассистентов. Каждая строка описывает одно активное подключение.

В строке видно:

1. Название клиента, то есть имя программы, которая подключалась.
2. Значок прав: либо «Полный доступ», либо «Только просмотр». Это тот самый выбор, который вы сделали на экране подтверждения.
3. Дату подключения.
4. Дату последнего использования. По ней сразу видно забытые подключения, которыми никто не пользуется месяцами.
5. Кнопку «Отключить», которая запрашивает подтверждение перед разрывом.

Что происходит после отключения. Токены этого подключения перестают действовать, и клиент при следующем вызове получит ошибку авторизации. Заказы, которые уже были оформлены, никуда не деваются: они остаются вашими обычными заказами и продолжают выполняться. Отключение убирает доступ на будущее, а не отменяет прошлое.

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

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

Автоматизация: поток событий и вебхуки

Помимо запросов «по требованию», у аккаунта есть поток событий, к которому ассистент тоже имеет доступ. События генерируются, когда что-то меняется по вашим заказам и рефиллам.

Тип события	Когда возникает
order.created	заказ создан
order.processing	заказ взят в работу
order.completed	заказ выполнен
order.partial	заказ выполнен частично
order.canceled	заказ отменён
order.updated	по заказу что-то изменилось
refill.created	создан запрос на рефилл
refill.updated	состояние рефилла изменилось

Имена событий не переводятся: они одинаковые на всех языках, чтобы интеграции не ломались при смене языка интерфейса.

Работать с ними можно двумя способами. Первый это вебхуки: инструмент create_webhook регистрирует адрес, на который панель будет присылать подписанные уведомления, list_webhooks показывает уже созданные подписки, а delete_webhook удаляет подписку вместе с ожидающими доставками. Важная деталь: секрет подписи показывается в ответе ровно один раз, при создании. Если вы его не сохранили, придётся удалять подписку и создавать заново.

Второй способ это чтение потока напрямую инструментом list_events с постраничным курсором. Этот вариант выручает там, где вебхук поставить некуда: вы работаете локально, у вас нет публичного адреса, нет фиксированного IP или просто не хочется поднимать приёмник ради нескольких заказов в неделю. Ассистент читает события сам и рассказывает, что изменилось за период.

Типичный рабочий сценарий выглядит так. Вы утром спрашиваете: «Что изменилось по моим заказам со вчерашнего дня?». Ассистент читает поток событий, группирует по типам и отвечает: столько-то завершено, столько-то ушло в частичное выполнение, по таким-то есть смысл запросить рефилл, потому что услуга это поддерживает. Дальше вы решаете, что с этим делать.

Про сам протокол вебхуков и формат подписи подробно написано в документации API и на странице API для SMM-панели. Инструменты MCP здесь ничего не изобретают, они управляют теми же подписками, что и REST-эндпоинты.

Готовые команды: order_status, find_service и reorder

Кроме инструментов, сервер публикует готовые команды (в терминах протокола это prompts). Клиент показывает их отдельным списком, обычно через меню команд, и они экономят вам формулирование одного и того же запроса.

Команда	Что делает	Аргументы
order_status	сводка по последним заказам с пометкой зависших и недовыполненных	count (по умолчанию 10)
find_service	сравнивает от трёх до пяти услуг под ваш запрос и считает цену, заказ не оформляет	request (обязательный), quantity
reorder	повторяет прошлый заказ после вашего подтверждения	order_id (обязательный)

Про find_service стоит сказать отдельно, потому что это самая полезная команда для новичка. Она сознательно не оформляет заказ: её задача сравнить варианты и показать разницу. Вы описываете задачу словами («нужны просмотры для YouTube, важна скорость, бюджет ограничен»), а ассистент возвращает подборку с ценами, минимумами, наличием рефилла и отмены. Дальше вы уже выбираете сами.

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

reorder закрывает частую задачу: «сделай то же самое, что в прошлый раз». Команда достаёт параметры прошлого заказа по его номеру и предлагает повторить, но заказ оформляется только после вашего подтверждения, как и любой другой.

Готовые команды работают ровно в тех же границах, что и инструменты. У подключения в режиме только просмотра reorder не сможет ничего оформить, потому что инструмента создания заказа в его списке просто нет.

Сколько запросов в минуту выдерживает аккаунт?

Лимит на аккаунт составляет 600 запросов в минуту, и он общий с API v3. Панели неважно, пришёл вызов от вашего скрипта, от партнёрской интеграции или от ИИ-клиента: считается всё вместе, потому что это один и тот же аккаунт.

При превышении сервер отвечает кодом HTTP 429 и заголовком Retry-After: 60. Правильная реакция клиента это подождать указанное время и повторить, а не долбить эндпоинт заново.

Дополнительно на уровне API v3 действует ограничение 900 запросов в минуту на один IP-адрес. Оно имеет значение в сценариях, где с одного сервера работают несколько аккаунтов: суммарный поток с адреса тоже ограничен.

Для обычной работы через ассистента эти цифры недостижимы. Один диалог с оформлением заказа это порядка четырёх-пяти вызовов: поиск, карточка услуги, расчёт, создание, иногда проверка статуса. Даже очень активный день не приблизится к лимиту.

Упереться в потолок можно в двух ситуациях. Первая: массовая выгрузка, когда ассистент листает каталог или историю заказов страница за страницей. Вторая: параллельная работа скрипта и ассистента на одном ключе. В обоих случаях лечится это паузами и увеличением размера страницы (у поиска услуг она поднимается до 50 записей, у списка заказов до 100), а не попытками обойти счётчик.

Ещё один момент про подключение, а не про вызовы. Динамическая регистрация клиента ограничена десятью попытками в час с одного IP-адреса. Если вы отлаживаете собственную интеграцию и много раз подряд регистрируете клиента заново, вы это ограничение почувствуете. Регистрируйтесь один раз и сохраняйте выданный идентификатор клиента: он бессрочный.

Что меняется для реселлеров и владельцев дочерних панелей?

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

Для MCP это означает несколько вполне конкретных вещей.

У клиентов вашей панели тот же набор возможностей. Страница «AI Ассистент» работает и в дочерней панели, и ваши клиенты подключают своих ассистентов так же, как клиенты основной панели. Никакого отдельного включения не требуется.

Все адреса строятся из вашего домена. Адрес подключения, метаданные обнаружения, эндпоинты авторизации и экран подтверждения показываются на домене вашей панели. Клиент, который настраивает ассистента, видит только ваш бренд.

Цены он видит ваши. Инструменты каталога отдают то же, что видит клиент в интерфейсе, то есть цену с вашей наценкой, а не базовую себестоимость.

Аккаунт привязан к домену. Учётная запись, созданная в дочерней панели, действительна только на её домене. Если клиент попробует подключить ассистента к адресу основной панели, аккаунт там просто не найдётся. Это частая причина недоумения на старте, и лечится она проверкой адреса подключения.

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

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

Управляющий сервер на 57 инструментов: сторона владельца панели

Этот раздел нужен для полноты картины, а не для действия: он касается только владельца панели.

Управляющий сервер работает по адресу POST /api/mcp и защищён одним секретным ключом (MCP_SECRET). Если ключ в окружении не задан, эндпоинт полностью закрыт и отвечает кодом 503. Ключ принимается тремя способами: заголовком Authorization: Bearer, отдельным заголовком X-MCP-Secret и параметром запроса ?key=. Сравнение делается за постоянное время, чтобы по скорости ответа нельзя было подбирать значение.

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

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

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

Смысл упоминания этого раздела в статье для клиентов один: панель управляется тем же самым протоколом, что и предлагается вам. Это не витрина, приделанная сбоку, а часть архитектуры.

MCP, API или панель: что выбрать под конкретную задачу?

Три способа работы с аккаунтом сосуществуют, и у каждого своя зона, где он объективно лучше остальных.

Задача	Панель	API v3	MCP
Первый заказ, знакомство с каталогом	лучший вариант	избыточно	хорошо для сравнения услуг
Подбор услуги по нескольким критериям	долго, много фильтров	нужен код	лучший вариант
Разовый заказ вручную	хорошо	избыточно	хорошо
Сотни заказов в день из своего сервиса	не годится	лучший вариант	ограничение 50 за вызов
Ежедневная сводка по статусам	много кликов	нужен код	лучший вариант
Реакция на события в реальном времени	нет	вебхуки, лучший вариант	чтение потока событий
Пополнение баланса	единственный способ	нет	нет
Обращение в поддержку	единственный способ	нет	нет
Ограничение прав до чтения	не применимо	нет	есть, режим просмотра

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

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

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

Устранение неполадок: частые ошибки и их причины

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

Симптом	Причина	Что делать
401 invalid_token	истекли 8 часов жизни токена доступа	клиент обновляет токен сам; если не обновил, подключитесь заново из кабинета
В браузере 405	GET-запрос, попытка открыть SSE	протокол принимает только POST, это не сбой
429	превышены 600 запросов в минуту	подождать столько, сколько указано в Retry-After
Сообщение о недействительном или истёкшем запросе подключения	прошло больше 10 минут с выдачи кода либо клиент не зарегистрирован	начать подключение заново из клиента
Эндпоинт токена отвечает 400	клиент прислал PKCE в варианте plain	принимается только S256
Адрес возврата отклоняется	redirect_uri не совпадает с зарегистрированным	единственная поблажка это номер порта у петлевого адреса
Эндпоинт отвечает 503	на управляющем сервере не задан MCP_SECRET	касается только владельца панели
Аккаунт не находится	учётная запись создана в дочерней панели	подключаться нужно к адресу того домена, где заведён аккаунт

Несколько пояснений к строкам, которые чаще всего вызывают вопросы.

Про 405 в браузере. Это самая частая ложная тревога. Человек копирует адрес подключения, вставляет его в адресную строку, видит ошибку и решает, что сервер не работает. На самом деле браузер отправил GET, а сервер принимает только POST. Проверять доступность правильно запросом с телом JSON-RPC, как в примере с curl выше.

Про истёкший код. Код авторизации живёт 10 минут и используется один раз. Если вы подтвердили доступ и отвлеклись, клиент получит отказ. Это защита, а не поломка: просто запустите подключение заново.

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

Про ошибки инструментов. Если ассистент говорит, что инструмент вернул ошибку, посмотрите на код. insufficient_balance значит не хватает денег, quantity_out_of_range значит количество вне диапазона услуги, cancel_not_supported значит услуга не поддерживает отмену. Эти коды фиксированные, а сопровождающий текст приходит на вашем языке. Модель обязана передавать сообщение как есть, поэтому если она вместо этого предлагает «обойти» ограничение, это повод перепроверить её ответ вручную в панели.

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

Часто задаваемые вопросы

Что такое MCP простыми словами?

MCP это открытый протокол, по которому ИИ-ассистент получает доступ к внешнему сервису через описанный список инструментов. Сервис публикует, что умеет делать, а модель вызывает нужное действие с конкретными параметрами и получает настоящие данные, а не догадки. В случае SMM-панели это означает, что ассистент может искать услуги в каталоге, считать стоимость заказа, оформлять заказы и смотреть их статусы в вашем аккаунте.

Нужно ли давать ассистенту пароль от панели?

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

Может ли ассистент оформить заказ без моего разрешения?

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

Какие ИИ-клиенты поддерживаются?

Поддерживается любой клиент, который умеет работать с MCP по транспорту Streamable HTTP. Клиенты с поддержкой OAuth подключаются через браузерное подтверждение и ничего копировать не требуют, а клиенты, умеющие отправлять произвольные заголовки, подключаются по API-ключу. Родная версия протокола это 2025-06-18, но принимаются и более ранние 2025-03-26 и 2024-11-05, поэтому клиент постарше тоже подключится.

Как отключить ассистента и что произойдёт после этого?

Откройте страницу «AI Ассистент» в кабинете, найдите нужную строку в списке подключённых ассистентов и нажмите кнопку отключения, затем подтвердите действие. Токены этого подключения сразу перестают действовать, и клиент при следующем обращении получит ошибку авторизации. Уже оформленные заказы остаются вашими обычными заказами и продолжают выполняться: отключение убирает доступ на будущее, а не отменяет прошлое.

Сколько живёт токен доступа и придётся ли подключаться заново?

Токен доступа действует 8 часов, а токен обновления 90 дней, причём токен обновления меняется при каждом использовании. На практике это значит, что клиент сам обновляет доступ в фоне и вы этого не замечаете. Заново проходить подключение приходится только если клиент долго не использовался, если вы отозвали доступ сами или если система отозвала токены из-за подозрительного повторного использования кода.

Может ли ассистент пополнить мой баланс?

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

Что выбрать: подключение по API-ключу или через OAuth?

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

Увижу ли я в панели заказы, оформленные ассистентом?

Да, полностью. Заказ, созданный через MCP, ничем не отличается от заказа, оформленного руками: он появляется в списке заказов с тем же номером, статусом и суммой, к нему применимы те же кнопки рефилла и отмены и те же правила возврата. Дополнительно каждый вызов инструмента записывается в журнал аудита, где видно программу-клиента, имя инструмента, аргументы и время выполнения.

Могут ли клиенты дочерней панели подключать своих ассистентов?

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

Что происходит, когда инструмент возвращает ошибку?

Ошибка инструмента не рушит соединение и не считается ошибкой протокола: она приходит текстом с признаком isError: true, поэтому модель читает причину и может исправить вызов. Коды ошибок фиксированные, например insufficient_balance при нехватке средств или quantity_out_of_range при количестве вне диапазона услуги, а сопровождающее сообщение приходит на вашем языке. Ассистент должен передать это сообщение как есть, а не придумывать обходной путь.

Платный ли доступ к MCP?

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