Rovo MCP превысил 5 млн вызовов: Atlassian Rovo MCP 5 million calls Jira Confluence

Важно сразу отделить факт от красивой интерпретации. 5 миллионов - это счётчик вызовов протокола, а не 5 миллионов пользователей и не 5 миллионов закрытых задач. Но даже в таком аккуратном прочтении цифра говорит о главном сдвиге: Jira и Confluence всё чаще открывают не человеком через браузер, а программным агентом через MCP. Инструмент, спроектированный для людей, стал ещё и API-поверхностью для машин.

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

По данным Atlassian, речь идёт о двух вещах. Первая - накопленный объём: Rovo MCP превысил отметку в 5 миллионов вызовов. Вторая - рост ежедневного использования: компания сообщает, что дневная нагрузка увеличивается. Конкретных дневных чисел, разбивки по клиентам или доли Jira против Confluence в первичном источнике я не нашёл, поэтому не привожу их - иначе это было бы выдумкой.

Что стоит за словом «вызов». MCP (Model Context Protocol) - это протокол, по которому языковая модель или агент обращается к внешнему инструменту: получает список доступных операций, вызывает их с аргументами и получает результат. Один разговор агента с Jira - «найди задачи спринта, отфильтруй по исполнителю, обнови статус» - легко разворачивается в несколько отдельных вызовов. Поэтому счётчик вызовов растёт быстрее, чем число реальных пользовательских сценариев.

Отсюда первый практический вывод. Цифра 5 миллионов - это индикатор адопшена паттерна, а не бизнес-результата. Она честно отвечает на вопрос «стали ли агенты массово трогать рабочие данные». И честно молчит про вопрос «сколько денег это сэкономило» - на него без данных клиентов ответить нельзя.

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

Раньше интеграция с трекером выглядела так: разработчик руками писал обёртку над REST API Jira, описывал каждый эндпоинт, парсил ответы, чинил это после каждого обновления схемы. Модель в такой схеме была слепой - она умела только генерировать текст, а всю «мышечную» работу писал человек.

MCP переворачивает подход. Инструмент сам публикует машиночитаемое описание своих операций: какие есть действия, какие у них параметры, что вернётся. Агент подключается к такому MCP-серверу, видит каталог операций и вызывает нужные сам, по ходу рассуждения. Для Jira это операции вроде «найти задачи по JQL», «создать задачу», «сменить статус»; для Confluence - «найти страницу», «прочитать содержимое», «создать заметку».

Ключевой сдвиг в том, что поверхность, спроектированная для человека, теперь одинаково доступна и человеку, и агенту. Один и тот же спринт-борд в Jira открывается глазами через браузер и вызовами через протокол. Именно поэтому счётчик Atlassian растёт: каждый агентский сценарий над рабочими данными - это пачка вызовов.

И здесь же кроется причина, по которой цифру нельзя переоценивать. Пять вызовов на один осмысленный результат - нормальная картина. Поэтому 5 миллионов вызовов честнее читать как «протокол стал рабочим», а не как «агенты сделали 5 миллионов полезных дел».

Разберём минимальный сценарий: агент собирает задачи спринта из Jira и оформляет по ним заметку в Confluence. Архитектурно у тебя две независимые части. Первая - MCP-сервер, который даёт агенту инструменты Jira и Confluence. Вторая - языковая модель, которая играет роль «мозга»: читает задачу, решает, какие инструменты дёрнуть, и формулирует итог.

Модель и инструмент не обязаны быть от одного вендора. MCP-сервер отвечает за доступ к данным, а модель ты можешь взять любую, лишь бы она умела в tool use и была доступна из твоей сети. Ниже - компактный пример на Python, где «мозгом» выступает Claude, а вызовы идут через OpenAI/Anthropic-совместимый эндпоинт. Меняются только ключ и base_url.

Обрати внимание на разделение ролей. jira_confluence_tools - это описания операций, которые пришли от MCP-сервера. Модель сама решает, что вызвать и в каком порядке; твой код исполняет вызовы и возвращает результат обратно в диалог. Каждый такой шаг - это один «вызов» в терминах метрики Atlassian, если он идёт через Rovo MCP.

Если тебе нужен не Rovo, а собственный агент над своей Jira, схема та же: поднимаешь MCP-сервер, подключаешь модель, замыкаешь цикл «модель просит инструмент - код исполняет - результат назад». Rovo - это фирменная реализация этого паттерна от Atlassian, а не единственный способ его собрать.

Самая частая ошибка при чтении такой новости - линейный пересчёт. «Пять миллионов вызовов, значит агенты закрыли пять миллионов задач, значит вот столько сэкономленных часов». Ни одного из этих шагов данные Atlassian не поддерживают, и сама компания приводит только объём вызовов и факт роста, без разбивки в деньги.

Разберём, где рвётся логика. Один осмысленный сценарий - это несколько вызовов. Часть вызовов - это чтение и уточнение, а не изменение данных. Часть сценариев агент вообще не доводит до конца: модель может уйти в лишний вызов, получить пустой результат по неверному JQL или зациклиться на уточнениях. Поэтому «вызов» и «результат» - это разные единицы, и коэффициент между ними тебе никто не раскрыл.

