Что API для публикации в соцсети должен давать ИИ-агенту: семь пробелов, которые мы намерили у себя

Mellow Hub — это API публикации с MCP-сервером поверх: 49 инструментов в полном каталоге и 10 сетей для публикации. С октября 2026 года наш собственный контент-агент ставит через него ролики основателя в четыре профиля Hub на трёх языках. 8 ноября 2026 года агент записал, чего ему не хватало, и мы в тот же день сверили каждый пункт с живым сервером.

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

Чем агент занят весь день

Узнать, что ему можно; загрузить видео; проверить пост; поставить его в расписание; поправить; встроить в очередь, общую с другими постами и профилями; получить «да» человека; понять результаты. Вечер, когда он поставил восемь постов, показывает этот цикл по вызовам. Найти, что снимать, — тоже работа: trends_search и trends_breakdown появились на боевом сервере 8 ноября, уже после прогона, который мы здесь измеряем, поэтому в список они не входят.

Что сработало и должно быть везде

• Один вызов, который говорит, что агенту можно. whoami возвращает режим, права, каналы, сколько постов осталось на сегодня и разрешает ли подписка публиковать.
• Проверка, которая ничего не публикует. validate_post возвращает все проблемы сразу и называет канал и поле.
• Обязательный ключ идемпотентности. 7–8 ноября 2026 года агент сделал 38 вызовов create_post и получил 38 постов без дублей — включая вызов, который вернул ошибку лимита с пометкой «можно повторить» и при этом номер уже сохранённого поста.
• Сверка с итогом от сети. get_post даёт статус и публичную ссылку по каждому каналу; partial значит, что часть каналов вышла, а часть нет.
• Отказы, которые модель может пересказать. Пробный рилс, который Instagram не дал, вернулся с фразой «Instagram did not give this reel a trial, and it was not posted as an ordinary reel».
• Человек, которого доступ не может обойти. Ключ в режиме проверки готовит пост и останавливается, и ни один ключ не одобряет собственный пост (как устроена доверенность).

Семь пробелов и что мы видели

1. Нет очереди по времени. list_posts отдаёт свежие посты первыми, с фильтром по статусу, не больше 100 за раз. Нет окна времени, нет фильтра по каналу, нет сортировки по времени публикации. 8 ноября агент расставил восемь постов, прочитав запланированные посты четырёх профилей и сведя их вручную. Если в статусе больше 100 постов, остальное не видно: у одного профиля список отменённых упёрся в потолок. Человек видит очередь по дням в календаре Hub; у агента такого чтения нет. *Что помогло бы:* чтение очереди по окну времени сразу по всем каналам и свободные слоты с учётом дневного лимита.

2. Один доступ — один профиль. Четыре профиля — это четыре ключа и таблица «язык → ключ» в каждом скрипте. Это сделано сознательно: ключ к одному профилю — узкая доверенность, которую человек видит и может отозвать. Платит за это агент. *Что помогло бы, ничего не расширяя втихую:* список профилей и доступ, который человек выдаёт сразу на несколько профилей, называя каждый, с лимитом и журналом по каждому, — или способ скопировать пост в другой профиль.

3. Три суммы для одного числа. Около 12:00 UTC 8 ноября 2026 года просмотры русского YouTube основателя читались тремя способами:

Каждое число верно для своего окна, но агент на вопрос «как сходил YouTube?» не может понять, какое называть. get_metrics читает до 50 последних постов на канал, и в его строках есть номер поста в сети и ссылка, но нет номера поста в Hub, поэтому результаты сопоставляются с расписанием по времени и подписи. Некоторые сети через этот путь ничего не отдают (у Telegram — unsupported), и инструмент так и говорит, а не показывает ноль. *Что помогло бы:* одно чтение, которое возвращает число с окном, временем чтения и источником, привязанное к номеру поста в Hub.

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

4. Нет частичной правки. update_post принимает пост целиком: что не передано, удаляется. Чтобы заменить одно видео, пришлось заново отправить подпись, каналы, настройки каждой сети и время. *Что помогло бы:* правка только тех полей, которые названы.

5. Нет меток, чтобы связать результаты с экспериментами. Агент вёл несколько семейств роликов и восстанавливал, какой пост к какому относится, по подписям и своим заметкам. *Что помогло бы:* метки на посте и результаты по меткам с размером выборки и предупреждением, если она мала.

6. Один пост за вызов. На серию ушло 38 вызовов пачками, примерно через пять секунд друг за другом, и один всё равно упёрся в лимит запросов провайдера публикации. *Что помогло бы:* массовое создание и массовая проверка с ключом идемпотентности и отдельным итогом для каждого поста, с темпом на стороне сервера.

7. Допуск узнаёшь только по отказу. validate_post проверяет, что пробный рилс — это одно видео в формате рилса; подписчиков он не видит. 7 ноября пробный рилс для аккаунта меньше чем с 200 подписчиками прошёл проверку и получил отказ Instagram, и ничто в list_channels об этом не предупредило. Сам Hub читает число подписчиков только у аккаунтов, подключённых через собственное приложение Mellow для Instagram. *Что помогло бы:* допуск каждого канала в списке каналов и предупреждение от проверки. Подробнее о пробных рилсах через API.

Как мы обходились

• Таблица «язык → ключ» и whoami первым вызовом при каждом запуске.
• Локальная таблица загрузок, чтобы повтор брал уже загруженное медиа.
• Время постов вручную по четырём чтениям очереди.
• Результаты сопоставлены с постами по времени публикации и подписи, у каждого числа записано время чтения.
• Для каждого update_post пост целиком собирается заново из файла плана.

Как оценить любой API публикации для агента

1. Может ли агент узнать свои лимиты одним вызовом?
2. Есть ли проверка, которая ничего не публикует и возвращает все проблемы сразу?
3. Обязателен ли ключ идемпотентности и возвращает ли ошибка, за которой пост сохранён, его номер?
4. Даёт ли сверка итог и ссылку по каждой сети?
5. Может ли агент читать очередь по времени сразу по всем каналам?
6. Приходит ли каждая метрика с окном, временем чтения и номером поста?
7. Можно ли поменять одно поле, не отправляя пост заново?
8. Видно ли до отправки, что аккаунту доступно?
9. Есть ли одобрение, которое может дать только человек, и журнал действий каждого доступа?
10. Сформулированы ли отказы так, чтобы модель могла пересказать их человеку?

8 ноября 2026 года Hub отвечал «да» на 1–4, 9 и 10 и «нет» на 5–8. Задать те же вопросы любому API до того, как на него опирается агент, дешевле, чем узнать ответы по очереди публикаций. Основы — в гайде о планировании постов через API.

Цифры коротко