Вашему MCP-серверу не нужно 40 инструментов

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

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

Проблема не в MCP. Проблема в том, что MCP воспринимают как магический адаптер для вашего бэкенда.

MCP-сервер — это не просто ваш API, ставший доступным для агентов. Это интерфейс продукта для очень буквального и крайне рассеянного пользователя. И этот пользователь — языковая модель.

Если вы дадите модели 40 похожих инструментов, вы не дадите ей силы. Вы дадите ей 40 способов быть «почти правым».

Перестаньте зеркально копировать ваши API-роуты. Люди могут читать документацию и понимать контекст. Модели же ищут совпадения паттернов в названиях и описаниях.

Стройте свой MCP-слой вокруг намерений пользователя.

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

  • Один инструмент для обзоров рынка
  • Один инструмент для календарей релизов
  • Один инструмент для конкретных снимков данных (snapshots)
  • Один инструмент для исторических индикаторов

API-роут говорит: «Если вы отправите этот запрос, сервер ответит». Инструмент MCP должен говорить: «Используйте меня для этой конкретной задачи с этими конкретными входными данными и ожидайте этот конкретный результат».

Хорошие описания инструментов — это логика маршрутизации, а не маркетинговый текст.

Плохо: name: get_data description: Получает данные из API.

Лучше: name: lookup_release_calendar description: Возвращает запланированные экономические события для одной валюты и диапазона дат. Используйте этот инструмент перед ответами на вопросы о предстоящих макроэкономических событиях.

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

  1. Используйте скучные названия. Разработчики любят компактные названия вроде fetch или query. Моделям же нужны специфические названия, такие как search_docs или check_deployment_status. Неоднозначные названия обходятся дорого.

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

  3. Проектируйте с учетом возможных ошибок. Качество продакшн-решения зависит от того, как вы обрабатываете ошибки. Не возвращайте просто ошибку 500 или пустой массив. Объясните модели, почему произошел сбой. Если записи не найдены, скажите модели предложить пользователю более широкий диапазон дат.

Лучший инструмент для агента — не самый мощный, а тот, который модель не сможет понять неправильно.

Source: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

Optional learning community: https://t.me/GyaanSetuAi