BestrankMCP: Сначала ресурс, потом сырой список: как не путать подборки и инструменты

Сначала ресурс, потом сырой список: как не путать подборки и инструменты

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

Снаружи всё мило. Есть коллекция «Мои чаты с Битрикс24». Рядом инструмент «покажи все чаты». Кажется, агент разберётся.

Не разберётся. Возьмёт привычный общий список, отфильтрует по словам и вернёт «почти то». Формально похоже. По смыслу - уже не ваша подборка.

Проблема не в «глупой модели». В контракте сервера. Если нужна готовая бизнес-сущность, сервер должен вести к ней архитектурой, а не намёком.

Как это ломается в офисе

Руководитель пишет: «Покажи мои чаты с Битрикс24». В голове - готовый список. На сервере рядом ресурс с длинным URI и инструмент со всеми чатами аккаунта. Без явного маршрута побеждает второй.

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

Простое правило

Именованная, стабильная, заранее заданная человеком, с бизнес-смыслом - ресурс.

Ищет, фильтрует, листает весь каталог, шлёт сообщения, читает сырой поток без заранее зафиксированного смысла - инструмент.

Частая ошибка: ресурс сделали, но оставили рядом такой же удобный общий list «на всякий случай». Для человека страховка. Для агента - приглашение срезать угол.

Почему «ресурс рядом» ещё не resource-first

Агент редко угадывает длинный URI. Нужен индекс подборок - список того, что вообще есть. Нужен поиск по естественному имени: человек пишет «мои чаты с Битрикс24», не адрес. Маршрут: найти → открыть → только потом сырой список, если нужен drill-down.

И сырые инструменты должны выглядеть сырыми. «Список чатов» слишком хорошо рифмуется с «покажи мои чаты». В имени и описании лучше прямо: все чаты, запасной путь, не вместо curated-коллекции.

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

Тот же паттерн не только в Telegram

В CRM - «просроченные VIP». В Jira - «критические баги релиза». В базе знаний - «регламенты онбординга». Если каждый раз собирать через общий list, получается набор самодельных фильтров. Держится до первого спорного названия.

Что сделать сегодня без философии: выписать три-пять повторяющихся подборок, перенести в ресурсы, добавить индекс, дать поиск по имени, переименовать общие list в «сырой / все», поправить описания.

База - что такое MCP. Типы - инструменты, ресурсы, промпты. Про ресурсы отдельно - справочники и снимки.

Если агент стабильно берёт не тот источник, чаще помогает пересобрать контракт, а не сменить модель.