# Руководство по оценке серверов MCP

## Обзор

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

---

## Краткий справочник

### Требования к оценочным заданиям
- Создай 10 понятных человеку вопросов
- Вопросы должны быть ТОЛЬКО ДЛЯ ЧТЕНИЯ, НЕЗАВИСИМЫМИ, НЕРАЗРУШАЮЩИМИ
- Каждый вопрос требует нескольких вызовов инструментов (потенциально десятков)
- Ответы должны быть одиночными проверяемыми значениями
- Ответы должны быть СТАБИЛЬНЫМИ (не меняться со временем)

### Формат вывода
```xml
<evaluation>
   <qa_pair>
      <question>Твой вопрос здесь</question>
      <answer>Один проверяемый ответ</answer>
   </qa_pair>
</evaluation>
```

---

## Цель оценочных заданий

Качество сервера MCP определяется НЕ тем, насколько хорошо или полно сервер реализует инструменты, а тем, насколько хорошо эти реализации (схемы входных/выходных данных, строки документации/описания, функциональность) позволяют большим языковым моделям, не имеющим другого контекста и располагающим доступом ТОЛЬКО к серверам MCP, отвечать на реалистичные и сложные вопросы.

## Обзор оценки

Создай 10 понятных человеку вопросов, для ответа на которые требуются ТОЛЬКО операции ЧТЕНИЯ, НЕЗАВИСИМЫЕ, НЕРАЗРУШАЮЩИЕ и ИДЕМПОТЕНТНЫЕ. Каждый вопрос должен быть:
- Реалистичным
- Ясным и кратким
- Однозначным
- Сложным, потенциально требующим десятков вызовов инструментов или шагов
- Допускающим ответ в виде одного проверяемого значения, которое ты определяешь заранее

## Рекомендации по вопросам

### Основные требования

1. **Вопросы ДОЛЖНЫ быть независимыми**
   - Каждый вопрос НЕ должен зависеть от ответа на любой другой вопрос
   - Не должен предполагать предыдущих операций записи при обработке другого вопроса

2. **Вопросы ДОЛЖНЫ требовать ТОЛЬКО НЕРАЗРУШАЮЩЕГО И ИДЕМПОТЕНТНОГО использования инструментов**
   - Не должны предписывать или требовать изменения состояния для получения правильного ответа

3. **Вопросы должны быть РЕАЛИСТИЧНЫМИ, ЯСНЫМИ, КРАТКИМИ и СЛОЖНЫМИ**
   - Должны требовать от другой большой языковой модели использования нескольких (потенциально десятков) инструментов или шагов для ответа

### Сложность и глубина

4. **Вопросы должны требовать глубокого исследования**
   - Рассматривай многошаговые вопросы, требующие нескольких подвопросов и последовательных вызовов инструментов
   - Каждый шаг должен использовать пользу информации, найденной в предыдущих вопросах

5. **Вопросы могут требовать обширного постраничного просмотра**
   - Может понадобиться просмотр нескольких страниц результатов
   - Может потребоваться обращение к старым данным (устаревшим на 1–2 года), чтобы найти узкоспециализированную информацию
   - Вопросы должны быть ТРУДНЫМИ

6. **Вопросы должны требовать глубокого понимания**
   - А не поверхностных знаний
   - Можно формулировать сложные идеи как вопросы «True/False», требующие доказательств
   - Можно использовать формат выбора ответа, в котором большая языковая модель должна исследовать разные гипотезы

7. **Вопросы не должны решаться простым поиском по ключевым словам**
   - Не включай конкретные ключевые слова из искомого содержимого
   - Используй синонимы, связанные понятия или перефразирование
   - Требуй нескольких поисков, анализа нескольких связанных элементов, извлечения контекста, а затем вывода ответа

### Тестирование инструментов

8. **Вопросы должны подвергать возвращаемые инструментами значения стресс-тестированию**
   - Могут вызывать возврат инструментами больших JSON-объектов или списков, перегружая большую языковую модель
   - Должны требовать понимания нескольких видов данных:
     - Идентификаторы и имена
     - Временные метки и даты со временем (месяцы, дни, годы, секунды)
     - Идентификаторы файлов, имена, расширения и MIME-типы
     - URL, GID и т. д.
   - Должны проверять способность инструмента возвращать все полезные формы данных