Отсюда прямое следствие для твоих собственных отчётов. Если ты строишь агента над Jira и Confluence, не отчитывайся числом вызовов перед бизнесом - это внутренняя техническая метрика. Считай завершённые сценарии, долю успешных прогонов и стоимость токенов на один полезный результат. Вот эти три числа переводятся в решения, а счётчик вызовов - нет.

Ещё одна ловушка - стоимость. Каждый вызов инструмента тянет за собой обращение к модели: она читает результат и решает следующий шаг. Значит длинные агентские цепочки над большими страницами Confluence - это токены, и их надо считать заранее. Метрика вызовов у Atlassian ничего не говорит про твои расходы; про них говорит только твой собственный биллинг модели.

Не каждый сценарий заслуживает агента. Иногда достаточно обычной автоматизации по правилам, а иногда - вообще одного JQL-фильтра. Агент оправдан там, где нужно рассуждение поверх неструктурированного текста: собрать разрозненное, переформулировать, связать задачу с документом. Ниже - компактная таблица для решения.

Логика простая: чем больше в задаче свободного текста и обобщения, тем оправданнее агент. Чем чётче правило «если событие - то действие», тем лучше работает обычная автоматизация без модели и без лишних вызовов. А если задача сводится к выборке - не надо ни агента, ни модели, хватит JQL.

Отдельно про российскую специфику. Главная практическая развилка здесь не в самом MCP - протокол открытый и от географии не зависит, - а в доступе к моделям, которые играют роль мозга. Если твой агент завязан на зарубежную модель, тебе нужен стабильный способ до неё дотянуться из РФ, без VPN и без зарубежной карты, иначе прод будет падать не из-за логики, а из-за сети и оплаты.

Тут работает простой приём: держать доступ к нескольким моделям через один совместимый эндпоинт и переключать их по цене и качеству, не переписывая интеграцию. provod.ai собирает Claude, GPT, Gemini, DeepSeek и Qwen в одном чате и отдаёт один API, совместимый с SDK OpenAI и Anthropic: меняешь ключ и base_url - код агента остаётся прежним. Оплата рублями с карты, через СБП или по счёту, а для бухгалтерии есть договор, счёт и закрывающие документы. При этом provod.ai не заменяет саму платформу автоматизации, не даёт GigaChat, не подменяет приватную или on-prem инфраструктуру и не делает за тебя внедрение - это доступ к моделям, а не к Jira.

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

Отдельно про наблюдаемость. Раз каждый шаг - это вызов, тебе нужен трейс всей цепочки: какой инструмент вызван, с какими аргументами, что вернулось. Без этого ты не отладишь ни зацикливания, ни лишние вызовы, ни рост стоимости. По сути ты воспроизводишь у себя ту же телеметрию, из которой Atlassian и получила свою публичную цифру.

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

Здесь важно быть честным, потому что вокруг агентных метрик много завышенных ожиданий.

Метрика вызовов не доказывает пользу. 5 миллионов вызовов - это факт про адопшен протокола, а не про сэкономленные часы или деньги. Про пользу можно говорить только на своих данных: сколько сценариев доведено до конца и сколько это стоило.

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

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

И доступ к моделям - это отдельная задача. Rovo MCP решает связь агента с рабочими данными, но не решает, откуда ты возьмёшь саму модель и как оплатишь её из России. Это две разные проблемы, и путать их не стоит.

5 миллионов вызовов - это много? Это заметный объём, показывающий, что паттерн вышел из стадии демо. Но переводить его в число пользователей или задач нельзя: Atlassian раскрыла именно вызовы и факт роста дневного использования, без разбивки.

MCP - это только про Rovo и Atlassian? Нет. MCP - открытый протокол доступа моделей к инструментам. Rovo - фирменная реализация паттерна от Atlassian для Jira и Confluence. Свой агент над своим трекером можно собрать по той же схеме.

Можно ли использовать любую модель как мозг агента? Да, если она поддерживает tool use и доступна из твоей сети. MCP-сервер отвечает за инструменты, модель - за рассуждение; это независимые части, и модель заменяема.

Как считать экономику агента? Не по числу вызовов, а по стоимости одного завершённого сценария: токены модели плюс доля неуспешных прогонов. Общий счётчик вызовов для бизнес-отчёта бесполезен.

Что с доступом к моделям из России? Сам протокол от географии не зависит. Проблема - в доступе к зарубежным моделям и оплате. Её решают агрегаторы с рублёвым балансом и совместимым API, вроде provod.ai, где меняешь только ключ и base_url.

Собери прототип агента над Jira и Confluence сегодня, а модель для него подключи через provod.ai - один API, рублёвый баланс, без VPN.

Один OpenAI-совместимый endpoint ко всем флагманам: OpenAI (GPT-5.5, GPT-5.4), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus.

Цены 1-в-1 с провайдером по курсу ЦБ— без наценки на токены. Оплата в рублях по договору, полный пакет закрывающих документов (договор-оферта, счёт, акт, счёт-фактура, УПД 5.03 через ЭДО). Без VPN — легальный B2B-сервис в России.

Если статья была полезной— попробуйте provod.ai: главная страница · каталог моделей · документация