Оценка MCP-сервера на моделях

Оценка MCP-сервера на моделях - прогон фиксированного набора задач через модель с подключённым сервером, по нескольку раз на каждую задачу, с автоматической проверкой результата и замером вызовов инструментов, токенов, времени и ошибок. Она показывает, выполняют ли модели задачи, для которых сервер создан, с помощью его инструментов, их описаний и результатов. Место оценки среди других уровней тестирования описано в статье Тестирование MCP-серверов: основы.

Спецификация MCP, текущая версия 2026-07-28, описывает протокол и не описывает оценку: в документации протокола такого раздела нет. Метод для инструментов агентов описан Anthropic в двух инженерных статьях: «Writing effective tools for agents» (11 сентября 2025) и «Demystifying evals for AI agents» (9 января 2026). Кроме того, Anthropic публикует руководство и стенд для оценки MCP-серверов в составе скила mcp-builder в репозитории anthropics/skills.

Кратко

Какую задачу решает

Модульные тесты и тестирование соответствия проверяют код и протокол, но не показывают, что модель делает с сервером: она может вызвать не тот инструмент, неверно заполнить аргументы или остановиться, не закончив задачу.

Ручная проверка в чат-ассистенте даёт одну попытку одного сценария. Её нельзя точно повторить, а результат нельзя сравнить между двумя версиями описаний или двумя моделями.

Оценка заменяет это фиксированным набором задач, автоматической проверкой и повторными попытками. Её числа можно сравнивать между версиями сервера, версиями описаний и моделями.

Из чего состоит оценка

Словарь ниже определён в статье «Demystifying evals for AI agents». В третьем столбце - что каждая часть означает для MCP-сервера.

Статья подчёркивает: оценить агента - значит оценить модель и агентную обвязку вместе. Для MCP-сервера третий компонент - сам сервер.

Задачи

Какой должна быть задача

Anthropic рекомендует задачи из реального использования и на реальных данных, а не в упрощённой песочнице. Сильная задача требует нескольких вызовов инструментов, иногда десятков. Слабая задача называет всё прямо: назначить встречу с указанным адресом почты. Сильная задача требует сначала найти данные: назначить встречу по проекту, приложить заметки с прошлой встречи и забронировать переговорную.

Статья «Demystifying evals» добавляет практические правила:

• Источник. Для начала достаточно 20-50 простых задач, взятых из реальных сбоев. Такие задачи дают баг-трекер и обращения в поддержку.
• Однозначность. Два эксперта выносят по результату один и тот же вердикт. У каждой задачи есть эталонное решение.
• Баланс. В наборе есть задачи, где инструмент нужно вызвать, и задачи, где вызов - ошибка.
• Сломанные задачи. Задача, которую не проходит ни одна попытка, обычно указывает на дефект задачи или оценщика, а не агента.

Руководство mcp-builder добавляет, что вопросы независимы друг от друга, требуют только операций чтения и имеют ответы, которые не меняются со временем: число реакций на сообщение не подходит, факт о закрытом проекте подходит.

Проверяемый результат

В таблице - три вида оценщиков, которые применяют для MCP-серверов.

Точный ответ подходит для вопросов с одним значением: имя, дата, число. Оценщик не должен отклонять верный ответ из-за форматирования или равнозначной формулировки, поэтому задача указывает формат, например «use YYYY/MM/DD».

Проверка состояния оценивает итог, а не отчёт агента: оценщик ищет бронь в базе данных, а не верит словам агента, что бронь сделана. Для инструментов, которые меняют данные, это основной вид оценщика.

LLM-as-judge применяют, когда результат - свободный текст. Общий метод, рубрики и калибровка описаны в статье Тестирование LLM-приложений.

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

Описание задачи

Спецификация и статьи не определяют формат файла задач. Пример ниже показывает поля, которые обычно нужны описанию задачи; имена полей произвольные.

{
  "id": "issues-017",
  "split": "train",
  "prompt": "Find the bug that was reopened most often in the Billing project during March 2026 and add the label needs-review to it. Reply with the issue key only.",
  "grader": [
    { "type": "exact_answer", "expected": "BILL-482" },
    { "type": "state_check", "query": "labels of BILL-482", "expected_contains": "needs-review" }
  ],
  "expected_tools": ["search_issues", "get_issue_history", "update_issue"],
  "tags": ["search", "write"]
}

Поле split отделяет задачи для настройки от отложенных. Поле expected_tools сравнивается со стенограммой, но не решает исход.

Запуск оценки

Агентный цикл

Anthropic рекомендует запускать оценку прямыми вызовами API модели, а не через чат-интерфейс. У каждой задачи свой цикл: модель вызывает инструменты и получает результаты, пока не даст итоговый ответ.