9. **Вопросы должны В ОСНОВНОМ отражать реальные сценарии использования людьми**
   - Те виды задач поиска информации, которые важны ЛЮДЯМ, работающим с помощью большой языковой модели

10. **Вопросы могут требовать десятков вызовов инструментов**
    - Это создаёт трудности для больших языковых моделей с ограниченным контекстом
    - Побуждает инструменты сервера MCP сокращать возвращаемую информацию

11. **Включай неоднозначные вопросы**
    - Они могут быть неоднозначными ИЛИ требовать трудных решений о том, какие инструменты вызывать
    - Заставляй большую языковую модель потенциально ошибаться или неверно интерпретировать
    - Обеспечь, чтобы, несмотря на НЕОДНОЗНАЧНОСТЬ, ПО-ПРЕЖНЕМУ СУЩЕСТВОВАЛ ЕДИНСТВЕННЫЙ ПРОВЕРЯЕМЫЙ ОТВЕТ

### Стабильность

12. **Вопросы должны быть спроектированы так, чтобы ответ НЕ МЕНЯЛСЯ**
    - Не задавай вопросы, основанные на «текущем состоянии», которое динамично
    - Например, не подсчитывай:
      - Количество реакций на публикацию
      - Количество ответов в ветке
      - Количество участников канала

13. **НЕ позволяй серверу MCP ОГРАНИЧИВАТЬ виды создаваемых вопросов**
    - Создавай трудные и сложные вопросы
    - Некоторые из них могут быть неразрешимы доступными инструментами сервера MCP
    - Вопросы могут требовать конкретных форматов вывода (дата и время или время эпохи, JSON или MARKDOWN)
    - Для решения вопросов могут потребоваться десятки вызовов инструментов

## Рекомендации по ответам

### Проверка

1. **Ответы должны быть ПРОВЕРЯЕМЫМИ прямым сравнением строк**
   - Если ответ можно записать в разных форматах, ясно укажи формат вывода в ВОПРОСЕ
   - Примеры: «Используй YYYY/MM/DD», «Ответь True или False», «Ответь A, B, C или D и ничего больше».
   - Ответ должен быть одним ПРОВЕРЯЕМЫМ значением, например:
     - Идентификатор пользователя, имя пользователя, отображаемое имя, личное имя, фамилия
     - Идентификатор канала, имя канала
     - Идентификатор сообщения, строка
     - URL, заголовок
     - Числовая величина
     - Временная метка, дата и время
     - Логическое значение (для вопросов True/False)
     - Адрес электронной почты, номер телефона
     - Идентификатор файла, имя файла, расширение файла
     - Ответ с выбором варианта
   - Ответы не должны требовать специального форматирования или сложного структурированного вывода
   - Ответ будет проверяться ПРЯМЫМ СРАВНЕНИЕМ СТРОК

### Удобочитаемость

2. **В ответах обычно следует предпочитать УДОБОЧИТАЕМЫЕ ДЛЯ ЧЕЛОВЕКА форматы**
   - Примеры: имена, личное имя, фамилия, дата и время, имя файла, строка сообщения, URL, yes/no, true/false, a/b/c/d
   - Вместо непрозрачных идентификаторов (хотя идентификаторы допустимы)
   - ПОДАВЛЯЮЩЕЕ БОЛЬШИНСТВО ответов должно быть удобно для чтения человеком

### Стабильность

3. **Ответы должны быть СТАБИЛЬНЫМИ/НЕИЗМЕННЫМИ**
   - Изучай старое содержимое (например, завершившиеся разговоры, запущенные проекты, вопросы с полученными ответами)
   - Создавай ВОПРОСЫ на основе «закрытых» понятий, для которых ответ всегда будет одним и тем же
   - Вопросы могут требовать рассмотрения фиксированного временного окна, чтобы исключить изменчивость ответов
   - Опирайся на контекст, который ВРЯД ЛИ изменится
   - Пример: если нужно найти название научной работы, будь ДОСТАТОЧНО КОНКРЕТЕН, чтобы ответ нельзя было спутать с работами, опубликованными позже

4. **Ответы должны быть ЯСНЫМИ и ОДНОЗНАЧНЫМИ**
   - Вопросы должны быть спроектированы так, чтобы существовал единственный ясный ответ
   - Ответ можно получить с помощью инструментов сервера MCP

