Как тестировать MCP-интеграцию на примерах реальных рабочих задач

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

Запишите сценарий как вход и инварианты

Для инструмента чтения обращения фикстура содержит пользователя, ticket_id, состояние исходной системы и ожидаемые свойства ответа. Инвариант — условие, которое должно выполняться независимо от формулировки модели. Например, ID результата совпадает с запрошенным; закрытые комментарии отсутствуют; ответственный соответствует текущему состоянию.

Храните в фикстурах только искусственные или разрешённые обезличенные данные. Для проверки доступа удобно создать две команды и обращения каждой из них. Тогда случайное расширение выборки станет видимой ошибкой, а тест не потребует подключения к рабочей CRM.

Проверьте три слоя отдельно

Первый слой — бизнес-адаптер, который получает данные и собирает результат. Второй — MCP-контракт: tools/list показывает нужную схему, tools/call принимает аргументы и возвращает согласованный объект. Третий — поведение агента: по вопросу сотрудника выбран подходящий инструмент, а ответ опирается на его результат.

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

Проверьте содержательные условия локально

Пример ниже представляет первый слой. Тестируется выбор обращения, проверка команды пользователя и исключение внутреннего комментария. Результат выводится после прохождения условий. В серверном наборе те же фикстуры используйте при вызовах через MCP-клиент, добавив проверки JSON-RPC и схемы.

tickets = {"T-1": {"team": "support", "status": "open", "internal_note": "private"}}
def read_ticket(ticket_id, team):
    ticket = tickets.get(ticket_id)
    if not ticket or ticket["team"] != team:
        return {"state": "unavailable"}
    return {"state": "found", "ticket_id": ticket_id, "status": ticket["status"]}
result = read_ticket("T-1", "support")
assert result["ticket_id"] == "T-1" and result["status"] == "open"
assert "internal_note" not in result
assert read_ticket("T-1", "sales") == {"state": "unavailable"}
assert read_ticket("missing", "support") == {"state": "unavailable"}
print({"result": result, "checks": 4})

Включите неудобные состояния

Проверьте пустую историю, неизвестный ID, недоступный источник и обращение с несколькими передачами. «Нет событий» и «сервис истории не ответил» должны давать разные результаты. Сотрудник по-разному действует в этих ситуациях.

Не привязывайте тест финального ответа к одной точной фразе. Проверяйте факты и отсутствие недопустимых утверждений. Для сценария передачи дежурному важнее правильный ответственный и незавершённая задача, чем порядок предложений. Смысловые оценки модели храните отдельно от детерминированных проверок адаптера.

Запускайте набор при изменении исходного API, преобразования статусов, схемы tools и правил доступа. В отчёте указывайте, какой слой проверялся и на каких фикстурах. Успешный локальный тест бизнес-функции не следует называть проверкой совместимости с клиентом.

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

Продолжить проект на практике

Следующий этап после бизнес-фикстур — проверить интеграцию через настоящий MCP-клиент. В платном курсе AI Agent Integrations PRO: MCP вы пройдёте discovery, tool call и обработку результата, добавите тесты и логи. Это помогает связать предметные условия с серверным контрактом и получать объяснимый результат приёмки.

Откройте программу курса и выберите следующий этап своего проекта.

По теме: Структурированный ответ MCP tool: как не потерять типы данных.