MCP для Cursor и Codex в командном репозитории

Раздел

MCP-серверы

Сложность

средняя

Обновлено

2026-05-20

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

MCP в командном репозитории нужен не для того, чтобы Cursor или Codex получили больше власти, а чтобы они получали нужный контекст через понятные и проверяемые каналы: документацию, задачи, read-only статус CI, карту сервисов, спецификации API и внутренние runbook. Запись в продуктовые системы, массовые правки задач и доступ к секретам не должны появляться в первом контуре.

Для Cursor полезно начинать с проектного mcp.json, потому что конфигурация живет рядом с репозиторием и понятна команде. В официальной документации Cursor описывает MCP как способ подключать внешние tools и data sources, а также разделяет локальные и remote transports: Cursor MCP docs. Для Codex важно отличать локальный агент в терминале от облачных задач: Codex CLI может читать, менять и запускать код в выбранной директории, что описано в OpenAI Codex CLI docs.

Практическое правило: MCP-сервер для команды должен быть скучным, read-only и журналируемым, пока вы не доказали, что агент не путает контекст, не вытаскивает лишние данные и не обходят ревью.

Что подключать первым

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

MCP tools по спецификации являются действиями, которые модель может вызвать, и должны иметь схему входных параметров. В MCP tools specification отдельно указаны access controls, rate limits, audit logging и подтверждение пользователя для чувствительных операций. Для командного репозитория это не украшение, а базовый контракт.

Минимальная схема

developer -> Cursor or Codex
  -> project MCP config
    -> docs_search(query)
    -> issue_read(id)
    -> ci_status(branch)
    -> api_spec_read(service)
  -> agent proposes diff
  -> tests and human review

В этой схеме агент не получает общий run_anything_in_company tool. Он получает несколько узких функций. Если нужно дать OpenAI-документацию прямо в рабочий контекст, OpenAI публикует documentation-only MCP server для developer docs: OpenAI Docs MCP. В статье про OpenAI Codex CLI этот же принцип важен для локальных задач: агенту нужны инструкции, тесты и границы.

Граница ревью: MCP может объяснить задачу и собрать контекст, но не отменяет code review. Если агент меняет код, владелец репозитория все равно смотрит diff, тесты и влияние на контракт.

Конфигурация для команды

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

{
  "mcpServers": {
    "team-docs": {
      "command": "node",
      "args": ["tools/mcp/team-docs.js"],
      "env": {
        "DOCS_BASE_URL": "https://docs.example.internal"
      }
    },
    "ci-readonly": {
      "url": "https://mcp.example.internal/ci"
    }
  }
}

Секреты не должны попадать в файл. Используйте переменные окружения, secret store или OAuth, если сервер remote. В описании каждого сервера фиксируйте владельца, список tools, тип данных, срок действия токена и способ отключения.

Политика tools

Минимальная политика для репозитория:

• каждый tool имеет владельца;
• параметры типизированы и ограничены;
• нет tools для чтения секретов;
• нет произвольного SQL, shell или GraphQL без allowlist;
• результаты не возвращают лишние персональные данные;
• каждый вызов пишет журнал;
• опасные операции требуют подтверждения человека;
• tools можно отключить без изменения кода продукта.

Фрагмент внутреннего allowlist может выглядеть так:

tools:
  docs_search:
    mode: read
    max_results: 8
    pii: forbidden
  issue_read:
    mode: read
    fields: [title, body, labels, status]
  ci_status:
    mode: read
    branches: [main, release/*, user-branches]
forbidden:
  - secrets_read
  - deploy_production
  - bulk_issue_update

Ревью и журнал

Журнал нужен не только security-команде. Он помогает понять, почему агент сделал конкретный diff. Записывайте user, tool, параметры без секретов, результат, длительность, trace ID и версию MCP-сервера. Если агент сослался на устаревший runbook, это должно быть видно.

Для pull request полезен короткий блок:

Такой блок не заменяет тесты, но снижает риск “агент что-то понял из воздуха”.

Где MCP не нужен

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

Также не используйте MCP как обход доступа. Если разработчик не имеет права читать систему, агент от его имени тоже не должен ее читать. Права проверяются на сервере, а не в prompt.

Чеклист

• Есть один сценарий: docs, tasks, CI или API specs.
• Первый контур read-only.
• В репозитории описан владелец MCP-сервера.
• Нет доступа к секретам и production-записи.
• Tools имеют allowlist и ограниченные параметры.
• Cursor/Codex используют проектные инструкции.
• Каждый вызов MCP журналируется.
• Ревьюер видит, какие источники использовал агент.
• Опасные операции требуют человека.
• Есть команда быстрого отключения сервера.

FAQ

MCP заменяет AGENTS.md?

Нет. AGENTS.md задает правила работы в репозитории. MCP дает доступ к внешнему контексту и tools. Нужны оба слоя.

Можно ли подключить один сервер ко всем репозиториям?

Можно, но лучше начинать с проектного контура. Глобальный сервер легко раскрывает лишний контекст между командами.

Нужно ли давать агенту доступ к issue tracker?

Да, если задачи и acceptance criteria живут там. Но на старте достаточно чтения задачи и статуса, без массовых изменений.

Что читать дальше?

После командного MCP посмотрите MCP сервер: что это, Cursor AI для команды и OpenAI Codex CLI. Если нужен разбор, какие tools безопасно открыть команде, откройте услуги Woghan.