### Разнообразие

5. **Ответы должны быть РАЗНООБРАЗНЫМИ**
   - Ответ должен быть одним ПРОВЕРЯЕМЫМ значением разных видов и форматов
   - Понятие пользователя: идентификатор пользователя, имя пользователя, отображаемое имя, личное имя, фамилия, адрес электронной почты, номер телефона
   - Понятие канала: идентификатор канала, имя канала, тема канала
   - Понятие сообщения: идентификатор сообщения, строка сообщения, временная метка, месяц, день, год

6. **Ответы НЕ должны быть сложными структурами**
   - Не список значений
   - Не сложный объект
   - Не список идентификаторов или строк
   - Не текст на естественном языке
   - ЕСЛИ ТОЛЬКО ответ нельзя однозначно проверить ПРЯМЫМ СРАВНЕНИЕМ СТРОК
   - И реалистично воспроизвести
   - Должно быть маловероятно, что большая языковая модель вернёт тот же список в другом порядке или формате

## Процесс оценки

### Шаг 1: изучение документации

Прочитай документацию целевого API, чтобы понять:
- Доступные конечные точки и функциональность
- При наличии неоднозначности получи дополнительную информацию из интернета
- Распараллель этот шаг НАСКОЛЬКО ВОЗМОЖНО
- Убедись, что каждый субагент ТОЛЬКО изучает документацию из файловой системы или интернета

### Шаг 2: изучение инструментов

Перечисли инструменты, доступные на сервере MCP:
- Изучи сервер MCP напрямую
- Разберись в схемах входных/выходных данных, строках документации и описаниях
- БЕЗ вызова самих инструментов на этом этапе

### Шаг 3: углубление понимания

Повторяй шаги 1 и 2, пока не получишь хорошее понимание:
- Выполни несколько итераций
- Подумай о видах задач, которые хочешь создать
- Уточняй своё понимание
- НИ НА КАКОМ этапе не следует ЧИТАТЬ код самой реализации сервера MCP
- Используй интуицию и понимание, чтобы создавать разумные, реалистичные, но ОЧЕНЬ трудные задачи

### Шаг 4: изучение содержимого только для чтения

Разобравшись в API и инструментах, ИСПОЛЬЗУЙ инструменты сервера MCP:
- Изучай содержимое ТОЛЬКО с помощью операций ЧТЕНИЯ и НЕРАЗРУШАЮЩИХ операций
- Цель: выявить конкретное содержимое (например, пользователей, каналы, сообщения, проекты, задачи) для создания реалистичных вопросов
- НЕ следует вызывать инструменты, изменяющие состояние
- НЕ читать код самой реализации сервера MCP
- Распараллель этот шаг, направляя отдельных субагентов на независимые исследования
- Убедись, что каждый субагент выполняет только операции ЧТЕНИЯ, НЕРАЗРУШАЮЩИЕ и ИДЕМПОТЕНТНЫЕ операции
- БУДЬ ОСТОРОЖЕН: НЕКОТОРЫЕ ИНСТРУМЕНТЫ могут возвращать МНОГО ДАННЫХ, из-за чего закончится КОНТЕКСТ
- Для исследования делай ПОСТЕПЕННЫЕ, НЕБОЛЬШИЕ И ЦЕЛЕВЫЕ вызовы инструментов
- Во всех запросах вызова инструментов используй параметр `limit` для ограничения результатов (<10)
- Используй пагинацию

### Шаг 5: генерация задач

После изучения содержимого создай 10 понятных человеку вопросов:
- Большая языковая модель должна иметь возможность ответить на них с помощью сервера MCP
- Следуй всем приведённым выше рекомендациям по вопросам и ответам

## Формат вывода

Каждая пара QA состоит из вопроса и ответа. Результат должен быть XML-файлом со следующей структурой:

```xml
<evaluation>
   <qa_pair>
      <question>Найди созданный во втором квартале 2024 года проект с наибольшим числом завершённых задач. Как называется проект?</question>
      <answer>Website Redesign</answer>
   </qa_pair>
   <qa_pair>
      <question>Найди задачи с меткой "bug", закрытые в марте 2024 года. Какой пользователь закрыл больше всего задач? Укажи его имя пользователя.</question>
      <answer>sarah_dev</answer>
   </qa_pair>
   <qa_pair>
      <question>Найди запросы на включение изменений, которые изменяли файлы в каталоге /api и были объединены в период с 1 по 31 января 2024 года. Сколько разных участников работало над этими PR?</question>
      <answer>7</answer>
   </qa_pair>
   <qa_pair>
      <question>Найди репозиторий с наибольшим числом звёзд, созданный до 2023 года. Как называется репозиторий?</question>
      <answer>data-pipeline</answer>
   </qa_pair>
</evaluation>
```

