Гайды

Как настроить MCP в Qwen Code

13 октября 2026 · 15 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Материал редакции Зерокодера. Счёт по выдаче снят собственным прогоном 13 октября 2026 года; цитаты источников приведены дословно. Обновлено: октябрь 2026.

Как настроить MCP в Qwen Code: добавить сервер командой qwen mcp add или вручную прописать его в settings.json. Qwen Code читает серверы из блока mcpServers в файле настроек — об этом сообщает документация QwenLM. Ниже — порядок действий, разбор транспортов и диагностика.

Собственный срез корпуса: мы скачали подборку результатов веб-поиска по запросу «Как настроить MCP в Qwen Code»: текст отдали 9 из 10.

Конфигурация и выбор транспорта

В пользовательской документации QwenLM серверы заданы в mcpServers. Пользовательский файл — ~/.qwen/settings.json, проектный — .qwen/settings.json. Для HTTP используется httpUrl, для SSE — url, для stdio — command и args, при необходимости cwd и env. После добавления сервера в уже открытом CLI предусмотрен перезапуск в том же проекте и проверка через /mcp.

Документация пользователя и разработчика по-разному называют историческую область по умолчанию. В упражнении область задаётся явно. Этот пример подключает уже работающий HTTP endpoint:

qwen mcp add --scope project --transport http training http://localhost:3000/mcp
qwen

Затем откройте /mcp и проверьте состояние training. Адрес localhost здесь учебный: сначала нужен настоящий MCP-сервер, который слушает этот endpoint. Команда добавления только записывает конфигурацию. Сервер не появится от произнесения имени или записи адреса. Если ваш сервер расположен иначе, возьмите адрес и транспорт из его действующей инструкции.

Для понимания CLI есть инструкция Qwen в VS Code. В этом материале настройку проверяем отдельным учебным заданием. Результат серверного вызова редакция не получала.

Учебный пример и самопроверка

Возьмём задачу, которую можно пройти целиком на своей машине: подключить локальный stdio-сервер, который отдаёт одну простую функцию, и убедиться, что Qwen Code её вызывает. Конкретный сервер вы выбираете сами — подойдёт любой учебный MCP-сервер с одной командой.

Шаги:

1. Определитесь с областью. Для упражнения удобна проектная: .qwen/settings.json в корне тестового проекта. Так эксперимент не затронет остальные проекты.
2. Опишите сервер. Через qwen mcp add с транспортом stdio либо вручную в блоке mcpServers.
3. Перезапустите Qwen Code в этом проекте.
4. Попросите модель вызвать инструмент сервера.
5. Зафиксируйте результат: вызов состоялся или нет.

Критерии самостоятельной проверки — три вопроса, на которые нужен ответ «да»:

• Сервер появился в списке после добавления.
• Модель вызвала инструмент по вашей просьбе.
• Повторный запуск в том же проекте сохраняет доступ к серверу.

Если хотя бы один ответ отрицательный, упражнение не пройдено — и это нормальный результат первого прохода. Дальше разбираем причины.

Отдельно проверьте поведение при перезапуске. Документация QwenLM прямо указывает на необходимость перезапуска в том же проекте после добавления сервера. Зафиксируйте, изменился ли список серверов после запуска новой сессии. Частоту причин редакция не измеряла.

Второй учебный сценарий — перенос сервера между областями. Опишите сервер в проектной области, убедитесь, что он виден, затем перенесите описание в пользовательскую и проверьте в другом проекте. Так вы увидите разницу охвата на практике.

Сверка транспорта с выбранным сервером

Выбор привяжите к действующей инструкции сервера. В карточке запишите, что он предоставляет: endpoint или запускаемый процесс. Сопоставьте это с технической основой выше и сохранённой конфигурацией. Локальность машины сама по себе не определяет транспорт: локальный сервер тоже может слушать HTTP. Для опыта используйте тот маршрут, который предоставляет ваш сервер. Проверьте, что адрес или команда относятся именно к учебному экземпляру. Секреты храните в предусмотренном для них месте и проверяйте, какие записи готовы передавать серверу.

Отказ подключения и следующий шаг

Запишите этап отказа: обнаружение, выбор инструмента, вызов или чтение результата. Сохраните сообщение без секретов. Сверьте фактический файл конфигурации и каталог запуска. Для процесса проверьте путь и окружение; для endpoint — доступность выбранного сервера. Если функция обнаружена, но вызов отклонён, сравните аргументы с её действующей схемой. Одновременно менять транспорт, ключ и модель не требуется. Следующее действие выбирайте по конкретному наблюдению. Подробный учебный разбор ниже показывает, как сохранить эту связь при успешном чтении и при отказе.

Смежные ошибки клиента описаны в разборе Qwen Code.

Учебный договор с уже работающим сервером

