Что вы реально получаете (и не получаете), подключая Claude или Cursor к Jira и Linear через MCP

Подключить Claude Code или Cursor к Jira или Linear через MCP можно за пять минут, и работает это ровно так, как обещано: агент может читать и писать тикеты. А вот чего он не может, так это ничего сверх того, что мог бы сделать человек, нажимая те же кнопки в том же workflow-движке Jira или Linear. Потому что MCP-сервер именно это и пробрасывает, один в один.

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

Как подключить Claude Code и Cursor к Jira

Официальный удалённый MCP-сервер Atlassian вышел в GA в феврале 2026 года, крутится на mcp.atlassian.com и покрывает Jira, Confluence, Jira Service Management, Bitbucket и Compass. Только облако: для self-hosted Jira официального сервера просто нет.

В Claude Code:

claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2

Дальше /mcp внутри сессии, и в браузере проходит OAuth 2.1. В Cursor сервер добавляется через Settings → MCP или по deep-ссылке от самого Atlassian, которая пишет тот же URL в mcp.json.

Экран OAuth-согласия не формальность. Именно то, что вы там подтвердите, определяет, до чего дотянется агент. Вот деталь, которую стоит перечитать дважды, из собственных заметок Atlassian по безопасности: «MCP-клиенты могут выполнять действия в продуктах Atlassian с вашими текущими правами» (в оригинале: "with your existing permissions"). Отдельного, более узкого набора прав для агента не существует. Он получает ровно то, что есть у вас.

Как подключить Claude Code и Cursor к Linear

Удалённый сервер Linear живёт на mcp.linear.app/mcp. В Claude Code:

claude mcp add --transport http linear https://mcp.linear.app/mcp

и следом /mcp для авторизации, та же схема, что у Atlassian. Cursor’у нужен небольшой мост, потому что поддержка удалённого MCP там ещё свежая:

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.linear.app/mcp"]
    }
  }
}

Сама Linear предупреждает, что «удалённые MCP-подключения пока в раннем состоянии, и соединение может не установиться с первого раза». Это не баг конкретно Cursor, а реальное состояние удалённого MCP как класса на конец 2026 года: закладывайте минимум одну повторную попытку рукопожатия, прежде чем подозревать свой конфиг.

Что реально даёт сырой MCP-доступ

После подключения агент может искать, читать, создавать, комментировать и переводить тикеты между статусами. Тот же набор действий, что доступен в веб-интерфейсе. Контроль доступа у обоих вендоров грубый: в Linear можно запросить OAuth-скоуп read или указать отдельный mcp/readonly-эндпоинт, где write-инструментов вообще нет; у Atlassian права сгруппированы в read_jira, write_jira, search_jira, а для админов ещё delete_jira и manage_jira.

Это вся модель доступа целиком. Только чтение или чтение-и-запись, по продукту, на всё подключение сразу. Ни у одного из серверов нет понятия «этот агент может переводить статусы в проекте A, но не может удалять тикеты в проекте B», потому что сама модель прав в продукте под это не строилась. Агент наследует ровно то, что мог бы сделать человек с вашим логином.

Atlassian действительно пишет каждый вызов инструмента в аудит-лог организации: это реально и это больше, чем упоминает документация Linear. Но запись в логе привязана к вашему аккаунту, а не к отдельной идентичности агента, потому что с точки зрения системы прав Jira никакого агента не существует. Есть только ваш OAuth-токен, которым сейчас пользуется программа, а не вкладка браузера.

Чего там структурно нет

Четыре пробела, и ни один из них не включается галочкой в настройках. Их нет, потому что модель прав и workflow в Jira и Linear никогда не проектировалась с расчётом на нечеловеческого актора.

Тарификация риска в момент выполнения. Ничто не отличает «добавить комментарий» от «перевести тикет в Done» или «удалить issue» в момент, когда агент вызывает инструмент. Write-скоуп один на всё, других градаций нет. Если нужен автоматический допуск для обратимых действий и стоп-кран для деструктивных, эту логику придётся писать самим поверх MCP-подключения, потому что ни один из серверов её не поставляет.

Доказательство перед «готово». Ничто в логике переходов Jira или Linear не проверяет, существует ли PR, смёржен ли он и прошёл ли CI, прежде чем агент переведёт тикет в Done. Доска покажет ровно то, что заявил агент, потому что workflow-движок всегда доверял этому от человека, и применяет то же доверие к тому, что сейчас дёргает API-токен.

Идентичность агента, отдельная от вашей. Оба сервера аутентифицируются как вы. Если через один и тот же OAuth-грант подключены три агента (кодовый ассистент, QA-бот, скрипт-триажер), Jira и Linear видят одного актора: ваш аккаунт. Ограничить, зарейтлимитить или отозвать доступ одному из них, не трогая остальных, нельзя: credential-то один на всех.

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

Честный вывод

Всё это не значит, что нужно уходить с Jira или Linear. Для огромной доли реального использования агент, который читает тикеты, черновит апдейты и двигает карточки в рамках ваших прав, это ровно тот уровень доступа, который и нужен. А официальный путь туда у обоих вендоров сделан и поддерживается быстрее, чем это сделает любая сторонняя интеграция.

Знать эти четыре пробела важно не ради теории, а потому что именно в них лежит риск в тот момент, когда у агента появляется запись в ваш трекер. Не в том, что он технически может сделать (это идентично тому, что можете вы сами), а в том, что ничто структурно не мешает ему сделать неправильную версию этого же действия в три часа ночи, пока никто не смотрит, под идентичностью, которую потом невозможно вычленить.

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