## Примеры оценочных заданий

### Хорошие вопросы

**Пример 1: многошаговый вопрос, требующий глубокого исследования (GitHub MCP)**
```xml
<qa_pair>
   <question>Найди репозиторий, который был архивирован в третьем квартале 2023 года и до этого был проектом с наибольшим числом форков в организации. Какой основной язык программирования использовался в этом репозитории?</question>
   <answer>Python</answer>
</qa_pair>
```

Этот вопрос хорош, потому что:
- Требует нескольких поисков для обнаружения архивированных репозиториев
- Нужно определить, у какого из них было больше всего форков до архивирования
- Требует изучения сведений о репозитории для определения языка
- Ответ — простое проверяемое значение
- Основан на исторических («закрытых») данных, которые не изменятся

**Пример 2: требует понимания контекста без совпадения ключевых слов (MCP для управления проектами)**
```xml
<qa_pair>
   <question>Найди инициативу, направленную на улучшение первоначального знакомства клиентов с продуктом и завершённую в конце 2023 года. После завершения руководитель проекта создал ретроспективный документ. Как называлась должность руководителя на тот момент?</question>
   <answer>Product Manager</answer>
</qa_pair>
```

Этот вопрос хорош, потому что:
- Не использует конкретное название проекта («инициатива, направленная на улучшение первоначального знакомства клиентов с продуктом»)
- Требует найти завершённые проекты за определённый период
- Нужно определить руководителя проекта и его должность
- Требует понимания контекста из ретроспективных документов
- Ответ удобочитаем для человека и стабилен
- Основан на завершённой работе (не изменится)

**Пример 3: сложное агрегирование, требующее нескольких шагов (MCP для трекера задач)**
```xml
<qa_pair>
   <question>Среди всех ошибок, о которых сообщили в январе 2024 года и которым назначили критический приоритет, какой исполнитель устранил наибольшую долю назначенных ему ошибок в течение 48 часов? Укажи имя пользователя исполнителя.</question>
   <answer>alex_eng</answer>
</qa_pair>
```

Этот вопрос хорош, потому что:
- Требует фильтрации ошибок по дате, приоритету и статусу
- Нужно сгруппировать по исполнителю и рассчитать доли устранённых ошибок
- Требует понимания временных меток для определения 48-часовых окон
- Проверяет пагинацию (потенциально нужно обработать много ошибок)
- Ответ — одно имя пользователя
- Основан на исторических данных за определённый период

**Пример 4: требует обобщения нескольких типов данных (CRM MCP)**
```xml
<qa_pair>
   <question>Найди клиентский аккаунт, который перешёл с тарифа Starter на Enterprise в четвёртом квартале 2023 года и имел наибольшую годовую стоимость контракта. В какой отрасли работает этот клиент?</question>
   <answer>Healthcare</answer>
</qa_pair>
```

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

### Плохие вопросы

**Пример 1: ответ меняется со временем**
```xml
<qa_pair>
   <question>Сколько открытых задач сейчас назначено команде разработки?</question>
   <answer>47</answer>
</qa_pair>
```

Этот вопрос плох, потому что:
- Ответ будет меняться по мере создания, закрытия или переназначения задач
- Не основан на стабильных/неизменных данных
- Зависит от «текущего состояния», которое динамично

**Пример 2: слишком легко решается поиском по ключевым словам**
```xml
<qa_pair>
   <question>Найди запрос на включение изменений с заголовком "Add authentication feature" и скажи, кто его создал.</question>
   <answer>developer123</answer>
</qa_pair>
```

Этот вопрос плох, потому что:
- Может решаться простым поиском по ключевым словам точного заголовка
- Не требует глубокого исследования или понимания
- Не требует обобщения или анализа

**Пример 3: неоднозначный формат ответа**
```xml
<qa_pair>
   <question>Перечисли все репозитории, в которых Python является основным языком.</question>
   <answer>repo1, repo2, repo3, data-pipeline, ml-tools</answer>
</qa_pair>
```

