Про «инструмент != эндпоинт» подпишусь под каждым словом - оборачивать API в tools один к одному - дорогой способ получить неработающего агента. Каждый эндпоинт в списке - это токены, которые платятся в каждом диалоге, и лишний шанс для модели позвать не то. Добавлю критерий нарезки, который нам помог: формулировка живого пользователя. Провалы агентов концентрируются там, где инструмент надо подобрать по размытой человеческой фразе вроде «почему упал платёж?». Поэтому резать стоит не по HTTP-глаголам и даже не по «намерениям» из головы разработчика, а по реальным репликам. Мы делали похожую обёртку над платёжным API: из полного контракта получилось восемь инструментов, полный tools/list - около 4 000 токенов, набор «только чтение» - около 1 100. Размер описаний закреплён отдельным тестом: бюджет падает в CI так же, как сломанная арифметика, иначе описания незаметно отрастают обратно.
Двухшаговое подтверждение с одноразовым токеном по хешу канонизированных аргументов - мы независимо пришли почти к той же схеме (у нас TTL - 15 минут), похоже, это уже устойчивый паттерн. Два дополнения из платёжной специфики, которые лягут и на панель. Выше порога подтверждающее значение должен ввести человек: значение, подставленное той же стороной, которая собрала операцию, подтверждением не считается. И в текст describeConsequences нельзя пускать сырые строки из внешних данных - у нас сводка собирается только из известных полей с жёсткой очисткой, потому что из внешнего реестра может приехать текст, адресованный модели.
Про отложенную элиситацию. В редакции протокола от 28.07.2026 она превратилась в возврат «нужны данные» с повторным вызовом - ваша токенная механика ложится на это почти без изменений. Единственное, что стоит зафиксировать заранее: закрытый диалог - отказ, молчание согласием не считается.
Мне как читателю не хватило раздела про поведение при обрыве связи. Агент при таймауте не «проверит глазами» (несмотря на то, что коллега с франзуским акцентом любит всё проверять глазами и править руками), а повторит вызов - для деструктивных операций это второй restart core. У нас на этом месте детерминированный ключ операции (повтор возвращает прежний результат) и честный исход «неизвестно» вместо угадывания.
И раз уж вы довели конвейер до OIDC с provenance - проверил из любопытства - у marzban-sdk и marzban-mcp аттестации на месте, npm audit signatures проходит. Для пакета, который ставят одной командой рядом с продовым токеном, это заметная часть доверия, и большинство MCP-серверов в реестре этим до сих пор пренебрегает.
Если интересно сравнить решения на смежном домене - деньги вместо инфраструктуры, - мы недавно разложили те же грабли по полочкам: механика подтверждений и идемпотентности (https://www.invoicebox.ru/ru/blog/mcp-server-money) и границы доверия с расходом контекста (https://www.invoicebox.ru/ru/blog/mcp-server-trust). Совпадений с вашим списком неприлично много - хорошая новость для всех, кто такое строит.
Information
Rating
5,575-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Про «инструмент != эндпоинт» подпишусь под каждым словом - оборачивать API в tools один к одному - дорогой способ получить неработающего агента. Каждый эндпоинт в списке - это токены, которые платятся в каждом диалоге, и лишний шанс для модели позвать не то. Добавлю критерий нарезки, который нам помог: формулировка живого пользователя. Провалы агентов концентрируются там, где инструмент надо подобрать по размытой человеческой фразе вроде «почему упал платёж?». Поэтому резать стоит не по HTTP-глаголам и даже не по «намерениям» из головы разработчика, а по реальным репликам. Мы делали похожую обёртку над платёжным API: из полного контракта получилось восемь инструментов, полный tools/list - около 4 000 токенов, набор «только чтение» - около 1 100. Размер описаний закреплён отдельным тестом: бюджет падает в CI так же, как сломанная арифметика, иначе описания незаметно отрастают обратно.
Двухшаговое подтверждение с одноразовым токеном по хешу канонизированных аргументов - мы независимо пришли почти к той же схеме (у нас TTL - 15 минут), похоже, это уже устойчивый паттерн. Два дополнения из платёжной специфики, которые лягут и на панель. Выше порога подтверждающее значение должен ввести человек: значение, подставленное той же стороной, которая собрала операцию, подтверждением не считается. И в текст describeConsequences нельзя пускать сырые строки из внешних данных - у нас сводка собирается только из известных полей с жёсткой очисткой, потому что из внешнего реестра может приехать текст, адресованный модели.
Про отложенную элиситацию. В редакции протокола от 28.07.2026 она превратилась в возврат «нужны данные» с повторным вызовом - ваша токенная механика ложится на это почти без изменений. Единственное, что стоит зафиксировать заранее: закрытый диалог - отказ, молчание согласием не считается.
Мне как читателю не хватило раздела про поведение при обрыве связи. Агент при таймауте не «проверит глазами» (несмотря на то, что коллега с франзуским акцентом любит всё проверять глазами и править руками), а повторит вызов - для деструктивных операций это второй restart core. У нас на этом месте детерминированный ключ операции (повтор возвращает прежний результат) и честный исход «неизвестно» вместо угадывания.
И раз уж вы довели конвейер до OIDC с provenance - проверил из любопытства - у marzban-sdk и marzban-mcp аттестации на месте, npm audit signatures проходит. Для пакета, который ставят одной командой рядом с продовым токеном, это заметная часть доверия, и большинство MCP-серверов в реестре этим до сих пор пренебрегает.
Если интересно сравнить решения на смежном домене - деньги вместо инфраструктуры, - мы недавно разложили те же грабли по полочкам: механика подтверждений и идемпотентности (https://www.invoicebox.ru/ru/blog/mcp-server-money) и границы доверия с расходом контекста (https://www.invoicebox.ru/ru/blog/mcp-server-trust). Совпадений с вашим списком неприлично много - хорошая новость для всех, кто такое строит.