Evaluation harness
 |
 +-- tools/list --------------------------> MCP server (version under test)
 |     name, description, inputSchema
 |
 +-- task prompt + tool definitions ------> model API
 |                                            |
 |   <------------------------------------ tool call (name, arguments)
 +-- tools/call --------------------------> MCP server
 |   <------------------------------------ result or isError: true
 +-- tool result ------------------------> model API
 |     ... repeated until a final answer ...
 |
 +-- final answer + environment state ----> graders
 +-- transcript, counters, timings -------> result record

Описания инструментов, которые получает модель, берутся из tools/list проверяемой версии сервера, поэтому изменённое описание доходит до модели без правок стенда.

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

Изолированные попытки

Каждая попытка начинается с чистого окружения: общее состояние делает сбои связанными, а в примере из статьи «Demystifying evals» Claude прочитал историю git, оставшуюся от предыдущих попыток. Для MCP-сервера это означает сброс тестовых данных перед каждой попыткой и идентификаторы состояния, которые не переживают попытку.

Запись результата

Каждая попытка даёт запись, в которой входные параметры прогона хранятся вместе с результатами. Пример ниже - один из возможных форматов; имена полей произвольные.

{
  "task_id": "issues-017",
  "trial": 3,
  "model": "model-a",
  "agent_harness": "eval-loop-1.2",
  "server_version": "1.5.0",
  "passed": false,
  "graders": [
    { "type": "exact_answer", "passed": true },
    { "type": "state_check", "passed": false }
  ],
  "tool_calls": 14,
  "tool_errors": 3,
  "protocol_errors": 0,
  "input_tokens": 48210,
  "output_tokens": 2315,
  "duration_ms": 41870,
  "transcript": "runs/2026-11-03/issues-017-3.jsonl"
}

Ошибки выполнения инструмента (результаты с isError: true) и ошибки протокола (ошибки JSON-RPC) считаются отдельно: первые доходят до модели, вторые обычно нет.

Повторные попытки и доли успеха

Одна и та же задача в разных попытках даёт разные последовательности вызовов инструментов. Одна успешная попытка показывает, что задачу можно решить, но не что она решается надёжно, поэтому результат задачи - доля успешных попыток. Результаты k попыток одной задачи описывают две метрики.

pass@k - вероятность, что успешна хотя бы одна из k попыток. Метрику ввела статья «Evaluating Large Language Models Trained on Code» (Chen и соавторы, июль 2021) для генерации кода. Статья оценивает её по n ≥ k попыткам, из которых c успешны, как 1 - C(n-c, k) / C(n, k) с усреднением по задачам; C - биномиальный коэффициент.

pass^k - вероятность, что успешны все k попыток. Метрику предложила статья о τ-bench (Yao и соавторы, июнь 2024) для измерения надёжности агентов.

При k = 1 обе метрики равны доле успешных попыток. С ростом k pass@k приближается к 100 процентам, а pass^k - к нулю. Статья «Demystifying evals» приводит пример: при 75 процентах успеха на попытку вероятность, что три попытки подряд успешны, равна 0,75³, около 42 процентов.

В таблице обе метрики для независимых попыток с постоянной долей успеха на попытку p, посчитанные как 1 - (1 - p)^k и p^k.

pass@k подходит для сценария, где достаточно одного успеха, например когда разработчик может повторить запрос. pass^k подходит для сценария, где каждый запуск обязан быть успешным, например для агента, который обслуживает пользователей без надзора.

Метрики

В таблице - метрики, которые рекомендует собирать Anthropic, и на что они указывают для MCP-сервера.

Метрики сравнимы только на одном и том же наборе задач.

Матрица моделей и хостов

Модели по-разному выбирают инструменты. По данным Anthropic, даже схема имён инструментов, префикс или суффикс с названием сервиса, даёт разные результаты на разных моделях.

На результат влияет и хост, потому что он собирает контекст модели: какие инструменты видит модель, какой системный промпт их окружает, как обрабатываются длинные результаты. Пример - поле instructions в результате server/discover: по схеме клиент может его использовать, например добавить в системный промпт, но не обязан. Anthropic упоминает ещё одну особенность конкретного хоста: Claude Code по умолчанию ограничивает ответ инструмента 25 000 токенов.

Поэтому оценку проводят матрицей: группы задач в строках, сочетания модели и обвязки в столбцах. Пример показывает структуру; значения условные.

Число попыток растёт с каждой осью: тридцать задач по пять попыток на четырёх сочетаниях - 600 попыток. Сочетания выбирают по моделям и хостам, с которыми работают пользователи сервера.

Анализ стенограмм

