Все статьи
30 июля 2026 г.·4 мин чтения

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 разбираем отдельно.