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

Раздел

MCP-серверы

Сложность

средняя

Обновлено

2026-05-21

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

Cursor MCP стоит подключать как проектный preflight, а не как “включить все tools в редакторе”. Сначала выберите один источник контекста: документация, issue tracker, дизайн, локальный справочник или read-only API. Затем решите, где живет конфигурация, какой transport нужен, где лежат секреты, какие tools видит агент и кто подтверждает вызовы.

Для командного репозитория чаще всего начинать лучше с .cursor/mcp.json, потому что проектная конфигурация ревьюируется вместе с кодом и не протекает в другие рабочие папки. Global ~/.cursor/mcp.json удобен для личных серверов, но хуже подходит для общего rollout: один глобальный Figma, Context7 или internal-docs сервер легко начинает появляться в задачах, где команда его не планировала.

На 21 мая 2026 года Cursor в своей MCP-документации описывает stdio, SSE и Streamable HTTP, project/global конфигурацию и approval перед tool-вызовами: Cursor MCP docs. В базовой спецификации MCP современный стандартный набор transport уже сведен к stdio и Streamable HTTP, а HTTP+SSE остается совместимостью для старых клиентов: MCP transports. Поэтому в runbook фиксируйте не только “Cursor MCP включен”, а конкретный transport и дату проверки.

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

Что именно подключаете

Под запросом cursor mcp обычно смешаны четыре разные задачи.

Если MCP нужен только чтобы Cursor увидел файлы репозитория, остановитесь. Cursor и так работает с проектом. MCP оправдан, когда агенту нужен внешний повторяемый источник или tool, которого нет в обычной рабочей директории.

Project или global config

Project config подходит для командного контура:

repo/
  .cursor/
    mcp.json
  docs/
  src/

В project config кладите только те серверы, которые нужны именно этому репозиторию. Пример: team-docs, design-context, ci-readonly. Если сервер нужен одному разработчику для всех проектов, например личный docs-поиск, лучше держать его в global config и не заставлять команду наследовать этот контур.

Минимальная карточка для каждого сервера:

Cursor CLI использует ту же MCP-конфигурацию, что и редактор, и дает команды для списка серверов и tools: Cursor CLI MCP docs. Это удобно для проверки, но не отменяет ревью самого mcp.json.

Transport: stdio, SSE или HTTP

Для первого project-scoped сервера выбирайте stdio, если сервер локальный и запускается как подпроцесс. В спецификации MCP клиент запускает server process, сервер читает JSON-RPC из stdin, пишет MCP-сообщения в stdout, а logs должен отправлять в stderr, чтобы не ломать протокол: MCP transports.

Streamable HTTP нужен, когда сервер живет отдельно и должен обслуживать несколько клиентов. В этом случае обязательны нормальная authentication, проверка Origin для локальных серверов и bind к 127.0.0.1, если сервер запускается на рабочей машине. Не используйте 0.0.0.0 в локальном MCP без security review.

SSE в Cursor docs все еще встречается как поддерживаемый transport. Для нового внутреннего сервера проверьте совместимость клиента и сервера в день подключения. Если vendor дает только SSE endpoint, фиксируйте это как vendor constraint, а не как внутренний стандарт.

Минимальный project config

Пример формы для server-а, который читает только проектные docs:

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

Что важно в примере:

• путь ограничен docs/, а не всем home directory;
• server name скучный и понятный;
• в env нет токена;
• command и args ревьюируются;
• server можно отключить удалением одного блока;
• logs не попадают в stdout;
• первый tool read-only.

MCP roots помогают клиенту сообщить серверу, с какими filesystem areas он работает, но это не полноценная security boundary. Официальные client concepts прямо разделяют roots как scope coordination и реальное enforcement через права ОС или sandbox: MCP client concepts. Поэтому root в config не заменяет allowlist внутри сервера.

Секреты и OAuth

Для local stdio не кладите API key в mcp.json как literal value. Используйте environment variable reference, secret manager, shell profile или отдельный локальный файл вне Git. В task, README, screenshot и chat не должно быть реального значения ключа.

Для remote server лучше OAuth или короткоживущие токены с audience binding. MCP authorization specification требует bearer token в Authorization header для HTTP-запросов и запрещает access token в URI query string: MCP authorization. Для команды это простое правило: если vendor просит вставить token в URL, не добавляйте такой сервер в Cursor без отдельного review.

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

Tools и approval

MCP tools model-controlled: модель может выбрать tool по контексту. В спецификации tools поэтому отдельно говорится о human in the loop, понятном UI для exposed tools и confirmation prompts: MCP tools. Cursor тоже показывает tool calls и по умолчанию требует approval перед MCP tool-вызовом.

Не рассчитывайте на название tool как на контроль. docs_search безопасен только если сервер действительно ищет в разрешенном корпусе, не читает соседние директории и не возвращает секретные snippets. Хороший первый набор:

