Как в llama-server подключить MCP-серверы через --mcp-servers-config, зачем нужен --jinja, почему CORS-прокси опасно включать и что при такой схеме остаётся на компьютере.

Локальная модель сама по себе умеет одно: отвечать текстом на текст. Чтобы она читала файлы, ходила в базу или дёргала внешний сервис, ей нужны инструменты — и общий способ их описать. Этим занимается Model Context Protocol.

В llama.cpp поддержка MCP есть, но со звёздочкой: в документации она помечена как экспериментальная, а часть механики живёт не в самом сервере, а во встроенном веб-интерфейсе. Это влияет и на настройку, и на то, насколько такой связке можно доверять рабочие данные.

Что здесь происходит

MCP описывает контракт между хостом и сервером инструментов. Хост запускает серверы, читает список их инструментов и показывает модели, что она вправе вызвать. Модель ничего не «подключает» сама — она только просит, а выполняет хост. Устройство протокола подробно разобрано в статье что такое MCP.

В связке с llama.cpp роли распределяются так: llama-server считает модель и раздаёт интерфейс, встроенный веб-клиент выступает MCP-хостом, а серверы инструментов — это отдельные программы, локальные или удалённые.

Как подключить

Два ключа запуска, оба помечены как экспериментальные:

--mcp-servers-config PATH — путь к JSON-файлу с описанием серверов;
--mcp-servers-json JSON — то же самое, но строкой прямо в команде.

Формат описания совместим с нотацией Cursor. Это удобно: готовые куски конфигурации из документации серверов обычно переносятся без правок, как и в LM Studio.

Запуск выглядит так:

llama-server.exe -m C:\models\qwen3-8b-q4_k_m.gguf --jinja --mcp-servers-config C:\llama\mcp.json

--jinja здесь обязателен. Без него не включается вызов функций в стиле OpenAI, а без вызова функций модель не сможет обратиться к инструменту, даже если сервер подключён и виден.

◆

Если инструменты не появляются в интерфейсе, проверь сначала --jinja, а потом шаблон чата у самой модели. Часть GGUF-файлов собрана без шаблона для tool calls — тогда инструменты не заработают ни с какими ключами, и лечится это только другой сборкой модели.

Про CORS-прокси и почему он выключен

Есть ещё пара ключей: --webui-mcp-proxy и --no-webui-mcp-proxy. Второй стоит по умолчанию.

Прокси нужен потому, что MCP-клиент работает в браузере, а браузер не даёт странице обращаться к произвольным адресам. Прокси обходит это ограничение, пропуская запросы через сам сервер. Документация сопровождает ключ прямым предупреждением: не включать в недоверенной среде.

Логика предупреждения простая. Прокси превращает llama-server в посредника, который ходит по адресам за того, кто его попросил. В домашней сети на 127.0.0.1 это приемлемо. На машине, доступной снаружи, — уже нет.

Смежная защита работает в ту же сторону: когда указан конфиг MCP-серверов, значение --cors-origins по умолчанию ограничивается локальным адресом. Это тоже стоит оставить как есть.

Насколько локальной остаётся такая связка

Тут нужна честность, потому что MCP часто продают как «приватную альтернативу облаку».

Локальным остаётся вычисление модели: текст запроса и ответ не уходят наружу, .gguf-файл лежит у тебя. А вот инструменты живут своей жизнью. Сервер файловой системы читает твой диск и никуда не ходит. Сервер GitHub обращается к GitHub. Сервер веб-поиска отправляет запрос поисковику. Локальный MCP-клиент не делает облачный сервис локальным — он лишь даёт модели способ до него дотянуться.

Полностью офлайн получится, если ограничиться серверами, которые не выходят в сеть: файловая система, локальная база, локальные скрипты. Пример такой схемы — в статье про MCP и базу данных.

Отдельная проблема: модель может не потянуть

Описания инструментов попадают в контекст на каждом запросе. Один сервер с тридцатью инструментами и подробными схемами способен занять несколько тысяч токенов ещё до первого твоего сообщения.

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

Что помогает:

подключать серверы по одному, а не всё сразу;
поднимать контекст ключом -c, если хватает памяти;
брать модель побольше — на агентских сценариях это решает больше, чем настройки.

Безопасность серверов — отдельная тема: MCP-сервер это обычная программа с твоими правами, поэтому не стоит ставить их из случайных репозиториев и давать файловому серверу корень диска. Подробнее — в статье про подключение MCP-сервера.

Где эта схема упирается

Собранная связка выглядит убедительно: локальная модель, локальные инструменты, ничего наружу. Но у неё есть потолок, и он не в настройках.

llama-server остаётся сервером вывода с чатом в браузере. Модель может вызвать инструмент — и на этом её самостоятельность заканчивается. Она не ведёт задачу через несколько шагов, не проверяет свой результат, не возвращается к плану, если шаг не удался, и не работает по расписанию. Плюс сама поддержка MCP здесь помечена экспериментальной, то есть ключи и поведение могут поменяться между билдами.

Дока устроена как агент, а не как чат с инструментами: она ведёт задачу до результата, работает с файлами и терминалом, умеет расписания и свои навыки, а MCP-серверы подключаются как часть готового процесса, а не как экспериментальный ключ. Локальная модель при этом скачивается из интерфейса — собирать движок и подбирать сборку под видеокарту не нужно.

Как площадка для знакомства с MCP llama.cpp хороша: видно каждый слой, ничего не спрятано за кнопками. Проблема начинается, когда экспериментировать надоедает и хочется, чтобы инструменты просто были на месте каждый день. Тогда проще взять Доку и не следить за тем, какие ключи поменялись в очередном билде.

MCP в llama.cpp: инструменты для локальной GGUF-модели