1 июля 2026 года Atlassian опубликовала цифру, которая звучит буднично и при этом ломает привычную картину: Rovo MCP превысил 5 миллионов вызовов. Это данные самой компании из блога о работе Rovo MCP. Независимый трекер релизов Releasebot тем же июлем зафиксировал соответствующее обновление платформы.
Важно сразу отделить факт от красивой интерпретации. 5 миллионов - это счётчик вызовов протокола, а не 5 миллионов пользователей и не 5 миллионов закрытых задач. Но даже в таком аккуратном прочтении цифра говорит о главном сдвиге: Jira и Confluence всё чаще открывают не человеком через браузер, а программным агентом через MCP. Инструмент, спроектированный для людей, стал ещё и API-поверхностью для машин.
Дальше - разбор без маркетинга. Что именно раскрыла Atlassian, что такое MCP на пальцах, как выглядит вызов в коде, почему счётчик вызовов нельзя пересчитывать в деньги, и что со всем этим делать инженеру из России, у которого нет прямого доступа к части зарубежных моделей.
Что именно раскрыла 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-фильтра. Агент оправдан там, где нужно рассуждение поверх неструктурированного текста: собрать разрозненное, переформулировать, связать задачу с документом. Ниже - компактная таблица для решения.
| Сценарий | Агент над MCP | Обычная автоматизация | Просто фильтр/поиск |
|---|---|---|---|
| Собрать заметку по спринту из десятков задач | Да, есть текст и обобщение | Частично, без связного текста | Нет |
| Перевести задачу в статус по событию | Избыточно | Да, правило надёжнее | Нет |
| Найти похожие инциденты в Confluence | Да, нужен смысловой поиск | Нет | Частично |
| Массово проставить лейблы по JQL | Нет | Да | Да, через фильтр |
| Ответить на вопрос по вики своими словами | Да | Нет | Нет |
Логика простая: чем больше в задаче свободного текста и обобщения, тем оправданнее агент. Чем чётче правило «если событие - то действие», тем лучше работает обычная автоматизация без модели и без лишних вызовов. А если задача сводится к выборке - не надо ни агента, ни модели, хватит JQL.
Отдельно про российскую специфику. Главная практическая развилка здесь не в самом MCP - протокол открытый и от географии не зависит, - а в доступе к моделям, которые играют роль мозга. Если твой агент завязан на зарубежную модель, тебе нужен стабильный способ до неё дотянуться из РФ, без VPN и без зарубежной карты, иначе прод будет падать не из-за логики, а из-за сети и оплаты.
Тут работает простой приём: держать доступ к нескольким моделям через один совместимый эндпоинт и переключать их по цене и качеству, не переписывая интеграцию. provod.ai собирает Claude, GPT, Gemini, DeepSeek и Qwen в одном чате и отдаёт один API, совместимый с SDK OpenAI и Anthropic: меняешь ключ и base_url - код агента остаётся прежним. Оплата рублями с карты, через СБП или по счёту, а для бухгалтерии есть договор, счёт и закрывающие документы. При этом provod.ai не заменяет саму платформу автоматизации, не даёт GigaChat, не подменяет приватную или on-prem инфраструктуру и не делает за тебя внедрение - это доступ к моделям, а не к Jira.
Как подключить свой агент за один вечер?
Пошаговый план для минимального рабочего прототипа над своим стендом. Никакой магии, всё крутится вокруг двух частей: инструмент и модель.
- Подними MCP-сервер для Jira и Confluence или используй Rovo, если ты уже в экосистеме Atlassian. На этом шаге проверь права: агент должен ходить под сервисной учёткой с минимально нужным доступом, а не под админом.
- Возьми модель с поддержкой tool use и убедись, что она доступна из твоей сети. Проверь связность и оплату заранее, до написания логики.
- Замкни цикл: модель просит инструмент - твой код исполняет вызов через MCP - результат возвращается в диалог. Ограничь число шагов в одном прогоне, чтобы агент не зациклился.
- Добавь бюджет вызовов и токенов на один прогон и логируй каждый вызов. Это твоя честная замена метрике Atlassian: тебе нужен не общий счётчик, а стоимость одного полезного результата.
- Тестируй на негативных случаях: пустой 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.
Собери прототип агента над Jira и Confluence сегодня, а модель для него подключи через provod.ai - один API, рублёвый баланс, без VPN.
Источники
- Atlassian, блог о работе Rovo MCP (первичный источник, объём вызовов и рост использования): https://www.atlassian.com/blog/company-news/inside-rovo-mcp-usage
- Releasebot, независимый трекер релизов Atlassian (июльское обновление): https://releasebot.io/updates/atlassian
provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.
Try: provod.ai · model catalog · docs
Top comments (0)