Числа показывают, что что-то не так; стенограммы показывают почему. Anthropic рекомендует читать рассуждения и обратную связь агента, а затем сырые вызовы инструментов и результаты: то, что агент упустил, может значить больше, чем то, что он сделал. По статье «Demystifying evals», оценкам не доверяют, пока не прочитаны стенограммы.

В таблице - закономерности, описанные Anthropic, и изменения на стороне сервера, на которые они указывают.

Один из примеров в статье - инструмент веб-поиска Claude: модель без нужды дописывала «2025» в параметр query, и это искажало результаты. Исправило это изменение описания инструмента.

Сбой может вызвать и оценщик. В примере с CORE-Bench из статьи «Demystifying evals» Claude Opus 4.5 набирал 42 процента, пока не исправили ошибки проверки, и 95 процентов после; одна из ошибок отклоняла ответ «96.12» при эталоне «96.124991». Стенограммы неуспешных попыток отделяют ошибки агента от ошибок оценщика.

Устройство инструментов и результатов, к которому ведут эти закономерности, описано в статьях Инструменты (tools) в MCP и MCP-сервер поверх существующего API.

Отложенная выборка

Настройка описаний на тех же задачах, которые измеряют результат, ведёт к переобучению: описания улучшаются для этих задач, а не в целом. Поэтому Anthropic держит отложенную выборку (held-out set), которую не используют, пока меняют инструменты.

Статья «Demystifying evals» разделяет два назначения оценки:

• Оценка возможностей (capability eval) отвечает на вопрос, что агент умеет делать хорошо. Её доля успеха начинается с низкой и оставляет место для роста.
• Регрессионная оценка (regression eval) отвечает на вопрос, делает ли агент то, что делал раньше. Её доля успеха держится около 100 процентов.

Задача оценки возможностей, которая стабильно проходит, переходит в регрессионный набор. Набор, где проходят все задачи, показывает только регрессии, а не улучшения; статья называет это насыщением. Повторный запуск оценки после изменений сервера описан в статье Регрессионное тестирование MCP-сервера.

Малые выборки

Наборы задач для MCP-серверов обычно небольшие. Статья Anthropic «A statistical approach to model evaluations» (19 ноября 2024) и сопровождающая её работа «Adding Error Bars to Evals» рекомендуют:

• указывать при каждой оценке стандартную ошибку среднего; 95-процентный доверительный интервал - оценка плюс-минус 1,96 стандартной ошибки;
• кластеризовать стандартные ошибки, когда результаты не независимы, например при нескольких попытках одной задачи; по данным статьи, кластеризованные ошибки на популярных наборах могут быть больше наивных более чем в три раза;
• запускать несколько попыток на задачу и усреднять их;
• сравнивать две версии на одних и тех же задачах по парным разностям, что убирает разброс сложности задач;
• выбирать число задач с помощью анализа мощности.

Для доли успехов p на n задачах стандартная ошибка равна квадратному корню из p(1 - p) / n. При 80 процентах на 20 задачах это около 8,9 процентного пункта, а 95-процентный интервал - около плюс-минус 17,5 пункта. На 20 задачах одна задача меняет долю на 5 пунктов, поэтому 80 процентов против 90 на таком наборе сами по себе не показывают, что одна версия лучше.

Оценка, тестирование соответствия и модульные тесты

Таблица сравнивает три вида проверок, которые часто запускают на одном сервере.

Модульные тесты и тестирование соответствия отвечают, правилен ли сервер; оценка отвечает, может ли модель им пользоваться.

Виды проверок не заменяют друг друга. Дефект кода быстрее и дешевле находит модульный тест, дефект протокола - тестирование соответствия. Поэтому оценку запускают после того, как детерминированные проверки прошли.

Термины

Источники

• Writing effective tools for agents, Anthropic, 11 сентября 2025(откроется в новой вкладке) (на английском)
• Demystifying evals for AI agents, Anthropic, 9 января 2026(откроется в новой вкладке) (на английском)
• A statistical approach to model evaluations, Anthropic, 19 ноября 2024(откроется в новой вкладке) (на английском)
• Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations, E. Miller, arXiv:2411.00640(откроется в новой вкладке) (на английском)
• Evaluating Large Language Models Trained on Code, M. Chen и соавторы, arXiv:2107.03374(откроется в новой вкладке) (на английском)
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, S. Yao и соавторы, arXiv:2406.12045(откроется в новой вкладке) (на английском)
• MCP Server Evaluation Guide, скил mcp-builder, anthropics/skills, GitHub(откроется в новой вкладке) (на английском)
• Tools, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Discovery, спецификация 2026-07-28(откроется в новой вкладке) (на английском)