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

1 июля 2026 года Atlassian опубликовала цифру, которая звучит буднично и при этом ломает привычную картину: Rovo MCP превысил 5 миллионов вызовов. Это данные самой компании из блога о работе Rovo MCP. Независимый трекер релизов Releasebot тем же июлем зафиксировал соответствующее обновление платформы.

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

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

Подключите AI-агентов с оплатой в рублях на provod.ai

Что именно раскрыла Atlassian?

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

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

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

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

Что такое MCP и почему Jira с Confluence стали инструментами агентов?

Раньше интеграция с трекером выглядела так: разработчик руками писал обёртку над 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.

from anthropic import Anthropic

client = Anthropic( api\_key="provod\_your\_key", base\_url="https://api.provod.ai/anthropic", )

# tools здесь - это операции, которые агенту отдал MCP-сервер Jira/Confluence resp = client.messages.create( model="claude-opus-4-8", max\_tokens=1024, tools=jira\_confluence\_tools,   # каталог операций из MCP-сервера messages=[{ "role": "user", "content": "Собери задачи текущего спринта из Jira и оформи по ним заметку в Confluence", }], ) print(resp.content)

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

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

Почему 5 млн вызовов - это не 5 млн задач и не ROI?

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

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

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

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

Когда вообще стоит строить агента над Jira и Confluence?

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

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

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

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

Как подключить свой агент за один вечер?

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

1. Подними MCP-сервер для Jira и Confluence или используй Rovo, если ты уже в экосистеме Atlassian. На этом шаге проверь права: агент должен ходить под сервисной учёткой с минимально нужным доступом, а не под админом.
2. Возьми модель с поддержкой tool use и убедись, что она доступна из твоей сети. Проверь связность и оплату заранее, до написания логики.
3. Замкни цикл: модель просит инструмент - твой код исполняет вызов через MCP - результат возвращается в диалог. Ограничь число шагов в одном прогоне, чтобы агент не зациклился.
4. Добавь бюджет вызовов и токенов на один прогон и логируй каждый вызов. Это твоя честная замена метрике Atlassian: тебе нужен не общий счётчик, а стоимость одного полезного результата.
5. Тестируй на негативных случаях: пустой JQL, страница Confluence без доступа, слишком большой документ. Агент должен деградировать предсказуемо, а не выдумывать ответ.

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

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

Чего это не решает?

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

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

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

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

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

FAQ

5 миллионов вызовов - это много?

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

MCP - это только про Rovo и Atlassian?

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

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

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

Как считать экономику агента?

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

Что с доступом к моделям из России?

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

provod.ai — снизьте зависимость продукта от одного вендора

Не зашивайте всю архитектуру в особенности одной модели: общий совместимый API позволяет менять поставщика под качество, доступность и новую задачу, сохраняя прикладной контур.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Независимость не покупается через повышенный тариф: provod.ai сохраняет официальную цену каждой модели 1:1 и не добавляет свою маржу.

Сделайте AI-стек гибче: форма регистрации · цены на модели · защита данных по 152-ФЗ · инструкция по миграции

Источники

• Atlassian, блог о работе Rovo MCP (первичный источник, объём вызовов и рост использования): https://www.atlassian.com/blog/company-news/inside-rovo-mcp-usage
• Releasebot, независимый трекер релизов Atlassian (июльское обновление): https://releasebot.io/updates/atlassian