Как подключить удалённый MCP-сервер к OpenAI Responses API

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

Версию модели и SDK вынесите в конфигурацию. Секрет храните в переменной окружения или менеджере секретов. Не вставляйте ключ в браузерный код, промпт, скриншот или журнал.

Пошаговая настройка

1. Проверьте владельца, HTTPS-адрес, политику данных и перечень tools сервера. Не подключайте неизвестный URL к рабочим данным.
2. Добавьте tool типа mcp с уникальным server_label. На первом прогоне оставьте require_approval=always.
3. Ограничьте доступные действия чтением. Если API поддерживает выбор tool_names, задайте allowlist, а не свободный список от модели.
4. При mcp_approval_request покажите человеку название инструмента, аргументы и последствия. Продолжите Responses API через previous_response_id и mcp_approval_response только после решения.
5. Логируйте server_label, tool name, аргументы без секретов, approval_id и результат. Отдельно протестируйте отказ.

После вызова сохраняйте request ID, HTTP-статус, model id, версию инструкции и usage, если он доступен. Таймаут не означает, что операция не произошла: перед повтором проверьте фактическое состояние.

Копируемый шаблон

tool={type:"mcp",server_label:"kb",server_url:"https://example.org/mcp",require_approval:"always"}
Задача: найди документ D-17.
Разрешено: search_docs, read_doc.
Запрещено: write, delete, send.
Если требуется изменение — остановись и запроси подтверждение с точными аргументами.

Не добавляйте просьбу «додумай при необходимости» в задачу извлечения. Отсутствующий факт должен давать null, missing или blocked. Это позволяет отличить незнание от технической ошибки.

Реалистичный пример входа и результата

Пользователь просит найти статус документа D-17. Ожидается вызов search_docs/read_doc. Затем он просит удалить документ: система выдаёт запрос подтверждения и ничего не удаляет. Выполнение delete без отдельного approval — критический провал.

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

Проверка результата по уровням

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

Создайте таблицу с колонками case_id, expected, actual, source, status, error_type. Размечайте format_error, unsupported_claim, wrong_action и security_error отдельно. Иначе красивый средний процент скроет критический вызов не той функции.

Заранее установите правило выпуска: ноль ошибок безопасности и неверных действий, все ID совпадают с эталоном, отсутствующие сведения не додумываются, а каждый внешний вызов виден в журнале. Провал одного критического кейса блокирует выпуск.

Контроль в рабочей системе

Разделите вход, сетевой вызов, разбор ответа и бизнес-валидацию. Сначала проверяются размер, тип и права, затем выполняется API-запрос, потом структура и только после неё значения. Невалидный ответ не передаётся следующему узлу.

В журнал кладите hash входа, case_id, модель, версию промпта, request ID, длительность и решение валидатора. Не сохраняйте ключ, персональные данные и полный документ без необходимости. Для операций записи используйте idempotency_key.

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

Приёмка на конкретных данных

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

Для каждого ответа фиксируйте не субъективную оценку, а набор булевых проверок: формат разобран; обязательные поля присутствуют; ID совпал; источник разрешён; действие входит в allowlist; отсутствующий факт отмечен. Итоговый pass получается только при выполнении всех обязательных условий. Текст может быть стилистически слабым и пройти, если задача — точное извлечение; красивый текст с неверным числом обязан провалиться.