Комментарии 3
У себя в компании уже месяца 4 гоняем мою поделку для Jira/confluence - в паблик пока не выкладывал, но в процессе разработки родился фреймворк https://github.com/andrico21/rmcp-server-kit , который как раз замечательно закрывает вопросы авторизации, но для Rust-проектов.
Про «почти 100 инструментов» есть цена, которую видно не на сервере, а на клиенте: список с описаниями и схемами параметров грузится в контекст каждой сессии целиком, и на сотне инструментов модель начинает путать update с get. Я бы отдавал tools/list не всё сразу, а по ролям из Keycloak: аналитику только инструменты его систем, изменяющие — отдельным ключом. Заодно это закрывает то, чего в статье нет: токен у агента полноценный, а содержимое тикета недоверенное, и просьба «обнови описание» из чужого комментария в Jira уйдёт в API от имени сотрудника. А ключи для агентов вы сразу выдаёте с правом записи, или есть режим только на чтение?
на сотне инструментов модель начинает путать update с get
спасибо! дельное замечание
пока что такого не было, но у нас такое вряд ли может произойти
список тулов загружается только для тех интеграций, для которых у пользователя есть настройки
если пользователь добавил только jira, то тулов для confluence он не получит
а вот доступ к самим системам уже идет через стандартный процесс согласования доступов, вне mcp
режима для чтения у нас нет, это регулируется на уровне учетной записи (мы предупреждаем на старте сотрудников что подключениек mcp это не замена обращения к интерфейсу, если у учетки сотрудника есть права batch update, то mcp их не ограничивает)

У нас есть MCP дома