Следующий сценарий создан редакцией для самостоятельной проверки подключения. Он начинается с доступного MCP-сервера. Возьмите учебный сервер, для которого у вас есть инструкция владельца, известный транспорт и инструмент чтения данных. Название инструмента, его аргументы и способ авторизации возьмите из этой инструкции и фактического списка сервера. В этом упражнении сервер уже развёрнут; его установку команда добавления в Qwen Code не выполняет. Редакция сервер не запускала и результата вызова не получала.

Подготовьте учебный документ без личных данных. Назовите его garden-note в системе сервера. Содержимое придумано для опыта: «Саженцы доставлены. Инструменты выдают у северных ворот. Время встречи остаётся прежним. Ответственный за полив пока не выбран». Если выбранный сервер читает файлы, создайте файл с этим текстом в разрешённой учебной папке. Если он читает записи, создайте запись с этим идентификатором. Способ загрузки и ограничения папки сверяйте с инструкцией своего сервера.

До подключения посмотрите учебный документ собственным способом и сохраните копию текста. Это контрольный вход: дальше вы сможете установить, получил ли инструмент нужные данные. Выберите для первого опыта только чтение. Если в списке есть удаление записей, отправка сообщений или изменение файлов, такие операции в учебном запросе не нужны. Проверяемый результат здесь — прочитанный документ и его аккуратная сводка. Правила доступа задаются самим сервером и выбранной конфигурацией; один текст запроса не заменяет ограничения инструмента.

Запишите карточку подключения: имя сервера в Qwen Code, фактический endpoint или команду запуска, транспорт, выбранную область и название инструмента чтения. Рядом сохраните названия аргументов из его схемы. Значение секрета в карточку не вставляйте. Если нужного инструмента нет в списке, остановитесь и выберите сервер, который выполняет учебную задачу. Ответ модели с придуманным названием инструмента не создаёт этот инструмент на сервере.

От списка сервера до фактического вызова

После записи конфигурации откройте новую сессию из выбранного проекта. Посмотрите /mcp, найдите своё имя сервера и сохраните наблюдаемое состояние. Если сервер не обнаружен, вернитесь к пути конфигурации и способу запуска. Если он обнаружен, изучите доступный список инструментов. Сопоставьте выбранный инструмент чтения с карточкой: имя, назначение, обязательные аргументы и ограничения. При расхождении сначала уточните данные сервера.

Первое сообщение модели сделайте коротким и предметным. Например: Используй инструмент чтения сервера training, чтобы получить учебный документ garden-note. Показать нужно фактический результат вызова, затем краткую сводку. Изменять документы не требуется. Если инструмента нет, назови это состояние и остановись. Имена training и garden-note в этом тексте относятся к вашему примеру; подставьте свои значения из карточки. Уточните точное имя инструмента, когда оно известно.

Наблюдайте за событием вызова в клиенте. Текст «я прочитал документ» ещё не устанавливает, что сервер получил запрос. Проверьте, какой инструмент был вызван, какие аргументы переданы и что он вернул. При наличии журналов сервера сопоставьте событие с ними. Запишите фактический исход: чтение состоялось, документ не найден, доступ отклонён или соединение прервалось. Эти состояния требуют разных следующих действий.

Если клиент просит подтверждение, прочитайте название действия и аргументы перед решением. Для учебного чтения должен запрашиваться именно ваш документ. Если вместо этого предложена запись, удаление или отправка наружу, остановите этот шаг и уточните запрос. Изменение режима подтверждений ради первого опыта не требуется. Сохраняйте выбранные границы доступа: опыт должен помочь понять маршрут, а расширение прав можно изучать отдельной задачей.

После успешного чтения сравните результат инструмента с контрольным текстом. Саженцы уже доставлены, выдача инструментов происходит у северных ворот, время прежнее, ответственный неизвестен. Отметьте, что из этого присутствует в фактическом возврате. Затем отдельно сравните сводку модели с возвратом. Если инструмент вернул правильный документ, а сводка назначила ответственного, соединение могло сработать, но содержательная задача требует исправления.

Контрольная правка данных без смены конфигурации

Для следующего опыта поменяйте одну фразу документа своим обычным способом. Например, замените северные ворота на площадку у теплицы. Сохраните обе версии рядом и подпишите изменение. Конфигурацию сервера, модель и запрос на чтение оставьте прежними. Затем снова попросите прочитать тот же учебный документ через конкретный инструмент. Так вы проверяете связь результата с изменённым входом.

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

При повторении не меняйте одновременно имя документа и endpoint. Иначе будет трудно установить, что вызвало расхождение. В журнале опыта укажите изменённый вход, переданный аргумент и результат чтения. Новый текст сводки оценивайте отдельно. Если модель добавила время встречи или фамилию, которых нет в документе, назовите именно эту добавленную деталь. После уточнения сверяйте весь ответ, чтобы исправление одной фразы сохранило остальные исходные сведения.

