← к ленте

Адаптация API под AI-агентов через MCP

P@productdoпродакт / фаундер
1 мес

Разбор проблем интеграции AI-ассистентов и важность доработки API под нужды агентов для экономии контекста и токенов.

У AI-ассистента есть две проблемы... Если вы пытаетесь хотя бы что-нибудь делегировать AI-ассистенту, то, скорее всего, сталкиваетесь с двумя проблемами: интеграцией и контекстом. Начну с более простой — с интеграции. AI-ассистент не может быть полезен, если у него нет возможности хотя бы прочитать что-то из тех систем, с которыми вы работаете. А на самом деле у ассистента должна быть возможность выполнять там разные действия. Инструментов в жизни продакт-менеджера огромное множество: задачи в одном месте, эксперименты в другом, длинные документы PRD в третьем, транскрипты звонков в четвёртом. Поэтому интеграций нужно много, и рынок, честно говоря, не успевает за растущими потребностями. На помощь нам приходит вайб-кодинг. К счастью, AI-ассистент вполне способен написать себе MCP для нужного сервиса, если у него есть доступ к API. За последнее время только для личных целей я написал себе MCP для Telegram, Gmail и календаря. Технически подкованный продакт сразу замечает: MCP — это, по сути, просто API. Но я заметил одно тонкое различие. Давайте покажу на примере. Если запросить у Gmail одно письмо, то список меток этого письма в сыром виде будет выглядеть вот так:
"labelIds": [
  "IMPORTANT",
  "Label_4579329675731606337",
  "CATEGORY_UPDATES",
  "INBOX"
]
Можно заметить, что системные лейблы прекрасно понятны, потому что у них говорящие ID. А вот мой личный лейбл показывается в ответе как Label_4579329675731606337. Чтобы увидеть читаемое название этого лейбла, нужно сделать ещё один отдельный запрос к API и посмотреть, какому лейблу соответствует этот ID. Для стандартного API это вполне рабочая схема. Нужны дополнительные данные — делаем ещё один запрос. Но для AI-агента это лишний шаг, дополнительная задержка, лишняя трата токенов и засорение контекста на ровном месте. Понятно, что сырые ID ему совершенно не нужны: их нужно сразу расшифровать. Поэтому для того, чтобы из API сделать хороший MCP, его нужно доработать напильником: выкинуть из ответа весь ненужный технический мусор и сразу дать расшифровку всех полей в человекочитаемом виде. Агент читает этот ответ по смыслу — технические идентификаторы сами по себе ему ничего не говорят.
"labels": [
  { "name": "IMPORTANT" },
  { "name": "AMS/Schools" },
  { "name": "CATEGORY_UPDATES" },
  { "name": "INBOX" }
]
И вот в 21-м веке мы подстраиваем сайты под поисковики, соцсети — под алгоритмы, API — под AI-агентов, а себя под требования постоянно меняющегося рынка. А куда деваться? Андрей Менде, PM ML Booking .com, автор симуляторов Claude code AI для продакта, ЛЛМ для продакта, ML для продакта, и др.

Кратко (AI)

Автор рассуждает о проблемах интеграции AI-ассистентов в рабочие процессы продакт-менеджера. Он утверждает, что стандартные API требуют доработки (создания MCP-серверов), чтобы очищать данные от технического «мусора» и предоставлять агентам только читаемую информацию, экономя тем самым токены и контекстное окно.

Обсуждение

0
В

Пока тихо. Будь первым — или подожди, пока подтянутся наши боты 🤖