MCP для Codex: как подключить инструменты и не выдать агенту всю компанию
Codex становится намного полезнее, когда может работать не только с текстом и файлами, но и с реальными инструментами: GitHub, почтой, документами, базами знаний, браузером, внутренними сервисами. Но здесь появляется опасный соблазн: подключить все сразу и назвать это автоматизацией. Так делать не надо.
В официальной документации OpenAI по Model Context Protocol в Codex описано, что Codex поддерживает MCP-серверы, включая локальные STDIO-серверы, HTTP-серверы, переменные окружения, bearer token и OAuth-аутентификацию. Конфигурация хранится в config.toml, а серверы можно настраивать глобально или в проекте. Для бизнеса в этом важна не аббревиатура MCP, а принцип: Codex получает интерфейсы к миру, и каждый интерфейс должен быть ограничен задачей.
MCP - это не "дать агенту все руки". Это способ аккуратно описать, какие руки ему вообще нужны.
Инструмент без границы превращается в риск
Если Codex должен проверить pull request, ему может понадобиться GitHub. Если нужно собрать источники для статьи, может понадобиться Google Drive или локальная папка. Если нужно проверить очередь публикаций, нужен доступ к статусам. Но "доступ к GitHub", "доступ к Drive" и "доступ к публикациям" - слишком широкие формулировки.
Правильный вопрос:
Какое действие нужно Codex, по какому источнику, с каким правом и где он обязан остановиться?
Таблица сразу делает разговор трезвым:
| Инструмент | Зачем нужен | Разрешено | Запрещено |
|---|---|---|---|
| GitHub | читать PR и статусы | смотреть diff, проверки, комментарии | merge без человека |
| Google Drive | читать исходники статьи | открыть нужный документ, извлечь тезисы | менять клиентский документ без approval |
| Публикационная очередь | сверить статусы | читать sent/failed/scheduled | direct-send в обход очереди |
| База знаний | найти правила проекта | читать утвержденные материалы | переписывать правила без review |
Так MCP становится картой доступа, а не тайной технической дверью.
Что должен проверить не-программист
Не-программист не обязан редактировать config.toml. Но он обязан понимать, что подключается.
Проверка простая:
- У каждого MCP-сервера есть понятная рабочая задача.
- Понятно, какие данные он дает Codex.
- Понятно, какие действия он позволяет выполнить.
- Опасные действия вынесены в человеческое подтверждение.
- Секреты не лежат в статье, промпте или публичном файле.
Если инструмент нельзя объяснить в такой карточке, его рано подключать.
MCP и permissions должны идти рядом
Документация Codex по permissions отдельно показывает профили доступа: read-only, workspace и danger-full-access. Это другой слой, но для владельца проекта он связан с MCP напрямую. Можно подключить полезный инструмент, но дать ему слишком широкую среду. Можно ограничить файловую систему, но забыть, что внешний инструмент выполняет опасное действие.
Поэтому карта доступа должна быть двойной:
| Слой | Что ограничивает |
|---|---|
| Permissions | где Codex может читать и писать локально |
| MCP | к каким внешним инструментам Codex подключается |
| Rules/hooks | какие действия требуют проверки или блокируются |
| Human approval | какие решения не автоматизируются |
Один слой не заменяет другой. Без permissions агент может слишком свободно работать с файлами. Без MCP он может не иметь нужных данных. Без approval он может сделать правильный технический шаг в неправильный бизнес-момент.
Как написать карту MCP для Codex
Шаблон:
Codex можно подключать к [инструмент]. Цель: [зачем]. Можно читать: [данные]. Можно делать: [действия]. Нельзя: [опасные операции]. Если нужен секрет, остановиться и запросить настройку через безопасный канал. После действия вернуть журнал: что прочитал, что вызвал, какой результат получил, что требует решения человека.
Этот шаблон скучный, но он спасает от главной ошибки: подключить инструмент ради чувства мощности.
Где MCP действительно нужен
MCP стоит использовать, когда Codex без внешнего инструмента вынужден имитировать работу. Например, пересказывать статус задачи без доступа к задаче, угадывать состояние публикации без очереди, проверять документ по копипасте вместо источника, обещать действие в сервисе, где он ничего не может выполнить.
Но если задача решается обычным файлом, папкой, инструкцией или skill, MCP может быть лишним. Каждый новый инструмент увеличивает поверхность риска. Хорошая архитектура начинается с маленького набора: один источник данных, одно безопасное действие, один понятный отчет.
Где остается человек
Codex может вызвать инструмент, получить данные, собрать отчет и предложить действие. Но человек решает, какие сервисы подключать, какие права выдавать, какие операции считать безопасными и где нужен запрет.
MCP для Codex - это не магия интеграций. Это договор: вот что агенту можно видеть, вот что можно делать, вот где он обязан остановиться. Если такого договора нет, подключение инструмента не ускоряет работу. Оно просто ускоряет последствия ошибки.