Можно выполнить ещё один опыт с отсутствующим идентификатором, который вы заранее проверили сами. Попросите инструмент прочитать эту запись и сохраните реальное сообщение сервера. Ожидаемый смысл проверки — понять, как ваш клиент показывает отсутствие данных. Конкретный код или форму ошибки задаёт выбранный сервер; в редакционном примере они не придуманы. Нормальный результат такого опыта — честная запись отказа и остановка содержательной сводки до получения документа.

Разбор отказа по этапу

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

Если сервер обнаружен, но нужного инструмента нет, сравните список с действующей инструкцией владельца. Проверьте, какие функции разрешены этому аккаунту и выбранной конфигурации. Не просите модель придумать замену с похожим названием. Для учебной задачи можно выбрать другой доступный инструмент чтения, но сначала обновите карточку аргументов и контрольный вход. Иначе результат будет относиться к другой операции, а журнал станет неоднозначным.

Если вызов стартовал и вернул отказ, сохраните сообщение вместе с аргументами без секретов. Уточните, относится ли оно к соединению, аутентификации, схеме аргументов или конкретной записи. Для ошибки аргумента сравните тип и имя поля со схемой инструмента. Для отказа доступа проверьте аккаунт и ресурс на стороне сервера. Для сетевого сообщения проверьте состояние endpoint. Общий совет «перезапустить всё» не показывает, какой слой изменился.

Если инструмент вернул данные, но модель дала слабую сводку, работа переходит к проверке текста. Сопоставьте ответ с контрольным документом. Отметьте пропуски, добавленные сведения и смешение факта с неизвестностью. Новый запрос должен назвать конкретное расхождение. Для полива в нашем документе ещё нет назначенного человека; сводка должна сохранить это состояние. Данные сервера становятся входом для модели, и правильность их пересказа проверяется отдельно от подключения.

Завершение упражнения и передача результата

В конце сохраните конфигурацию без секретов, карточку подключения, исходный текст, изменённый текст и журнал фактических попыток. Запишите, какой инструмент был вызван и какое действие подтвердилось. Если упражнение осталось на этапе обнаружения, так и обозначьте итог. Если чтение прошло, укажите проверенный документ и наблюдаемые ограничения. Не расширяйте вывод одной попытки на все функции сервера.

Перед передачей коллеге очистите записи от токенов и личных путей. Оставьте названия полей, которые нужны для сравнения. Коллега должен понимать, что сервер был предварительно подготовлен и где взять его собственную инструкцию. Адрес из учебной страницы не заменяет живой endpoint. Список доступных инструментов и права аккаунта он проверяет заново в своём окружении.

Если конфигурация нужна только для упражнения, верните исходный файл и убедитесь, что учебная запись больше не мешает обычной работе. Если решите оставить сервер, подпишите назначение и область. Для более сложной задачи сначала выберите следующий проверяемый результат: другое чтение, поиск или допустимая запись. У каждой операции должны быть свой контрольный вход и критерий принятия. Такой порядок сохраняет связь между заданием, фактическим вызовом и результатом пользователя.

Ручной JSON для того же HTTP-упражнения

Для отдельной проверки можно описать тот же уже работающий сервер вручную. Поля взяты из конфигурации QwenLM; имя training выбрано редакцией. Пример предназначен для проектного файла. Сохраните копию существующего .qwen/settings.json и объедините запись с ним. Если раздел mcpServers уже есть, добавьте новый объект внутри него. Целый рабочий файл не следует заменять коротким примером: в нём могут находиться настройки модели и других серверов.

{
  "mcpServers": {
    "training": {
      "httpUrl": "http://localhost:3000/mcp"
    }
  }
}

Адрес в примере обозначает учебный endpoint. Используйте его только если ваш сервер действительно слушает здесь. Для сервера на другом адресе подставьте фактическое значение из инструкции владельца. Сначала сравните ручную запись с записью, созданной командой добавления. В обоих случаях должны совпасть имя, транспортный адрес и область. Для проверки не нужно одновременно держать дубли одного сервера под разными именами.

Перед запуском разберите файл JSON своим редактором и убедитесь, что соседние разделы сохранились. Синтаксически читаемый файл ещё нужно проверить в клиенте. Откройте новую сессию того же проекта, найдите сервер в /mcp и выполните учебное чтение. Сравните состояние, аргументы и результат с предыдущей попыткой. При расхождении сохраните обе конфигурации и выделите фактически изменённое поле.

Проверка области на двух учебных проектах

Создайте отдельные каталоги garden-demo и library-demo. В первом находится проектная запись training, во втором такой записи нет. Пользовательские настройки заранее просмотрите и запишите, не существует ли там сервер с тем же именем. Иначе сравнение не установит влияние одного проектного файла. Для этого опыта не нужна смена модели; сохраните тот же способ запуска клиента.

