TL;DR
Когда у агента есть несколько похожих инструментов (например, два «отправить письмо» от разных MCP-серверов), модель выбирает по метаданным: названию сервера и инструмента, описанию и схеме параметров. Исследователи меняли ровно одно поле за раз и смотрели, как сдвигается выбор. Сильнее всего влияла схема параметров: какие поля принимает инструмент, как они названы и сгруппированы. Названия влияли слабо.
Главная находка: инструмент можно проиграть до вызова только из-за неудачных названий и структуры полей. Если поле называется recipient_id вместо привычного to, инструмент выбирают в 1–10% случаев вместо примерно 50%. Модель читает _id как «нужен идентификатор, а не адрес почты» и обходит такой инструмент. Если названия инструментов различаются, но по смыслу они одинаковы, модель часто просто берёт первый в списке.
Практический вывод из статьи: плоские отдельные параметры (owner и repo, а не одна склейка или объект), привычные имена полей и описание, объясняющее параметры, повышают шансы инструмента. Порядок инструментов в списке тоже влияет, и его нужно проверять перестановкой.
Схема метода
Что меняли (по одному за раз, остальное неизменно):
S: имя сервера → слабый эффект, часто решает позиция
T: имя инструмента → почти не влияет
D: описание → +, если объясняет параметры
P: схема параметров → самый сильный и стабильный эффект
Что выигрывает в схеме (P):
• отдельные поля на верхнем уровне > поля внутри объекта
• раздельные owner + repo > одна строка "owner/repo" (если запрос даёт их раздельно)
• привычные имена (to, location) > "умные" (recipient_id)
Позиция в списке: при равных инструментах чаще выбирают первый
Пример применения
Задача: Вы автоматизируете интернет-магазин на Wildberries и подключили агенту (Claude Code или Cursor) два MCP-инструмента для создания заказа в CRM. Один из них написали вы, второй пришёл с чужим сервером. Агент почти всегда берёт чужой, ваш «простаивает». Нужно понять, что в вашей схеме мешает, и поправить.
Промпт:
Ты ревьюер метаданных MCP-инструментов. Два инструмента делают одно и то же.
Агент почти всегда выбирает инструмент B. Найди, чем наш инструмент A проигрывает на этапе выбора.
Инструмент A (наш):
name: crm-internal_create_order
description: Создаёт заказ в CRM.
parameters: { "create_order_request": { "customer_id": string, "items": array, "delivery_city": string } }
Инструмент B (чужой):
name: shop-server_create_order
description: Создаёт заказ. customer_id — телефон или email клиента, items — список артикулов с количеством, city — город доставки.
parameters: { "customer_id": string, "items": array, "city": string }
Проверь по пунктам:
1. Сгруппированы ли параметры в объект, хотя можно сделать плоскими.
2. Есть ли нестандартные имена полей (например, с суффиксом _id или редкие синонимы).
3. Объясняет ли описание параметры и что возвращается.
4. Влияет ли порядок инструментов в списке.
Дай переписанный вариант A: плоские параметры, привычные имена, описание с пояснением каждого поля.
Предложи 6 тестовых запросов и схему перестановки порядка, чтобы проверить результат.
Результат: Модель разберёт обе схемы по четырём пунктам. Скорее всего, она укажет объект-обёртку у A, нестандартное имя поля и скупое описание. Затем выдаст переписанный инструмент A с плоскими полями и описанием параметров. В конце будет план проверки: набор запросов и прогон в разном порядке инструментов.
Почему это работает
Слабость. Модель не видит код инструмента. Ей доступны только название, описание и схема. Названия у похожих инструментов часто почти одинаковы, и по ним выбирать нечем. Тогда модель опирается на что угодно: порядок в списке, «звучание» поля.
Сильная сторона. Модель хорошо читает схему как сигнал «подходит ли этот инструмент моему запросу». Поле to выглядит как почтовый адрес, recipient_id как внутренний идентификатор. Раздельные owner и repo ложатся на запрос «репозиторий X у пользователя Y» без дополнительных преобразований.
Как использовать. Сделайте схему похожей на то, что естественно вытекает из запроса. Плоские поля, привычные имена и описание, раскрывающее параметры, уменьшают для модели «трение при подборе».
Рычаги управления:
- Структура параметров → убрать объект-обёртку, раскрыть составные поля.
- Имена полей → брать самые частые в категории (to, location).
- Описание → добавить, что значит каждое поле и что возвращает инструмент.
- Порядок инструментов → поставить нужный первым, но проверять перестановкой.
- Имя сервера и инструмента → не вкладывать в них усилия, эффект слабый и нестабильный.
Шаблон промпта
В статье нет готовых промптов. Шаблон ниже собран из её выводов как чек-лист ревью.
Ты ревьюер метаданных MCP-инструментов. Сравни инструменты, которые делают одно и то же.
Задача: понять, почему агент выбирает {инструмент_конкурент} вместо {наш_инструмент}.
Инструмент 1:
name: {имя_1}
description: {описание_1}
parameters: {схема_1}
Инструмент 2:
name: {имя_2}
description: {описание_2}
parameters: {схема_2}
Типичный запрос пользователя: {пример_запроса}
Проверь:
1. Группировка: есть ли параметры внутри объекта, которые можно вынести на верхний уровень?
2. Имена: есть ли нестандартные имена полей (суффикс _id, редкие синонимы)?
3. Составные поля: есть ли одна строка, которую можно разбить на отдельные поля, если запрос даёт их раздельно?
4. Описание: объясняет ли оно каждый параметр и результат?
5. Порядок: как изменится выбор, если поменять инструменты местами?
Выдай:
- таблицу отличий;
- переписанную схему и описание для {наш_инструмент};
- {число} тестовых запросов и план проверки с перестановкой порядка.
Подставьте:
- {наш_инструмент} и {инструмент_конкурент} — те, между которыми идёт борьба;
- реальные схемы и описания;
- типичный запрос пользователя.
Ограничения
⚠️ Только для похожих инструментов: Все эффекты измерены там, где любой кандидат может выполнить запрос. Если запрос требует функции, которую поддерживает только один инструмент (например, копию получателю), модель выберет правильный независимо от порядка.
⚠️ Зависит от конкретных имён: Эффект сильно зависит от слов, а не от самой идеи «переименовать».
recipient_idрезко проигрывал, аreceiver, слово из запросов не используемое, оставался конкурентным. Универсальных «хороших» имён нет, нужен тест.
⚠️ Зависит от формата запроса: Если пользователь пишет путь целиком (
owner/repo), предпочтение раздельных полей ослабевает, а у одной модели разворачивается в обратную сторону.
⚠️ Позиция часто решает всё: Когда различия только в названиях, почти все модели берут первый инструмент. При двух кандидатах это особенно заметно. Без проверки в разном порядке легко принять позицию за качество.
⚠️ Неоднородные модели: Не все модели ведут себя одинаково. У DeepSeek в одной задаче явного предпочтения схемы не было, а Qwen часто выбирал только по позиции, поэтому его эффекты метаданных не определены.
⚠️ Условия теста: Режим размышления у моделей был отключён, задач пять, запросы синтетические. Для реального агента с длинным контекстом и размышлением эффект может отличаться. Часть текста статьи (совместные эксперименты и выводы) в доступной версии обрезана.
Как исследовали
Исследователи сначала выгрузили метаданные 367 174 MCP-инструментов и заметили странность. Например, 169 инструментов с названием send_email используют 78 разных наборов параметров. Названия и описания у них почти одинаковые, различаются поля (to против recipient_id). Из этих данных нельзя вычислить влияние схемы, потому что у инструментов различается и всё остальное. Поэтому они поставили контролируемый эксперимент.
Для пяти задач (отправка письма, погода, создание issue, заказ, pull request) они сделали версии инструментов, различающиеся ровно одним полем: имя сервера, имя инструмента, описание или схема параметров. Каждой из пяти моделей (GPT-5.4 mini, Claude Sonnet 4.6, Gemini 3.5 Flash, DeepSeek V4 Pro, Qwen3.7-Plus) давали по 50 запросов и 2, 3 или 5 кандидатов. Позиции в списке уравновесили циклической перестановкой. Для эффекта «после поправки на позицию» использовали условную логит-модель.
Результат: из 28 оцененных числовых эффектов схемы 23 статистически значимы, и 22 из них положительные. Эффект схемы примерно вдвое больше эффекта имени сервера. Самый показательный контраст: recipient_id против receiver. Первый обрушивает выбор до 1–10%, второй оставляет 35–51%. Это показывает, что модель не просто ищет совпадающие слова: она «понимает» смысл поля. Решающая проверка была такой: когда запрос просит CC, а поддерживает его только одна схема, все пять моделей выбрали её, даже если она стояла второй. То есть схема работает как проверка «подходит ли инструмент», а не только как инструкция по форматированию аргументов.
Неожиданное: названия, на которые все тратят силы, почти ничего не решали. В сравнениях по именам модели выбирали первый инструмент в 79–96% случаев. Для практики отсюда следует простое правило: измеряйте выбор при разном порядке инструментов, иначе вы измеряете позицию.
Адаптации и экстраполяции
💡 Адаптация для защиты от «перехвата» выбора: если вы подключаете чужие MCP-серверы, проверьте, не обходит ли чужой инструмент ваш за счёт более «удобной» схемы.
Вот два инструмента, которые делают одно и то же: {инструмент_1}, {инструмент_2}. Посчитай, у какого схема «привлекательнее» для модели по признакам: плоские поля, привычные имена, пояснения параметров в описании. Покажи, какие отличия могут заставить агента выбирать один из них независимо от качества.
🔧 Техника: перестановка порядка → честная проверка выбора
Прогоните одни и те же 6–10 запросов, меняя порядок инструментов в списке (A,B и B,A). Если инструмент выигрывает только когда он первый, его метаданные не работают, это эффект позиции. Проверяйте перестановкой любое изменение описания или схемы.
Ресурсы
- Which Metadata Matters for LLM Tool Selection in MCP? Evidence from Controlled Factor-Level Interventions
- Авторы: Xiaofan Li, Xing Gao (University of Delaware), Fengchun Qiao (University of South Florida)
- Связанные работы из исследования: анализ метаданных 367 174 MCP-инструментов (Li & Gao, 2026); смещения выбора инструментов (Blankenstein et al., 2026); влияние описаний на использование инструмента (Faghih et al., 2025); качество описаний MCP-инструментов (Hasan et al., 2026)