Схема MCP-инструмента изменилась. Ваш агент этого не заметил.

Ваш вызов инструмента не привел к сбою. Он вернул статус 200 и валидный JSON.

Но он сработал по неверному контракту. Три дня назад вышестоящий сервер переименовал одно поле. Ваш агент продолжал отправлять старое имя. Сервер молча отбросил его. Результат пришел пустым. Ошибки не возникло. Никто не замечал этого целую неделю.

Это «тихий сбой». Не тот громкий тип, когда логи окрашиваются в красный. А тот, когда сервер отвечает вам улыбкой, но данные неверны.

MCP-серверы могут изменять контракт инструмента между вызовами. Они могут переименовать параметр или изменить описание поля. Эти изменения часто остаются структурно валидными. Валидация JSON проходит успешно. Сервер отвечает кодом 200. Ваш агент действует на основе неверных данных без единой ошибки.

Решение простое: • Зафиксируйте SHA-256 хеш каждого контракта инструмента. • Включите в этот хеш как схему, так и описание. • Проверяйте хеш перед каждым вызовом. • Прекращайте вызов, если произошел дрифт контракта.

Мы фокусируемся на том, отвечает ли инструмент. Мы проверяем статус-коды. Мы устанавливаем таймауты. Мы делаем повторные попытки при ошибках 5xx. Почти никто не проверяет, изменился ли контракт в промежутке между моментом, когда агент узнал схему, и моментом, когда он сделал вызов.

MCP-сервер предоставляет инструменты через tools/list. Каждый инструмент имеет inputSchema и описание (description). Ваш агент считывает это один раз в начале сессии.

Если сервер обновляется, он может:

  • Переименовать параметр (например, с query на q), оставляя при этом открытыми дополнительные свойства. Старый параметр будет молча отброшен.
  • Изменить значение поля. Параметр limit может измениться с «максимального количества результатов» на «индекс страницы». Тип остается целым числом (integer), поэтому валидация проходит.
  • Сузить перечисление (enum). Валидное значение может быть приведено к новому значению по умолчанию.

Спецификация MCP гласит, что сервер ДОЛЖЕН (SHOULD) уведомлять клиента об изменениях в списке. Но она не говорит, что он ОБЯЗАН (MUST). Многие серверы не отправляют такие уведомления. Даже если они их отправляют, они могут не сообщить, что изменилась схема конкретного инструмента.

Перестаньте полагаться на структурную валидацию. Она не способна заметить изменение смысла.

Относитесь к своим MCP-инструментам как к программным зависимостям. Используйте подход с lock-файлом. При первом контакте создайте SHA-256 хеш схемы и описания инструмента. Перед каждым вызовом пересчитывайте хеш. Если они совпадают — продолжайте. Если нет — зафиксируйте дрифт и остановитесь.

Секрет в хешировании описания. Если параметр меняется с «max results» на «page index», схема выглядит так же. Хеш изменится, потому что изменились слова. Это позволяет отловить семантический дрифт, который пропускает валидация.

Не гадайте, когда контракт изменился. Не делайте повторные попытки вслепую. Сделайте паузу, залогируйте разницу и исправьте контракт.

Source: https://dev.to/0012303/the-mcp-tool-your-agent-calls-changed-its-schema-it-didnt-notice-5g6m

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