MCP и plugins: подключение Codex к внешним системам

Код и инструкции часто находятся в репозитории, а актуальные задачи, дизайн, документация и логи — вне его. Model Context Protocol подключает модель к инструментам и контексту.

Краткий ответ

Код и инструкции часто находятся в репозитории, а актуальные задачи, дизайн, документация и логи — вне его. Model Context Protocol подключает модель к инструментам и контексту.

Код и инструкции часто находятся в репозитории, а актуальные задачи, дизайн, документация и логи — вне его. Model Context Protocol подключает модель к инструментам и контексту. Plugin может упаковать skills, MCP-подключения и другие ресурсы для установки как одного продукта.

Что решает каждый слой

Разделяйте ответственность:

Если агенту нужно каждый раз читать актуальный issue из GitHub, копировать его в AGENTS.md неправильно. Нужен разрешённый connector или MCP. Если данные уже в репозитории, внешний сервер может быть лишним.

Выбор интеграции по данным

Перед подключением спросите:

1. Данные живые или достаточно снимка? 2. Требуется только чтение или внешнее изменение? 3. Кто выполняет аутентификацию и авторизацию? 4. Какие tools действительно нужны для сценария? 5. Как обрабатываются timeout, недоступность и частичный ответ? 6. Какие действия требуют подтверждения?

Начинайте с одного-двух инструментов, которые убирают конкретный ручной цикл. Большой каталог tools усложняет выбор и увеличивает поверхность риска.

Возможности MCP в Codex

Официальная документация описывает локальные STDIO-серверы и Streamable HTTP-серверы. HTTP-вариант может использовать bearer token или OAuth. Конфигурация хранится в config.toml и может быть пользовательской либо проектной для доверенного репозитория.

Codex CLI предоставляет команды семейства codex mcp для добавления, списка и входа в серверы. Конкретные параметры следует брать из актуального справочника, а секреты передавать через предусмотренные переменные или OAuth, а не записывать в открытый проектный файл.

Политика инструментов

Инструмент должен иметь узкую схему и понятное действие. Для MCP можно ограничить enabled/disabled tools и настроить approval behavior. Отдельно задавайте правила для чтения и записи.

Пример безопасного рабочего контракта:

Используй подключённый трекер только для чтения issue PROJ-42.
Сопоставь acceptance criteria с текущим diff и верни пробелы.
Не меняй issue, статус, assignee или комментарии.
Если данных недостаточно, перечисли отсутствующие поля.

Наличие write-tool не является разрешением его вызывать.

Ошибки интеграции

Диагностируйте по слоям:

1. plugin установлен и включён; 2. MCP server стартует или доступен по URL; 3. аутентификация завершена; 4. workspace policy разрешает сервер и tool; 5. требуемый tool присутствует в allowlist; 6. сессия перезапущена после изменения конфигурации; 7. timeout соответствует реальной операции.

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

Практика: дизайн одного MCP-сценария

Выберите задачу «проверить реализацию по макету». Опишите:

Проверьте, что MCP отвечает за данные, а skill — за последовательность анализа.

Частые вопросы

MCP и plugin — это одно и то же?

Нет. MCP — протокол подключения к инструментам и данным. Plugin — устанавливаемый пакет, который может включать MCP-настройки, skills и дополнительные ресурсы.

Нужно ли подключать MCP ради статичной документации проекта?

Обычно нет. Если документ version-controlled и меняется вместе с кодом, хранение рядом с проектом проще и воспроизводимее. MCP ценен для внешних и меняющихся источников.

Может ли project config содержать токен?

Секрет нельзя коммитить в открытый config. Используйте поддерживаемую аутентификацию, OAuth или ссылки на переменные окружения и секрет-хранилище.

Что важно запомнить

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-13