Откройте сессию в garden-demo и запишите состояние сервера. Затем откройте отдельную сессию в library-demo и сравните список. Ожидаемое различие задаётся вашей карточкой: проектная конфигурация привязана к выбранному проекту. Если сервер виден в обоих, проверьте пользовательский и системный уровни, а также реальный каталог запуска. Не удаляйте случайные записи ради ожидаемого результата; сначала установите, откуда они взялись.

После осмотра вернитесь в первый проект и снова прочитайте garden-note. В журнале запишите, что вы проверили именно прежнюю запись. Содержимое документа не должно случайно подменяться материалами второго проекта. Для сервера с ограничениями папок проверьте допустимый путь по его правилам. Наблюдение списка и права чтения относятся к разным слоям, поэтому фиксируйте их отдельными строками.

Если нужен переход к общей пользовательской области, сохраните исходный проектный файл и выберите новое положение записи явно. После переноса проверьте оба учебных проекта тем же способом. Проверьте также отсутствие оставшегося дублирующего объекта в первом проекте. Имена и пути из вашего журнала позволят понять, какая запись обслуживала вызов. Предлагаемый перенос редакция не выполняла; наблюдения зависят от конфигурации вашего окружения.

Граница чтения и содержательного решения

Допустим, задача пользователя после чтения заметки — отправить объявление участникам сада. Учебный вызов в этой статье только получает данные и формирует сводку. До отправки нужен отдельный шаг принятия текста и выбор разрешённого инструмента. Данные о времени встречи и ответственном всё ещё неполны; их нельзя заполнить уверенной догадкой ради готового объявления.

Для проверки этой границы сформулируйте запрос: «Прочитай документ и подготовь черновик объявления. Срок и ответственного оставь неизвестными. Отправку не выполняй». Сверьте фактические вызовы с разрешённым чтением. Если модель предложила отправку, изучите действие и остановите его до согласования. Фраза в запросе полезна как инструкция, а ограничения разрешённых инструментов должны задаваться вашим сервером и клиентом отдельно.

Прочитайте полученный черновик как адресат объявления. Сверьте место выдачи инструментов, статус доставки саженцев и неизвестность ответственного. Если в тексте появился точный час, попросите убрать именно его. После правки сравните весь черновик: место встречи и статус доставки должны сохраниться. Этот опыт показывает, почему подключение MCP и принятие результата пользователем нужно проверять последовательно.

Теперь попробуйте контрольный запрос без получения документа. Он может дать общий текст о саде, но в нём нет фактического возврата нужного сервера. Сопоставьте его с попыткой чтения по событиям клиента и происхождению данных. Для рабочего результата требуйте понятный вход и запись вызова. Красивый текст с правдоподобными деталями не даёт такого основания автоматически.

Как оформить итог отказавшего опыта

Упражнение полезно и тогда, когда подключение не завершилось. Сохраните исходную конфигурацию, выбранную область, состояние /mcp и этап, на котором остановились. Если вызов не состоялся, запись результата документа должна оставаться пустой. Если вызов состоялся и вернул отказ, сохраняйте реальное сообщение. В отчёте отделите эти наблюдения от предположения о причине.

Для следующего шага подготовьте одну проверяемую гипотезу. Например, клиент открыт из другого проекта, endpoint перестал отвечать или аргумент инструмента отличается от схемы. Укажите действие для её проверки и ожидаемое наблюдение, затем выполните его в своём окружении. После изменения обновите журнал, сохраняя предыдущую запись. Такой отчёт можно передать владельцу сервера без токенов и полного содержимого личных документов.

Завершите запись конкретной границей: конфигурация читается; сервер обнаружен; инструмент вызван; данные сверены; сводка принята. Отмечайте только подтверждённые этапы. Если подтверждено обнаружение, следующий участник начинает с вызова. Если подтверждено чтение, он может оценивать следующий содержательный результат. Эта точность сохраняет пригодность отчёта и помогает продолжить работу после устранения внешней причины отказа.

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

Как добавить MCP-сервер в Qwen Code?
Возьмите действующий адрес или команду сервера, задайте область явно и примените пример подключения из технической основы выше.

Где хранится конфигурация MCP?
Сохраните фактический путь выбранной области в карточке. Он нужен для проверки и возврата к исходному состоянию.

Какой транспорт выбрать?
Используйте транспорт из инструкции владельца сервера. Проверьте его соответствие записи конфигурации до первого вызова.

Почему сервер не виден?
Запишите наблюдаемое состояние, каталог и путь настроек. Проверьте новый запуск клиента и действующий endpoint или процесс.

Как подтвердить работу подключения?
Сопоставьте фактический вызов, его аргументы и результат с контрольным документом. Сводку модели проверяйте отдельно.