Этот вопрос плох, потому что:
- Ответ — список, который можно вернуть в любом порядке
- Его трудно проверить прямым сравнением строк
- Большая языковая модель может оформить его иначе (массив JSON, разделение запятыми, разделение переносами строк)
- Лучше запросить конкретное агрегированное значение (количество) или максимум (больше всего звёзд)

## Процесс проверки

После создания оценочных заданий:

1. **Изучи XML-файл**, чтобы понять схему
2. **Загрузи инструкцию каждой задачи** и параллельно с помощью сервера MCP и инструментов определи правильный ответ, пытаясь решить задачу САМОСТОЯТЕЛЬНО
3. **Отметь любые операции**, требующие ЗАПИСИ или РАЗРУШАЮЩИХ действий
4. **Собери все ПРАВИЛЬНЫЕ ответы** и замени все неправильные ответы в документе
5. **Удали любые `<qa_pair>`**, требующие ЗАПИСИ или РАЗРУШАЮЩИХ действий

Не забудь распараллелить решение задач, чтобы не исчерпать контекст, затем собери все ответы и в конце внеси изменения в файл.

## Советы по созданию качественных оценочных заданий

1. **Тщательно обдумай и заранее спланируй** перед генерацией задач
2. **Распараллеливай при возможности**, чтобы ускорить процесс и управлять контекстом
3. **Сосредоточься на реалистичных сценариях использования**, которые люди действительно хотели бы выполнить
4. **Создавай трудные вопросы**, проверяющие пределы возможностей сервера MCP
5. **Обеспечивай стабильность**, используя исторические данные и закрытые понятия
6. **Проверяй ответы**, самостоятельно решая вопросы с помощью инструментов сервера MCP
7. **Повторяй и уточняй** на основе того, что узнаёшь в процессе

---

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

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

## Настройка

1. **Установи зависимости**

   ```bash
   pip install -r scripts/requirements.txt
   ```

   Или установи вручную:
   ```bash
   pip install anthropic mcp
   ```

2. **Задай ключ API**

   ```bash
   export ANTHROPIC_API_KEY=your_api_key_here
   ```

## Формат файла оценочных заданий

Файлы оценочных заданий используют формат XML с элементами `<qa_pair>`:

```xml
<evaluation>
   <qa_pair>
      <question>Найди созданный во втором квартале 2024 года проект с наибольшим числом завершённых задач. Как называется проект?</question>
      <answer>Website Redesign</answer>
   </qa_pair>
   <qa_pair>
      <question>Найди задачи с меткой "bug", закрытые в марте 2024 года. Какой пользователь закрыл больше всего задач? Укажи его имя пользователя.</question>
      <answer>sarah_dev</answer>
   </qa_pair>
</evaluation>
```

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

Скрипт оценки (`scripts/evaluation.py`) поддерживает три типа транспорта:

**Важно:**
- **Транспорт stdio**: скрипт оценки автоматически запускает процесс сервера MCP и управляет им за тебя. Не запускай сервер вручную.
- **Транспорты sse/http**: перед запуском оценки необходимо отдельно запустить сервер MCP. Скрипт подключается к уже работающему серверу по указанному URL.

### 1. Локальный сервер STDIO

Для локально работающих серверов MCP (скрипт запускает сервер автоматически):

```bash
python scripts/evaluation.py \
  -t stdio \
  -c python \
  -a my_mcp_server.py \
  evaluation.xml
```

С переменными окружения:
```bash
python scripts/evaluation.py \
  -t stdio \
  -c python \
  -a my_mcp_server.py \
  -e API_KEY=abc123 \
  -e DEBUG=true \
  evaluation.xml
```

### 2. Server-Sent Events (SSE)

Для серверов MCP на основе SSE (сначала необходимо запустить сервер):

```bash
python scripts/evaluation.py \
  -t sse \
  -u https://example.com/mcp \
  -H "Authorization: Bearer token123" \
  -H "X-Custom-Header: value" \
  evaluation.xml
```

### 3. HTTP (потоковый HTTP)

Для серверов MCP на основе HTTP (сначала необходимо запустить сервер):

```bash
python scripts/evaluation.py \
  -t http \
  -u https://example.com/mcp \
  -H "Authorization: Bearer token123" \
  evaluation.xml
```

