Qwen Code MCP подключают через настройки агента: серверы с инструментами, будь то репозиторий, трекер задач или база знаний, описывают в файле settings.json и сразу ограничивают списком разрешённых действий. Каждый сервер расширяет то, что агент умеет, а значит, и то, что он способен испортить, поэтому после подключения идёт пробный прогон на отдельном репозитории. Подход работает, когда за каждым подключением стоит человек, отвечающий за его права.
Зачем MCP агенту
По документации Qwen Code, серверы MCP описываются в настройках, подключаются по HTTP, SSE или через локальный процесс, а набор доступных агенту инструментов сужается списками. Доверие к серверу задаётся отдельным параметром и снимает подтверждения.
Сам по себе кодовый агент видит файлы проекта и умеет запускать команды. Всё остальное, от задач в трекере до внутренней документации, лежит за его границей. Протокол MCP стандартизирует мост: сервер объявляет список инструментов с описанием, а агент вызывает их по ходу работы. Расплата за удобство в том, что агент получает руки там, где раньше были только глаза.
Общую картину инструмента, его назначение и пределы мы описывали в статье про Qwen Code для программирования в компании, а сам протокол — в материале MCP: что это и зачем бизнесу. Здесь только один вопрос: как подключить сервер так, чтобы список его действий был известен и ограничен до первого запуска.
Практическая граница проходит там, где у сервера возникает право записи. Чтение уже требует решения, потому что прочитанное уходит модели и способно покинуть вашу сеть. Запись добавляет риск порчи данных. Поэтому подключение делят на два этапа: сначала чтение, затем запись, а между ними проходит ревью.
Названия параметров и формат файла настроек меняются с версиями, поэтому перед работой откройте документацию Qwen Code и сверьтесь с текущей. Ниже описаны принципы, которые удерживаются от версии к версии.
Подключение сервера
Серверы объявляются в разделе mcpServers файла settings.json. Настройки хранятся на двух уровнях: пользовательском, в домашнем каталоге, и проектном, внутри репозитория. Проектный уровень удобнее для команды: подключения лежат рядом с кодом и видны на ревью.
| Транспорт | Для чего подходит | Что проверить до запуска |
|---|---|---|
| HTTP | Удалённые и облачные серверы, подключаются по адресу httpUrl | Кто владеет сервером и куда уходят данные запросов |
| SSE | Серверы старого образца на событиях, адрес задаётся полем url | Есть ли замена на HTTP и поддерживается ли сервер |
| Stdio | Локальные процессы, скрипты и консольные утилиты, запуск через command и args | Откуда взята программа и какие права у процесса |
По документации, сервер можно добавить тремя путями: отредактировать settings.json вручную, выполнить команду qwen mcp add или воспользоваться диалогом управления внутри самого агента, который вызывается командой /mcp.
Проектный файл настроек лежит в репозитории, поэтому ключам в нём делать нечего: их хранят в переменных окружения, а в настройках оставляют только имена переменных. Если ключ однажды попал в файл по ошибке, считайте его скомпрометированным и смените.
Выбирайте проверенные источники. Сервер из случайного репозитория с локальным запуском выполняет чужой код на вашей машине с вашими правами, а описание инструментов, которое читает модель, способно содержать инструкции. Фиксируйте версии, читайте исходники и подключайте только то, за что готовы отвечать.
Список действий
У сервера обычно больше инструментов, чем нужно задаче. Документация предлагает ограничить набор: параметры includeTools и excludeTools на уровне сервера оставляют агенту только перечисленное или убирают опасное, причём excludeTools имеет приоритет. Есть и глобальные фильтры mcp.allowed и mcp.excluded со сравнением по шаблону.
- Белый список: для первого подключения перечислите только чтение, например поиск и просмотр, а запись добавляйте позже.
- Чёрный список: удалите инструменты необратимых действий, такие как удаление, публикация и отправка наружу.
- Глобальные фильтры: закрепите правила для всего проекта, чтобы новый сервер приходил с урезанным набором прав.
- Описание инструментов: прочитайте его глазами, потому что модель ориентируется именно на этот текст.
- Доверие: параметр trust со значением true снимает вопросы по этому серверу в доверенном рабочем пространстве, поэтому включайте его осознанно и редко.
Параметр доверия заслуживает отдельного разговора. Он удобен, когда сервер локальный, написан вами и работает с тестовыми данными. Для чужого сервера или боевых данных подтверждения остаются страховкой, и пока вы читаете каждый запрос агента, они дают вам шанс остановиться до необратимого шага. Хороший ориентир: если вы готовы повторить каждое действие сервера вручную и показать его на ревью, доверие оправдано.
Какие внешние инструменты вы хотели бы дать кодовому агенту?
Тест на репозитории
Подключение проверяют на отдельном репозитории или ветке, где любая потеря безвредна. Цель теста: убедиться, что агент видит ровно те инструменты, которые вы разрешили, и что запретное действительно закрыто.
- Создайте тестовый репозиторий с безобидными файлами и без секретов и подключите сервер на проектном уровне.
- Откройте диалог /mcp и сверьте список инструментов с белым списком: любой лишний пункт — повод остановиться.
- Дайте агенту задачу, для которой нужен разрешённый инструмент, и убедитесь, что он его вызывает и показывает запрос.
- Попросите выполнить запретное действие и проверьте, что агент сообщает об отсутствии такого инструмента, а запись остаётся невозможной.
- Просмотрите журнал вызовов и изменённые файлы и только после этого переходите к рабочему репозиторию.
Условный пример: команда подключает сервер трекера задач и оставляет агенту два действия, поиск карточек и чтение описания. На тесте агент находит карточку и пересказывает её, а просьба закрыть задачу упирается в отсутствие инструмента. Запись откроют позже, отдельным шагом и с обязательным подтверждением человека.
Повторяйте тест после каждого обновления сервера или агента: набор инструментов у сервера может измениться, и новое действие появится в списке без вашего решения. Короткий скрипт сверки списка с эталоном снимает зависимость от внимательности человека.
Контроль и отзыв
Подключённый сервер превращается в часть инфраструктуры, и о нём надо заботиться так же, как о любой интеграции: знать владельца, срок пересмотра и порядок отзыва.
Короткая таблица из пяти колонок (сервер, владелец, разрешённые инструменты, уровень данных, дата последней проверки) спасает через полгода, когда все забыли, зачем агенту дан доступ к трекеру.
Отзыв прав начинайте с самого дешёвого шага: уберите сервер из настроек проекта и проверьте через /mcp, что он исчез. Затем смените ключи, которые использовал сервер, и просмотрите журнал обращений за период работы. Так отзыв превращается в рутину вместо аварии. Для ключей полезна привычка короткого срока жизни: чем раньше ключ устареет сам, тем меньше хлопот при отзыве.
Когда агент просит расширить права, решает человек: каждый новый инструмент — отдельное решение, и пустяком его считать нельзя. Вопрос, как встроить такие подключения в процессы компании, лучше обсуждать с теми, кто отвечает за безопасность. Помощь с процессом даёт разработка ИИ-агентов под задачи бизнеса.