Apple показала Agent Seer — систему, которая превращает описание MCP-сервера в набор проверок для агента без живого сервера, реальных ответов инструментов и ручной разметки. Для команд, которые уже строят или только примеряют к себе MCP, это выглядит как практичный сдвиг: тестирование MCP-агентов можно запускать не после долгой сборки стенда, а сразу после появления спецификации.
По данным Habr / Новости, Agent Seer работает только по текстовому контракту сервера: названиям функций, описаниям и схемам параметров. Из этого описания конвейер собирает пользовательские задачи, ожидаемые цепочки вызовов, правдоподобные ответы инструментов, многошаговые диалоги и эталон, с которым потом можно сравнивать поведение агента. Идея довольно хладнокровная: если MCP-схема и так описывает, что умеет сервер и как его вызывать, значит, эта же схема может стать сырьём для тестов. Не документацией «для галочки», а рабочим артефактом для CI.
На семи MCP-серверах система сгенерировала 337 сценариев. Уже на этом объёме всплыла важная вещь: главный источник ошибок связан не с количеством инструментов как таковых, а со сложностью их параметров. Проще говоря, агент нередко понимает, какую функцию надо вызвать, но ошибается в том, что именно передать внутрь. Это неприятный класс сбоев, потому что на поверхностной проверке всё выглядит почти правильно: имя функции выбрано верно, вызов случился, лог красиво мигает. Но результат всё равно ломается из-за неверного аргумента, лишнего поля, неоднозначного значения или не того формата входных данных.
Именно здесь тестирование MCP-агентов становится интереснее обычной проверки tool calling. Во многих командах до сих пор валидируют в первую очередь сам факт выбора инструмента: агент дошёл до нужной функции, значит, молодец. Agent Seer подсвечивает более неприятную правду: для надёжности этого мало. Если схема параметров перегружена, запутана или допускает несколько трактовок, агент может стабильно «почти попадать» в цель. Для продакшена это хуже, чем грубая ошибка выбора инструмента: баг сложнее заметить, он дольше живёт и чаще прячется в редких сценариях, которые не поймаешь парой ручных прогонов.
На уровне отрасли новость ложится в понятный тренд. Вокруг агентных систем быстро выросла инфраструктура для генерации ответов, маршрутизации инструментов и оркестрации цепочек, а вот инженерная дисциплина вокруг тестирования всё ещё догоняет. Код, который вызывает API, давно привык к контрактным тестам, мокам и регрессиям. Агенты пока чаще проверяют демонстрациями и набором happy path-сценариев. Подход Apple фактически предлагает перенести в агентный мир старую добрую мысль: если у вас есть формальный интерфейс, из него можно автоматически собирать проверки. Для MCP это особенно логично, потому что сама спецификация и существует как машиночитаемое описание возможностей инструмента.
Для разработчиков из этого следует довольно приземлённый вывод: спецификация MCP-сервера перестаёт быть просто паспортом интеграции. Она начинает влиять на тестопригодность системы. Чем чище названия методов, чем яснее описания и чем проще схема аргументов, тем выше шанс получить внятные синтетические сценарии и быстрее поймать регрессии после изменений. И наоборот: если API сервера выглядит как чулан после переезда, агент тоже будет спотыкаться чаще. В этом смысле Agent Seer подталкивает команды не только к автоматизации тестов, но и к санитарной уборке самих MCP-контрактов. Параметры должны быть не просто формально описаны, а однозначны для машины, которая будет делать выводы без человеческих догадок.
Для продактов и IT-руководителей здесь тоже есть прикладная польза. Любая команда, которая меняет MCP-схемы по мере роста продукта, получает шанс автоматически пересобирать дымовые и регрессионные тесты после каждого изменения контракта. Это может сократить цену экспериментов с новыми инструментами и помочь раньше выявлять поломки на стыке «агент — сервер». Особенно там, где интеграции появляются быстро, а ручное покрытие почти всегда отстаёт от реальности. При этом не стоит продавать такой подход как серебряную пулю: синтетическая проверка отлично ловит ошибки формы, но не гарантирует, что бизнес-логика отрабатывает верно и что реальные данные не разобьют красивую картинку на первом же боевом запросе.
Ограничение у подхода существенное и Apple его не прячет. Сценарии и эталоны синтетические, а качество результатов оценивала другая LLM. Это полезно для раннего обнаружения контрактных ошибок, но не заменяет тесты на живых данных, end-to-end прогоны и проверку доменной логики. Иначе говоря, Agent Seer может показать, что агент аккуратно следует правилам интерфейса, но не докажет, что интерфейс вообще ведёт к правильному бизнес-результату. Для зрелой команды это не минус, а скорее честная граница применения: тестирование MCP-агентов по спецификации хорошо работает как нижний слой защиты, а не как вся пирамида качества целиком.
Самый любопытный вопрос теперь не в том, можно ли генерировать тесты из MCP-схемы, а в том, станет ли это обязательной практикой для всех, кто всерьёз строит агентные продукты. Если ответ да, рынок быстро начнёт наказывать за плохо спроектированные параметры и расплывчатые описания функций. И это, пожалуй, редкий случай, когда аккуратная спецификация перестаёт быть бюрократией и превращается в прямое конкурентное преимущество.