## Параметры командной строки

```
usage: evaluation.py [-h] [-t {stdio,sse,http}] [-m MODEL] [-c COMMAND]
                     [-a ARGS [ARGS ...]] [-e ENV [ENV ...]] [-u URL]
                     [-H HEADERS [HEADERS ...]] [-o OUTPUT]
                     eval_file

positional arguments:
  eval_file             Path to evaluation XML file

optional arguments:
  -h, --help            Show help message
  -t, --transport       Transport type: stdio, sse, or http (default: stdio)
  -m, --model           Claude model to use (default: claude-3-7-sonnet-20250219)
  -o, --output          Output file for report (default: print to stdout)

stdio options:
  -c, --command         Command to run MCP server (e.g., python, node)
  -a, --args            Arguments for the command (e.g., server.py)
  -e, --env             Environment variables in KEY=VALUE format

sse/http options:
  -u, --url             MCP server URL
  -H, --header          HTTP headers in 'Key: Value' format
```

## Вывод

Скрипт оценки создаёт подробный отчёт, включающий:

- **Сводную статистику**:
  - Точность (правильных/всего)
  - Среднюю продолжительность задачи
  - Среднее число вызовов инструментов на задачу
  - Общее число вызовов инструментов

- **Результаты по каждой задаче**:
  - Промпт и ожидаемый ответ
  - Фактический ответ агента
  - Был ли ответ правильным (✅/❌)
  - Продолжительность и сведения о вызовах инструментов
  - Краткое изложение агентом своего подхода
  - Отзыв агента об инструментах

### Сохрани отчёт в файл

```bash
python scripts/evaluation.py \
  -t stdio \
  -c python \
  -a my_server.py \
  -o evaluation_report.md \
  evaluation.xml
```

## Полный пример рабочего процесса

Вот полный пример создания и запуска оценки:

1. **Создай свой файл оценочных заданий** (`my_evaluation.xml`):

```xml
<evaluation>
   <qa_pair>
      <question>Найди пользователя, создавшего больше всего задач в январе 2024 года. Каково его имя пользователя?</question>
      <answer>alice_developer</answer>
   </qa_pair>
   <qa_pair>
      <question>Среди всех запросов на включение изменений, объединённых в первом квартале 2024 года, в каком репозитории их было больше всего? Укажи имя репозитория.</question>
      <answer>backend-api</answer>
   </qa_pair>
   <qa_pair>
      <question>Найди проект, который был завершён в декабре 2023 года и имел наибольшую продолжительность от начала до конца. Сколько дней он занял?</question>
      <answer>127</answer>
   </qa_pair>
</evaluation>
```

2. **Установи зависимости**:

```bash
pip install -r scripts/requirements.txt
export ANTHROPIC_API_KEY=your_api_key
```

3. **Запусти оценку**:

```bash
python scripts/evaluation.py \
  -t stdio \
  -c python \
  -a github_mcp_server.py \
  -e GITHUB_TOKEN=ghp_xxx \
  -o github_eval_report.md \
  my_evaluation.xml
```

4. **Изучи отчёт** в `github_eval_report.md`, чтобы:
   - Увидеть, какие вопросы пройдены/не пройдены
   - Прочитать отзыв агента о твоих инструментах
   - Выявить области для улучшения
   - Доработать проектирование сервера MCP

## Устранение неполадок

### Ошибки соединения

При ошибках соединения:
- **STDIO**: проверь правильность команды и аргументов
- **SSE/HTTP**: проверь доступность URL и правильность заголовков
- Убедись, что необходимые ключи API заданы в переменных окружения или заголовках

### Низкая точность

Если многие оценочные задания не проходят:
- Изучи отзыв агента по каждой задаче
- Проверь, ясны ли и полны ли описания инструментов
- Убедись, что входные параметры хорошо документированы
- Подумай, не возвращают ли инструменты слишком много или слишком мало данных
- Убедись, что сообщения об ошибках подсказывают конкретные действия

### Проблемы с тайм-аутами

Если время выполнения задач истекает:
- Используй более способную модель (например, `claude-3-7-sonnet-20250219`)
- Проверь, не возвращают ли инструменты слишком много данных
- Убедись, что пагинация работает корректно
- Рассмотри упрощение сложных вопросов