Локальный MCP-сервер: как подключить без лишних прав

Раздел

MCP-серверы

Сложность

средняя

Обновлено

2026-05-21

Короткий ответ

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

В спецификации MCP локальный сценарий обычно начинается со stdio: клиент запускает сервер как подпроцесс, передает JSON-RPC через standard input/output, а сервер не должен писать в stdout ничего, кроме MCP-сообщений: MCP transports. Поэтому локальный MCP - это не “маленький веб-сервис на всякий случай”, а управляемый процесс с явным command, args, env и журналом.

Эта страница не повторяет MCP сервер: что это и MCP для Cursor и Codex. Здесь фокус уже практический: как безопасно подключить локальный сервер, проверить его и решить, готов ли он к командному использованию.

Когда локальный сервер уместен

Локальный MCP-сервер подходит, когда источник данных уже находится рядом с пользователем или репозиторием, а удаленный сервис добавляет лишнюю сложность.

Если агенту нужно читать корпоративные системы для многих пользователей, лучше проектировать remote MCP или backend API с нормальной авторизацией. Локальный сервер хорош для пилота, разработки, личного workspace и узких командных tools.

Минимальная схема подключения

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

{
  "mcpServers": {
    "project-docs": {
      "command": "node",
      "args": ["tools/mcp/project-docs.js", "--root", "${workspaceFolder}/docs"],
      "env": {
        "MCP_LOG_LEVEL": "info"
      }
    }
  }
}

В этой схеме важны не конкретные Node.js или Python, а ограничения:

• команда запуска фиксирована;
• директория передается явно;
• сервер не читает весь диск;
• секреты не лежат в конфигурации;
• logs пишутся в понятное место;
• ошибка запуска видна до работы с реальными задачами.

Официальный tutorial по локальным серверам показывает этот же принцип на filesystem-сервере: клиент стартует сервер из JSON-конфигурации и передает ему список разрешенных директорий, а пользователь подтверждает действия: Connect to local MCP servers. Для компании это означает: путь в args - часть security boundary, а не техническая мелочь.

Что разрешить в первом пилоте

MCP servers могут отдавать tools, resources и prompts. В документации MCP tools описаны как schema-defined интерфейсы, которые модель может вызвать, а resources - как passive data sources для контекста: Understanding MCP servers. В локальном пилоте начинайте с resources и read-only tools.

Пример allowlist:

local_mcp_pilot:
  resources:
    - docs://project-readme
    - docs://runbooks/{name}
    - repo://service-map
  tools:
    docs_search:
      mode: read
      max_results: 8
    task_status:
      mode: read
      allowed_projects: [current]
    test_summary:
      mode: read
      command: npm test -- --reporter=json
  forbidden:
    - read_home_directory
    - read_env_file
    - run_shell
    - deploy
    - edit_crm
    - write_repository

Не называйте tool слишком широко. run_command, query, request и admin_action почти всегда становятся проблемой. Лучше сделать три скучных tools с понятными параметрами, чем один универсальный tool, который нельзя проверить.

Секреты и директории

Локальный MCP запускается с правами пользователя. Это удобно, но опасно: сервер часто видит то же, что видит человек в терминале. Поэтому первый вопрос не “как подключить”, а “что сервер точно не должен увидеть”.

Проверка перед включением:

• нет доступа к .env, keychain export, SSH keys и браузерным профилям;
• paths в конфигурации абсолютные или workspace-scoped;
• server не принимает path traversal через параметры;
• временные файлы не сохраняют исходные документы целиком;
• logs не пишут токены, персональные данные и полные ответы модели;
• network disabled или ограничен, если сервер работает только с локальными файлами;
• destructive tools отсутствуют, а не просто запрещены prompt-ом.

Если нужен API key, храните его вне project config. Для командного rollout лучше использовать secret store или managed extension/configuration layer. Для локального пилота достаточно правила: секрет не попадает в mcp.json, README, examples и task history.

Проверка через Inspector

До подключения к реальному AI-клиенту проверьте сервер отдельно. MCP Inspector предназначен для тестирования и отладки servers: он показывает connection pane, resources, prompts, tools, schemas, результаты вызова и notifications: MCP Inspector.

Минимальная проверка:

npx @modelcontextprotocol/inspector node tools/mcp/project-docs.js --root ./docs

Что смотреть:

Если сервер работает только внутри конкретного клиента и его нельзя прогнать отдельно, сопровождать его будет трудно. Для production-like пилота нужна воспроизводимая команда проверки.

Локальный HTTP: когда нельзя расслабляться

Иногда локальный сервер запускают не через stdio, а как HTTP endpoint. Это не делает его безопаснее. В спецификации Streamable HTTP отдельно выделены риски: при локальном запуске сервер должен bind-иться к 127.0.0.1, проверять Origin и использовать authentication, иначе возможны атаки через DNS rebinding: MCP transports.

Практическое правило:

stdio for first local pilot
localhost HTTP only with Origin check, auth and logs
0.0.0.0 only after security review
remote MCP only with normal identity and access control

Если команда не может объяснить, кто может подключиться к локальному HTTP-серверу, не запускайте его. Для большинства рабочих мест stdio проще и безопаснее.

Rollout для команды

Не раскатывайте локальный MCP всем разработчикам одним файлом. Сначала проверьте 3-5 реальных задач и только потом добавляйте людей.

План:

1. Выбрать один reader job: например, поиск по docs или чтение статуса задач.
2. Назначить владельца сервера и владельца данных.
3. Описать allowed resources/tools и forbidden actions.
4. Проверить сервер через Inspector.
5. Подключить одному пользователю.
6. Собрать logs по 20-30 вызовам.
7. Убрать лишние tools и поля.
8. Добавить README с командой проверки и способом отключения.
9. Подключить команду через project config или managed extension.

Для командного репозитория этот rollout связан с правилами из статьи MCP для Cursor и Codex: агент может получать контекст, но diff, тесты и изменения прав остаются в обычном процессе ревью.

Чеклист

• Есть один локальный сценарий, а не “все tools сразу”.
• Сервер стартует отдельной командой и проверяется без AI-чата.
• Первый транспорт - stdio, если нет причины для HTTP.
• Разрешенные директории перечислены явно.
• Секреты не лежат в конфигурации.
• Tools узкие, schema-defined и read-only на старте.
• Нет произвольного shell, SQL, path access и production write.
• Logs есть, но не содержат токены и персональные данные.
• Inspector показывает только ожидаемые resources/tools.
• Есть owner, README, rollback и способ быстро отключить сервер.

FAQ

Чем локальный MCP отличается от обычного скрипта?

Скрипт запускается человеком или pipeline. MCP-сервер дает AI-клиенту discoverable resources/tools с описанием и schema. Это удобно, когда агенту нужен повторяемый контекст, но требует более строгих границ.

Можно ли дать серверу доступ ко всему репозиторию?

Иногда да, но не начинайте с этого. Лучше открыть docs/, schema/ или read-only карту сервисов и расширять доступ после логов реальных вызовов.

Нужен ли локальный MCP для Cursor?

Только если Cursor или другой агент регулярно не хватает внешнего контекста: docs, task status, service map, CI summary. Если задача решается обычным чтением файлов в репозитории, MCP может быть лишним.

Что делать, если серверу нужен .env?

Не отдавать .env как файл. Передайте минимальные переменные окружения через безопасный механизм запуска и проверьте, что logs их не печатают.

Когда переходить на remote MCP?

Когда один локальный сервер начали копировать между людьми, появились разные версии конфигурации, нужны централизованные права, audit log и доступ к общим системам. Это уже не локальная удобная утилита, а сервисный контур.