cursor_mcp_pilot:
  tools:
    docs_search:
      mode: read
      max_results: 8
      sources: [project_docs]
    issue_read:
      mode: read
      fields: [title, body, status, acceptance_criteria]
    ci_status:
      mode: read
      branches: [main, current_branch]
  forbidden:
    - run_shell
    - read_env
    - deploy
    - write_issue_status
    - edit_figma_canvas

Write tools добавляйте только после нескольких реальных read-only задач. Даже тогда лучше режим draft: агент готовит изменение, человек нажимает publish, merge, send или apply.

Figma и Context7

Figma и Context7 полезны, но это разные классы MCP.

Figma MCP - это design context и, в remote варианте, tools для design/write workflows. Официальная документация Figma рекомендует remote MCP server, описывает OAuth flow, Cursor plugin /add-plugin figma и tools вроде получения design context, screenshots, variables, Code Connect mappings и write-to-canvas: Figma remote MCP setup. Для продуктовой команды это значит: Figma можно подключать, когда задача реально про дизайн, но write tools должны быть отдельным approval-контуром.

Context7 - это docs context. Его Cursor guide описывает setup через npx ctx7 setup --cursor, OAuth/API key и режимы CLI или MCP: Context7 for Cursor. В privacy docs Context7 отдельно говорит, что MCP-клиент отправляет formulated query и library id, а не весь исходный prompt или source code. Но это все равно внешний сервис, поэтому не отправляйте в query имена клиентов, private API, токены, закрытые фрагменты кода и NDA-контекст.

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

Не подключайте Figma и Context7 просто потому, что они популярны в Cursor MCP запросах. Они должны отвечать на конкретный reader job.

Проверка перед rollout

Перед тем как команда начнет пользоваться MCP в задачах, прогоните короткий preflight.

1. Откройте Cursor в тестовом репозитории.
2. Подключите только один server.
3. Проверьте, что server виден в списке MCP.
4. Посмотрите список tools.
5. Выполните один read-only запрос.
6. Проверьте logs: нет токенов, raw headers, customer data.
7. Отключите server и убедитесь, что задача продолжает работать без него.
8. Запишите owner, rollback и дату проверки.

Для CLI-контуров используйте cursor-agent mcp list и cursor-agent mcp list-tools <identifier>, если ваша версия Cursor CLI поддерживает эти команды. Для локального server-а отдельно запустите его тестовой командой и убедитесь, что logs идут в stderr, а не смешиваются с протоколом.

Ревью и журнал

Хороший MCP rollout оставляет след:

На pull request полезно просить автора указать, использовался ли MCP и какие источники повлияли на diff. Не для бюрократии, а чтобы reviewer понимал: правка основана на локальных файлах, Figma frame, Context7 docs или внутреннем issue.

Если MCP tool дал устаревший ответ, чините источник или server ranking, а не только prompt. Если Cursor часто предлагает широкие calls, уменьшайте tools и убирайте auto-run для этого сервера.

Типовые ошибки

Не лечите эти ошибки добавлением еще одного MCP server-а. Сначала проверьте один server, один tool и один expected result.

Чеклист

• Есть один reader job: docs, task, design или CI.
• Выбран project config для командного сервера или global для личного.
• mcp.json не содержит реальных секретов.
• Transport зафиксирован: stdio, SSE или Streamable HTTP.
• Local HTTP не слушает 0.0.0.0.
• Remote server использует OAuth или нормальный bearer token, не token в URL.
• Первый набор tools read-only.
• Write tools отключены или работают только как draft.
• Tool calls требуют approval, пока сервер не проверен.
• Logs не содержат tokens, headers и private source snippets.
• Figma подключается только для design задач.
• Context7 используется только для library docs, без NDA/query утечек.
• Есть owner, test scenario, rollback и дата source check.

FAQ

MCP в Cursor нужен каждому репозиторию?

Нет. Если задача решается обычным чтением файлов и запуском тестов, MCP может быть лишним. Подключайте его, когда нужен внешний источник или повторяемый tool.

Project config лучше global config?

Для команды - чаще да. Project config легче ревьюировать и отключать. Global config удобен для личных инструментов, но может случайно попасть в чужой рабочий контекст.

Можно ли начинать с Figma MCP?

Можно, если задача действительно про дизайн. Но Figma MCP дает не только context, а и write/canvas workflows в remote варианте. Разделяйте read context и write actions.

Context7 безопасен для private code?

Не отправляйте private code как query. Context7 позиционируется как docs context, а не как хранилище вашего репозитория. Для закрытых источников используйте enterprise/private controls или внутренний docs server.

Что делать, если Cursor docs и MCP spec расходятся?

Следовать конкретному клиенту для настройки Cursor и спецификации для проектирования собственного server-а. В runbook записывайте дату проверки, версию клиента, transport и endpoint.

Когда включать auto-run для tools?

Не на первом rollout. Auto-run допустим только для скучных read-only tools с понятным owner, logs и низкой ценой ошибки.

Что читать дальше?

Для общей архитектуры начните с MCP сервер: что это. Для локального transport и Inspector-проверок смотрите локальный MCP-сервер. Для командного процесса рядом с coding tools откройте Cursor AI для команды и AI coding agents.