MCP в LM Studio: как подключить серверы к локальной модели
Где лежит mcp.json в LM Studio, как добавить локальный и удалённый MCP-сервер, почему серверы из-под облачных моделей ломают локальную и что при этом реально остаётся на компьютере.
LM Studio умеет не только чат с локальной моделью. С версии 0.3.17 приложение работает как MCP-хост: подключаешь серверы, и модель получает доступ к файлам, базам, трекерам и другим инструментам. Сама настройка занимает пару минут. Сложнее другое — понять, какие серверы локальной модели не навредят и что после подключения остаётся у тебя на компьютере.
Что здесь делает MCP
Model Context Protocol — общий способ описать инструменты, которыми может пользоваться модель. Хост (в нашем случае LM Studio) запускает серверы, читает список их инструментов и показывает модели, что она вправе вызвать. Устройство протокола подробно разобрано в статье что такое MCP.
Сама модель при этом ничего не «подключает». Она только просит вызвать инструмент, а запускает его хост. От хоста и зависит, какие серверы доступны и что произойдёт перед выполнением команды.
Где лежит mcp.json
Конфигурация живёт в файле mcp.json. Открыть его можно прямо из приложения: перейди на
вкладку Program в правой панели и выбери Install → Edit mcp.json. Откроется
встроенный редактор.
Формат совпадает с нотацией mcp.json у Cursor, так что готовые примеры из документации
других хостов обычно переносятся без правок. Внутри — один объект mcpServers, в котором
каждый ключ описывает отдельный сервер:
{
"mcpServers": {
"moy-server": {
"url": "https://example.com/mcp",
"headers": {
"Authorization": "Bearer <TOKEN>"
}
}
}
}
Так описывается удалённый сервер. Локальный запускается командой — вместо url указывается
command с аргументами. Точный набор полей у каждого сервера свой, поэтому сверяй его с
README конкретного проекта, а не с чужим гайдом.
Если копируешь фрагмент из документации сервера, бери только содержимое после
"mcpServers": {. Иначе в файле окажется два вложенных объекта mcpServers и LM Studio не
увидит ни одного сервера.
Почему серверы под облачные модели ломают локальную
Документация LM Studio предупреждает об этом прямым текстом: часть серверов написана под Claude, ChatGPT и Gemini и расходует слишком много токенов для локальной модели.
Механика простая. Описание инструментов попадает в контекст на каждом запросе. Сервер с тридцатью инструментами и подробными схемами может занять несколько тысяч токенов ещё до того, как ты напишешь первое сообщение. У облачной модели с большим окном это незаметно, а локальная модель на 8 тысяч токенов контекста упирается в предел сразу.
Что с этим делать:
- Подключай серверы по одному и смотри, как меняется поведение модели.
- Увеличивай контекст в настройках загрузки модели, если памяти хватает.
- Отключай серверы, которые не нужны в текущей задаче, вместо того чтобы держать всё сразу.
- Для агентских сценариев бери модель побольше: путаница в аргументах инструментов — типичный признак, что модель мала для этой работы.
Безопасность: чего не стоит делать
Документация формулирует это жёстко: не устанавливай MCP-серверы из недоверенных источников, потому что часть из них получает широкий доступ к системе. Сервер — это обычная программа, которая запускается на твоём компьютере с твоими правами. Значит, может читать файлы, писать в них и обращаться в сеть.
Минимальная гигиена:
- Смотри исходники или хотя бы репозиторий сервера, прежде чем прописывать его в
mcp.json. - Не давай серверу файловой системы корень диска — ограничивай конкретной папкой.
- Токены и ключи храни в переменных окружения, а не в тексте конфигурации, которую легко случайно показать в скриншоте.
- Для необратимых действий держи подтверждение человеком. Про это есть отдельный разбор в статье о подключении MCP-сервера.
Что остаётся локальным, а что нет
Когда LM Studio считает модель на твоей машине, текст запроса и ответ не уходят наружу. Модель, история чата и настройки лежат локально.
Но MCP этого не меняет. Локальный MCP-клиент не превращает облачный сервис в локальный: сервер GitHub всё равно обращается к GitHub, сервер Notion — к Notion, сервер веб-поиска отправляет запрос поисковику. Локальным остаётся только то, что физически считается и хранится у тебя.
Поэтому проверять надо не одну галочку, а всю связку: где считается модель, какие серверы включены и куда каждый из них ходит. Полностью офлайн получится, если ограничиться серверами вроде файловой системы или локальной базы — например, по схеме из статьи про MCP и базу данных.
С чего начать проверку
Возьми один сервер файловой системы и одну тестовую папку с несколькими документами. Попроси модель найти в них конкретный факт и назвать файл. По такому запросу сразу видно, дошли ли до модели инструменты, хватает ли ей контекста и не пересказывает ли она содержимое по памяти вместо чтения.
Если инструменты вызываются, но аргументы уезжают — дело обычно в модели, а не в конфиге. Подборка серверов, которые стоит попробовать первыми, собрана в статье про полезные MCP-серверы.
LM Studio или Дока
LM Studio удобна, когда хочется гибкости на уровне конфигов: несколько моделей рядом,
ручная настройка контекста, свой набор серверов в mcp.json. Взамен ты собираешь связку
сам и сам следишь за тем, чтобы модель не задохнулась от количества инструментов.
Дока устроена иначе. Это десктопный агент, который сразу работает с файлами, терминалом и документами, а MCP-серверы подключаются как часть готового рабочего процесса; локальную GGUF-модель можно скачать из интерфейса. Если тебе интересно сравнивать модели и собирать конфигурацию руками, LM Studio ближе. Если нужно поставить приложение и начать работать с MCP в тот же день, у Доки короче путь — скачать можно бесплатно.
Разницу между Ollama и LM Studio как основой для локального endpoint разбираем отдельно.