Если агенту в VS Code нужен внешний инструмент, MCP-сервер описывают в файле mcp.json внутри папки .vscode: имя сервера, способ запуска и адрес. После подтверждения доверия редактор показывает инструменты в чате, а каждый вызов может требовать вашего согласия. Схема работает там, где вы готовы отделить то, что агент видит в открытых файлах, от того, что он получает из внешней системы.
Файл mcp.json
VS Code читает настройки MCP из объекта servers в файле .vscode/mcp.json; для каждого сервера задают type (stdio или http), а также command с args либо url.
Возьмём сценарий: в компании есть внутренний справочник методов API, и разработчик просит агента написать вызов к нужному методу. Справочник оформлен как MCP-сервер, который отдаёт описание метода, параметры и примеры ответа. Агент читает их и предлагает код, а разработчик проверяет вызов на тестовом стенде. Запись в справочник сервером исключена: он отвечает только на чтение.
| Где лежит | Формат | Для чего |
|---|---|---|
| .vscode/mcp.json | Объект servers | Серверы проекта, общие для команды |
| .mcp.json в корне | Объект mcpServers | Переносимая запись, которую читают и другие клиенты |
| Пользовательская конфигурация | Открывается командой MCP: Open User Configuration | Личные серверы разработчика |
Один и тот же сервер можно описать по-разному: локальный запускается как процесс на машине разработчика (тип stdio), удалённый подключается по адресу (тип http). Для справочника, который живёт во внутренней сети, обычно выбирают второй вариант и ставят перед ним авторизацию. Список мест и формат описаны в документации VS Code. Для проекта с несколькими разработчиками это решает вопрос однородности: у всех один набор серверов, и расхождения видны в истории изменений. Проектный файл удобен тем, что лежит рядом с кодом, но вместе с тем уходит в репозиторий, поэтому ключи в нём хранить нельзя: для секретов в файле предусмотрены переменные ввода вида ${input:...}. Если вы сравниваете редакторы, посмотрите настройку MCP в Cline: логика сходная, а места настроек разные.
Что видит агент
Контекст агента в редакторе складывается из нескольких слоёв: ваш запрос, открытые файлы и выделенный фрагмент, результаты инструментов. Устройство здесь такое: ответ MCP-сервера попадает в тот же слой, что и файлы. Модель способна смешать их в одном ответе, поэтому всё, что сервер вернул, считается доступным для следующего шага задачи. Это важно для справочника API: если в описании метода окажется пример с боевым токеном, токен станет частью контекста.
Разработчик в этот момент читает итоговый код, и источник каждого поля остаётся за кадром. Отсюда три практических вывода. Сервер отдаёт нужные поля вместо всего документа целиком. Открытые в редакторе файлы с секретами закрывают до запуска задачи. Внешние тексты, которые сервер доставляет агенту, считаются данными, и любая команда внутри них (prompt injection) остаётся текстом без права на исполнение. Подробнее о границах контекста — в разборе окна контекста.
- Закройте вкладки с файлами окружения и ключами, прежде чем ставить задачу.
- Ограничьте ответ сервера полями метода: имя, параметры, пример без реальных значений.
- Проверьте, что в справочнике нет учётных данных, оставленных в описаниях.
Доверие при запуске
Документация VS Code прямо предупреждает, что MCP-серверы запускают произвольный код на вашей машине. Для серверов вне рабочей папки при первом старте или после изменения конфигурации редактор показывает окно с описанием сервера и просит подтвердить доверие; серверы рабочей папки подчиняются доверию к самой папке (Workspace Trust). Поэтому появление окна без вашего изменения служит сигналом для проверки. Читать это окно стоит внимательно: команда, пакет и аргументы определяют, что именно начнёт работать на компьютере разработчика. Проверьте, совпадает ли название пакета с тем, что заявлено в запросе на изменение, и закреплена ли версия, чтобы поведение сервера менялось только вашим решением, а очередное обновление пакета проходило ту же проверку.
Привычка нажимать «доверять» вслепую превращает окно в формальность, а первая подмена пакета в чужом запросе на изменение обходится дороже всей проверки. Для командной работы закрепите правила. Новый сервер добавляют через запрос на изменение файла mcp.json, и проверяющий смотрит на источник пакета, закреплённую версию и список аргументов. Серверы из публичных каталогов проходят ту же проверку, что и любая новая зависимость проекта. Закрепляйте версию в аргументах запуска и пересматривайте её сознательно, с прогоном контрольного вопроса. Удалённый вариант с адресом в поле url проверяют иначе: кто владеет адресом, какие данные туда уходят и как отзывается доступ.
Проверка вызова
Пока справочник подключён впервые и результат неизвестен, разрешайте вызовы по одному. По документации VS Code, в чате вас могут просить подтверждать каждое обращение к инструменту; для первых прогонов это именно то, что нужно, так как вы видите имя инструмента и аргументы до отправки.
- Добавьте сервер справочника в
.vscode/mcp.jsonи подтвердите доверие к рабочей папке и серверу, если редактор спросит. - Откройте чат агента и убедитесь, что в списке инструментов виден только поиск метода, а других действий нет.
- Попросите агента найти метод по описанию задачи и написать вызов к нему; перед отправкой прочтите аргументы запроса.
- Запустите вызов на тестовом стенде и сверьте поля ответа с описанием в справочнике.
Отдельно сравните, что агент написал в коде и что он получил от сервера. Поле, которого нет в ответе справочника, агент достроил по догадке; поле, которое расходится с описанием метода, говорит об устаревшем справочнике. Оба случая фиксируют в журнале проверки и исправляют до расширения набора. В связке Codex и VS Code действует тот же принцип: правка принимается после прочтения diff.
Какие внешние системы вы хотели бы показать агенту в редакторе?
Командные правила
Первая команда после подключения решает многое, поэтому зафиксируйте контрольный вопрос: агент обязан найти метод по описанию и назвать параметры, а при отсутствии метода сообщить об этом прямо. Когда сервер заработал у одного человека, оформите его для команды: описание в файле проекта, владелец, срок пересмотра и порядок отключения. Ключи подаются через переменные окружения или менеджер секретов, а в репозитории остаётся только имя переменной. Если сервер понадобился лишь одному разработчику, его место в пользовательской конфигурации.
Ответственность делите так: за содержимое справочника отвечает его владелец, за файл mcp.json и список разрешённых инструментов отвечает команда разработки, за решение о записи отвечает руководитель направления. Регулярно сверяйте список подключённых серверов с реальными задачами: лишний сервер расширяет доступ без пользы, поэтому неиспользуемый отключают сразу. Удаление из файла фиксируется тем же запросом на изменение, что и добавление. Отдельно отмечайте серверы с правом записи: справочник из нашего примера остаётся вне этой группы, зато трекер задач или хранилище файлов входят в неё. Для них подтверждение каждого вызова остаётся обязательным, а решение о включении принимает владелец системы, к которой сервер обращается. Решения о доступе к репозиторию и задачам удобно сверять со статьёй про GitHub через MCP.
Начните с одного сервера, который только читает справочную информацию, и закрепите его в .vscode/mcp.json через запрос на изменение. Проверьте окно доверия, список инструментов и ответ на вымышленном методе. Если разработку ведёт команда и нужны права и приёмка, обсудите с нами ИИ-агента для вашей разработки.