MCP на практике: браузер, GitLab, база, документация

В прошлом уроке разобрали, как MCP-сервер попадает в Codex: команда codex mcp add, таблица [mcp_servers.<имя>], транспорты STDIO и Streamable HTTP. Теперь — практика: четыре подключения, которые окупаются в обычном веб-проекте, и то, как сузить каждое до нужного минимума. Каждый сервер — это новые возможности агента и одновременно новая дверь наружу, поэтому настройка безопасности здесь не приложение к уроку, а его половина.

Прежде чем подключать: три вопроса

Перед каждым сервером ответьте себе:

1. Что он умеет делать? Читать или ещё и менять: создавать MR, писать в базу, отправлять формы.
2. Чьими правами? Токен с какими скоупами, пользователь БД с какими грантами.
3. Что он приносит в контекст? Страницы сайтов, комментарии в MR, строки из таблиц — всё это данные, написанные не вами. В них может оказаться текст, который выглядит как инструкция для агента (prompt injection).

Важная деталь из устройства Codex: песочница ограничивает команды оболочки, которые запускает агент, но MCP-сервер — отдельный процесс со своими правами. Фильтрующий сетевой прокси песочницы тоже не распространяется на MCP, браузер и Computer Use. Значит, ограничения для MCP задаются в двух местах: в настройках самого сервера (токен, режим только для чтения) и в настройках Codex (какие инструменты видны и какие требуют одобрения).

Ключи enabled_tools, disabled_tools, default_tools_approval_mode и tools.<инструмент>.approval_mode разобраны в прошлом уроке. Ниже они применяются к каждому серверу; чаще всего пригодится режим writes — он спрашивает подтверждение для инструментов, которые не помечены как read-only. Инструменты, помеченные сервером как деструктивные, Codex выполняет только после одобрения, если сервер не пометил их заодно как read-only.

Браузер: Playwright MCP или встроенный браузер

Для вёрстки и e2e агенту нужно видеть страницу. Есть два пути.

Playwright MCP работает в CLI, IDE и десктопе. Сервер управляет браузером через дерево доступности (accessibility tree), а не по пикселям, — агенту проще находить кнопки и поля.

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest", "--isolated"]
startup_timeout_sec = 30

Флаг --isolated держит профиль браузера в памяти: никаких сохранённых cookie между сессиями, и несколько агентов не конфликтуют за один профиль. Скриншоты, PDF и инструменты DevTools включаются отдельно через --caps; полный список флагов — в README Playwright MCP.

Две оговорки из того же README. Первая: Playwright MCP прямо назван «не границей безопасности», и --allowed-origins тоже ею не является. Вторая: для кодинг-агентов авторы советуют присмотреться к Playwright CLI в связке с навыками — это экономнее по контексту, чем гонять через модель большие деревья доступности. MCP удобнее для длинной исследовательской работы с сохранением состояния.

Встроенный браузер есть только в режиме Codex десктопного приложения ChatGPT, в CLI и IDE его нет. Он работает в отдельном профиле без ваших обычных cookie, поддерживает комментарии прямо на странице и вызывается через @Browser. Загрузку файлов автоматизировать нельзя; режим разработчика с полным доступом к Chrome DevTools Protocol требует отдельного одобрения. Подробности — в документации по браузеру.

В обоих случаях правило одно: агент ходит на локальный стенд или тестовое окружение, а не на прод с настоящими данными клиента. Как строить на этом e2e-проверки, разобрано в уроке «Браузер в руках агента».

GitLab: официальный MCP-сервер

У GitLab есть собственный MCP-сервер по адресу /api/v4/mcp вашего инстанса. По документации GitLab, он вышел в general availability в версии 19.5 (до этого был beta и experiment) и доступен на всех тарифах GitLab, включая Self-Managed. Версию своего инстанса уточните у администратора.

codex mcp add gitlab --url "https://git.example.com/api/v4/mcp"
codex mcp login gitlab

Вторая команда открывает браузер для OAuth со скоупом mcp. Старые personal access tokens сервер отклоняет — нужен OAuth или fine-grained токен.

Дальше сужаем. GitLab группирует инструменты в наборы (toolsets) и принимает их список в заголовке. Codex умеет передавать статические заголовки через http_headers:

[mcp_servers.gitlab]
url = "https://git.example.com/api/v4/mcp"
http_headers = { "X-Gitlab-Enabled-Mcp-Server-Toolsets" = "core,merge_requests,ci" }
default_tools_approval_mode = "writes"
tool_timeout_sec = 90

Так агент видит MR и пайплайны, но не вики и не отчёты безопасности, а любое изменение — комментарий в MR, новая задача — проходит через ваше подтверждение. В инструкции GitLab для Codex встречается флаг rmcp_client в [features]; в текущем справочнике конфигурации Codex такого ключа нет, HTTP-транспорт работает штатно.

Риск здесь конкретный. Описание MR и комментарии пишут люди, в том числе внешние контрибьюторы, и GitLab в своей документации прямо перекладывает защиту от prompt injection на пользователя. Работайте через MCP с проектами и объектами, которым доверяете.

База данных: только чтение и не прод

Агенту полезно видеть схему и реальные данные стенда: проверить миграцию, найти запись, которую тест не может создать. Пример — сервер DBHub: он поддерживает MySQL, MariaDB, PostgreSQL, SQLite и другие СУБД и умеет режим только для чтения. Настройки сервера лежат в его собственном TOML:

[[sources]]
id = "stage"
type = "mysql"
host = "127.0.0.1"
database = "site_stage"
user = "agent_readonly"
password = "${STAGE_DB_PASSWORD}"

[[tools]]
name = "execute_sql"
source = "stage"
readonly = true
max_rows = 200

[mcp_servers.db_stage]
command = "npx"
args = ["-y", "@bytebase/dbhub@latest", "--transport", "stdio", "--config", "/Users/me/.config/dbhub/stage.toml"]
env_vars = ["STAGE_DB_PASSWORD"]

env_vars пробрасывает переменную из вашего окружения в процесс сервера — пароль не попадает ни в один файл. Режим readonly в DBHub проверяет запросы по списку разрешённых команд и включает read-only режим самой СУБД, но настоящая страховка — пользователь БД, у которого есть только SELECT. Прод-базу с персональными данными клиентов агенту не подключайте вовсе: всё, что вернёт запрос, уходит в контекст модели.

Документация: Context7 и OpenAI Docs MCP

Модель знает фреймворки по состоянию на дату обучения. Для свежих API нужен сервер документации. Context7 вы уже подключали в прошлом уроке — он отдаёт актуальную документацию по популярным библиотекам. Второй вариант из официальной документации Codex — OpenAI Docs MCP:

[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

Он ищет и читает документацию по продуктам OpenAI, включая сам Codex. Оба сервера работают только на чтение, их можно держать включёнными, но каждый сервер добавляет описания инструментов в контекст и расходует лимит. Подключённое «на всякий случай» отключайте через enabled = false.

Где хранить настройки

Личные серверы с вашими токенами — в ~/.codex/config.toml. Серверы, нужные всей команде, — в .codex/config.toml репозитория; Codex загружает его только для доверенных (trusted) проектов. В проектный файл не кладите секреты: только bearer_token_env_var, env_vars и env_http_headers, которые ссылаются на переменные окружения. Проверить итог — /mcp в TUI или codex mcp list.