Это третья часть серии про MCP-сервер Инвойсбокс — интерфейс, через который ИИ-ассистент выставляет счета и возвращает деньги. В первой части — механика денег, во второй — границы доверия и проверка. Здесь речь о том, что происходит с сервером после того, как код написан: как его публикуют, чем читатель убеждается, что внутри лежит показанный ему код, и как ту же задачу решают карточные схемы, банки и российские сервисы.Начать стоит с истории, которая объясняет, зачем вокруг публикации столько формальностей.Пакет
postmark-mcp в реестре npm выглядел безупречно. Он копировал известную библиотеку и набирал доверие честными выпусками — пятнадцать версий подряд ничего лишнего не делали. В шестнадцатой появилась одна строка: скрытая копия всех отправленных писем уходила на адрес постороннего человека. Полторы тысячи установок в неделю, и утечка шла восемь дней, пока её не поймал поведенческий анализ.Теперь представьте на месте писем счета и платёжные реквизиты.Человек, который ставит ваш MCP-сервер, вас не знает. Он видит имя пакета, описание и номер версии. Всё остальное ему приходится принимать на веру — или проверять машиной, если вы дали ему чем.Начнём с денег, которые уже проходят через агентный канал, а закончим тремя свойствами, к которым пришли все, кто решает эту задачу всерьёз. Между ними — проверяемая публикация и приёмы других команд.Коротко, на двадцать секунд.- к 2028–2029 годам на агентные сценарии может приходиться 2–4 % онлайн-продаж;
- происхождение пакета доказывает провенанс сборки, и задним числом он не оформляется;
- имя в реестре MCP закрепляется пространством имён с подтверждением через DNS;
- Visa, Mastercard, Stripe и Google пришли к одному набору механик — они разобраны ниже;
- в России операции агентам уже открыли Сбер, Т-Инвестиции, Альфа-Банк и Robokassa;
- критикам протокола отвечаем отдельным разделом, включая тезис про 72 % окна.
О чём третья часть
1
Агентные покупки: насколько это уже рынок
2
Публикация: провенанс, реестр и совместимость
3
Приёмы, которые стоит забрать
4
Мир вокруг: как крупные игроки решают ту же задачу
5
Разговор со скептиками
6
Восемь правил, которые дешевле принять до первого выпуска
7
Это только первая версия
8
Чего хотелось бы от отрасли
9
С чего начать самому
Агентные покупки: насколько это уже рынок
Вся инженерная механика из первых двух частей имеет смысл при одном условии: если покупки и платежи, которые человек поручает ассистенту, становятся каналом продаж — таким же, как сайт и приложение. Этот раздел — про то, насколько канал уже большой и обо что он спотыкается.Канал уже считают в деньгах
Исследование Data Insight при поддержке Яндекса даёт вилку на годы вперёд. Сейчас, в 2026–2027 годах, на агентные сценарии — покупки, которые по поручению человека совершает программа-ассистент, — приходится 0,4–1 % онлайн-продаж, то есть 65–160 млрд рублей. К 2028–2029 годам это 2–4 % и 400–850 млрд, к 2030–2032 годам — 7–11 % и 2–3 трлн.Одна оговорка, без которой числа читаются неправильно. Считают розничный eCommerce, покупки физических лиц. Расчёты между компаниями в эту вилку не входят, отдельной оценки агентного B2B на российском рынке сегодня нет, и мы берём эти числа как показатель скорости, с которой люди привыкают поручать покупку программе, а не как размер своего рынка.Мировые оценки выше российских: к 2030 году агентная коммерция может дать 10–15 % мирового оборота eCommerce, у McKinsey это 3–5 трлн долларов. Strategy&/PwC называет для Европы 8–15 % (около 109 млрд евро), Morgan Stanley для США — 10–20 % (190–385 млрд долларов).Прогноз Data Insight при поддержке Яндекса: доля агентных сценариев в розничных онлайн-продажах — 0,4–1 % сейчас (65–160 млрд ₽), 2–4 % к 2028–2029 годам (400–850 млрд ₽), 7–11 % к 2030–2032 (2–3 трлн ₽).
Даже нижняя граница вилки означает канал сбыта, который придётся обслуживать так же всерьёз, как сайт и мобильное приложение: с документацией, поддержкой, разбором инцидентов. Верхняя означает, что продавец, у которого такого интерфейса нет, просто не попадёт в ответ ассистента, и покупатель об этом даже не узнает.
И это происходит сейчас
Прогноз даёт Data Insight, а текущие числа приводит сам Яндекс, и их стоит разделять. Переходы из чата Алисы AI в интернет-магазины выросли в 4,6 раза с начала года. Около 11 млн человек в неделю спрашивают Алису о товарах, 12 % запросов в чате касаются покупок. Продавцы, подключённые к транзакционной инфраструктуре Яндекса, — это 17 % российского e-commerce (это доля подключённых продавцов; доступная агенту доля рынка считается иначе). Подробности — в публикации Inc. Russia.К Yandex Commerce Protocol — протоколу, по которому магазин отдаёт заказ прямо в диалог, — подключено больше шести тысяч бизнесов, а тестировать подключение начали в феврале 2026 года.Что канал работает на живом спросе, показал июнь. Яндекс продавал новые наушники «Дропс» неделю эксклюзивно в чате с Алисой AI: с 9 по 15 июня заказать их можно было только там, и весь путь — от вопроса про возможности до оплаты — проходил в переписке. Первые пять тысяч разобрали за часы, всего оформили больше пятнадцати тысяч заказов на сумму свыше 135 млн рублей.× 4,6
выросли переходы из чата Алисы AI в интернет-магазины с начала года
11 млн
человек в неделю спрашивают Алису о товарах
12 %
запросов в чате касаются покупок
17 %
российского e-commerce — продавцы, подключённые к транзакционной инфраструктуре Яндекса
Между «спросил про товар» и «разрешил оплатить» лежит пропасть, и именно она интересна тому, кто занимается деньгами. Насколько она широка, видно по кейсам самого исследования: из тридцати восьми разобранных историй ИИ участвовал в выборе во всех, до корзины или оформления дошли тринадцать, а оплатой через ассистента закончились две.
Барьер — доверие, и он растёт вместе с суммой
Главным барьером исследование называет недостаток доверия: люди опасаются поручать алгоритму самостоятельные покупки, особенно на крупные суммы. Это ровно та зона, где живёт денежное API — счета, платежи, расчёты между компаниями, где ошибка стоит не испорченного вечера, а реальных средств и разговора с контрагентом.У этого барьера есть измеренная цена. Отвечая, какую сумму они готовы доверить ассистенту без своего участия, респонденты чаще всего называли пять тысяч рублей — «допустимую потерю». Прямой доступ к основной карте не готов дать почти никто: речь идёт про виртуальные карты с лимитом и обязательный экран подтверждения даже на мелких суммах. У нас порог, выше которого сумму называет человек, стоит на ста тысячах, и сравнивать их напрямую нельзя — там своя карта, здесь деньги компании. Общее у двух чисел одно: граница проведена, и проведена по сумме.Доверие здесь складывается не из уговоров и не из качества формулировок ассистента, а из свойств самого интерфейса. Идемпотентность — чтобы сбой связи не превратился в двойной платёж. Ограниченные права доступа — чтобы ассистент мог ровно то, что ему разрешили, и ни шагом больше. Прослеживаемый след операций — чтобы на вопрос «кто это сделал и по какому поручению» был ответ. Явное подтверждение человеком там, где сумма этого стоит — чтобы решение оставалось за человеком, а на машину приходилась подготовка.Со стороны продавца исследование называет главным ограничением не интеллект моделей, а готовность данных и внутренних интеграций: агенту нужен доступ к каталогу, ценам, остаткам, персональным условиям, доставке, оплате и статусу заказа, и всё это должно лежать в одном контуре с интерфейсами для агента. MCP-сервер закрывает одну клетку этой таблицы — расчёты — и не закрывает остальные.Без этого каждая ошибка обходится дважды: сначала деньгами, потом отказом пользоваться каналом. Один списанный второй раз платёж закрывает тему агентных сценариев для конкретной компании на годы — и никакой рост рынка её обратно не вернёт.Чего ждёт рынок
Ожидания рынка в исследовании расходятся, и расходятся именами. IT-директор «Золотого Яблока» Павел Бондарев говорит, что вход для генеративных систем в экосистему компании придётся сделать: доля такого трафика растёт. Директор по электронной коммерции Restore Андрей Васильев главным риском называет неучастие. Заместитель гендиректора «Бетховена» Вячеслав Уваров отвечает, что до появления кейсов с доказанной экономикой канал останется экспериментом.Числом эти ожидания выражаются так: доля агентного канала в выручке брендов, по оценке экспертов, дойдёт до уровня нынешнего органического трафика — 20–30 %. Внутренний ИИ-агент на площадке сначала станет конкурентным преимуществом, потом обычным делом. Измерений за этими ожиданиями нет, и относиться к ним стоит соответственно — но планировать инженерную работу приходится сейчас, пока числа ещё не устоялись.Поэтому вопрос для денежного API звучит не как «встраиваться ли в ассистентов», а как «какими свойствами должен обладать интерфейс, чтобы человеку было спокойно доверить ему сумму со многими нулями». Ответов на него три: наш собственный, чужой опыт инженерных команд и то, к чему пришли платёжные схемы и крупные платформы.Публикация: провенанс, реестр и совместимость
Как сервер попадает на чужую машину и что про него можно проверить машинно, не веря нам на слово? Инженеру дальше интересен порядок выпуска и набор проверок, остальным — ответ на один простой вопрос: чем подтверждается, что установленный пакет собран из того кода, который показывают.Перед установкой всё знание о нас сводится к трём вещам: архив пакета, страница в реестре и подписи, которые проверяются программой. Дальше пакет запускается на машине пользователя с его правами: официальные рекомендации MCP приравнивают локальный сервер к исполнению произвольного кода и требуют от клиента показать точную команду запуска и получить явное согласие человека (источник). Подменённый по дороге пакет обходит любую защиту, написанную внутри кода, поэтому публикация входит в контур безопасности наравне с двухфазным подтверждением денежных операций.Провенанс: подпись, которую надо получить с первого выпуска
Провенанс сборки: машинная запись о том, из какого репозитория и коммита собран пакет. Единственный проверяемый ответ на вопрос «точно ли внутри тот код, который показывают».
Публиковать платёжный пакет без провенанса мы не советуем никому, и причина не в моде на подписи.Провенанс — машинная запись о происхождении сборки: реестр фиксирует, из какого репозитория и какого коммита собран архив, потому что сборочная среда в момент публикации предъявляет одноразовый токен собственной личности (документация npm). Для пакета, который выставляет счета, это единственный машинно проверяемый ответ на вопрос «точно ли внутри тот код, который вы показываете». Всё остальное (README, страница в реестре, наши заверения) читателю приходится принимать на веру.Планировать провенанс приходится заранее: задним числом он не оформляется. Сборки, которая могла бы его подписать, к тому моменту уже не существует, и версия остаётся такой, о происхождении которой можно только рассказать словами. Наша первая версия вышла именно так — с рабочей машины, до того как выпуск переехал в сборочную среду; проверить её происхождение машинно нельзя и уже не будет можно.Публикация с провенансом работает только из сборочной среды публичного репозитория у поддерживаемых провайдеров, поэтому порядок такой: открыть репозиторий с исходниками (у нас для этого сделано публичное зеркало под лицензией MIT), перенести выпуск в сборочный конвейер и публиковать оттуда с флагом провенанса; ручная публикация такой записи не оставляет. Результат проверяют так, как его проверит читатель:
npm audit signatures в чистой установке. По шкале SLSA такая подпись отвечает за то, что архив не трогали после сборки (уровни SLSA).Рядом живёт вторая подпись, которую с провенансом легко перепутать: подпись самого реестра. Она покрывает имя, версию и хеш архива и защищает от враждебного зеркала или прокси (подписи реестра). Гарантии тут разные. Одна говорит «архив не подменили по дороге», другая — «архив собран вот из этого кода». Взрослому пакету нужны обе.Третьим приложите состав зависимостей — перечень всего, что приезжает вместе с пакетом, в одном из распространённых форматов. Собирать его нужно без инструментов разработки: описанное дерево должно совпадать с тем, что установится у клиента, иначе документ рассказывает про вашу разработку вместо его установки.Проверяется всё это двумя командами: npm view <пакет> dist.attestations показывает наличие подтверждений, а npm audit signatures проверяет их для установленных зависимостей. Требования к выпуску простые: свежий npm, публичный адрес репозитория в манифесте и сборка на облачном раннере поддерживаемого сервиса.Метаданные пакета: что стоит проверить до публикации
Метаданные складываются из полей манифеста и файлов рядом с ним, которые читатель видит раньше кода.Лицензия выбрана и лежит файлом, а полеlicense ей соответствует. Значение UNLICENSED без файла формально запрещает использование: юрист заказчика на этом остановится, а разработчик даже не дойдёт до установки. Мы выбрали MIT с двумя оговорками, которые стоит проговаривать явно: товарные знаки лицензия не передаёт, а доступ к API регулирует договор.Адрес репозитория ведёт на доступную страницу. Публичный пакет со ссылкой, отвечающей 404, читается как заброшенный, и проверить происхождение кода по нему нельзя.Версия в примерах установки совпадает с опубликованной. Инструкция по установке — исполняемый код: человек несовпадение заметит, а агент выполнит буквально и поставит прошлую версию вместе с прошлым поведением денежных инструментов. Сверка живёт в сборке: пусть падает, если пример в README расходится с манифестом, и пусть опубликованная версия сверяется с той, что лежит в реестре пакетов.В примерах конфигурации версия указана явно. Для платёжного инструмента latest означает, что набор инструментов может измениться между двумя запусками одного диалога — с последствиями в деньгах.Что проверять в артефакте перед публикацией
Между «код правильный» и «клиенту уехало то, что задумано» лежит отдельная проверка, о которой вспоминают обычно после первой неприятности. Проверять надо состав того, что реально попадает в архив пакета; состояние рабочей папки об этом не говорит.Искать надо четыре вещи. Пути и имена с машины разработчика, следы рабочего процесса и черновики, ссылки на документы, которых у читателя нет, и пометкиTODO без номера задачи. Каждая из них безобидна внутри и работает против вас снаружи: человек, решающий, доверить ли вам выпуск счетов, читает пакет как характеристику команды.Мы рекомендуем список разрешённого вместо списка запрещённого. При списке запретов новый внутренний файл уезжает наружу от обычной забывчивости автора; при списке разрешений он просто не попадает в сборку, и ошибка получается в безопасную сторону. Проверять надо собранный архив (для npm это npm pack и осмотр получившегося тарбола), потому что именно он уедет в реестр.И последнее правило, самое дешёвое из всех. Момент отправки наружу оставляйте действием человека.Если разработка идёт в закрытом репозитории, наружу выкладывают зеркало, и собирать его стоит по тому же принципу: копируется только то, что в списке разрешённого. Обратная схема («копируем всё, кроме перечисленного») рано или поздно вывезет наружу новый внутренний документ, про который забыли написать исключение.Зачем нужен реестр и как закрепить в нём своё имя
Реестр MCP работает как каталог серверов. Клиент (Claude Desktop, Cursor, редактор кода) обращается к нему, показывает пользователю карточку сервера и предлагает установку. Роль та же, что у каталога приложений: одно место, где можно найти нужное и понять, откуда оно взялось.Вторая функция важнее первой.Имена инструментов внутри сервера префикса компании не несут: инструмент называетсяcreate_order, без префикса компании в имени. По одному имени пакета подделку не отличить — рядом с настоящим пакетом легко появляется похожий, с лишней буквой или другим владельцем. Запись в реестре под своим пространством имён (namespace, буквально «пространство имён» — префикс вида ru.invoicebox) закрывает этот зазор: пространство выдаётся тому, кто доказал права на домен, а запись внутри него связана с конкретным пакетом. Пользователь и агент видят не просто «какой-то пакет с подходящим названием», а запись, за которую отвечает владелец домена.Официальный реестр живёт по адресу registry.modelcontextprotocol.io, его код открыт — modelcontextprotocol/registry. Реестр в статусе предварительной версии, поэтому детали формата стоит сверять по документации перед каждым выпуском. Кроме официального есть сторонние каталоги — Smithery и mcp.so; они удобны для видимости, но доказательством принадлежности не служат.Имена инструментов сервер объявляет без префикса, так что чужой сервер вправе объявить собственный create_refund и предложить его тому же ассистенту. Отсюда потребность доказать, что сервер именно наш, а похожий на наш — чужой.Пространство имён подтверждается записью в DNS на самом домене: короткая строка с версией схемы, алгоритмом подписи и открытым ключом. Записей можно держать несколько, так делается ротация ключа. Закрытый ключ по значимости равен токену публикации и лежит в хранилище секретов: с ним чужой пакет может назваться нашим. Частая ошибка — повесить запись на подимя вроде _mcp-auth; реестр смотрит апекс домена, то есть сам домен без приставок, и запись на апексе покрывает все подпространства. Написание полей описания сервера менялось между ревизиями схемы (registryType против registry_name и подобное), поэтому запись, собранную без обращения к реестру, сверяют с его собственной заготовкой.Владение именем в npm подтверждается полем mcpName в манифесте, которое обязано совпадать с именем сервера в реестре (типы пакетов). Итого происхождение подтверждают три независимые сущности: пакет в npm, образ и запись в реестре. Отдельная проверка сверяет версию, имя, описание, адреса и переменные окружения в обе стороны, чтобы в записи не оказалось придуманных переменных, а нужные для запуска не потерялись.Как оформить запись: четыре шага
1
Пометить пакет полем mcpName
В package.json появляется имя будущей записи — у нас ru.invoicebox/mcp-server. Реестр проверяет уже опубликованный пакет.
2
Написать запись о сервере
server.json: имя в форме обратного домена, описание и версия как у пакета, ссылка на исходники, способ запуска, переменные окружения с пояснениями.
3
Подтвердить пространство имён записью в DNS
TXT-запись на апексе домена: v=MCPv1; k=ed25519; p=<открытый ключ>. Альтернатива — файл /.well-known/mcp-registry-auth.
4
Сверять запись с пакетом машинной проверкой
Версия, имя, описание, ссылки, mcpName и переменные окружения сравниваются при сборке в обе стороны.
Запись в реестре MCP собирается в четыре шага — пометить пакет, описать сервер, подтвердить право на имя и свести запись с пакетом машинной проверкой.
Шаг 1. Пометить пакет полем mcpName
В манифесте пакета (package.json) появляется поле mcpName со значением будущего имени в реестре — у нас ru.invoicebox/mcp-server. Это метка владения. Реестр читает опубликованный пакет и убеждается, что тот, кто заводит запись, управляет пакетом. Без метки запись отклоняется, и это хорошо: иначе любой желающий описал бы чужой пакет как свой.Порядок действий обычный — поставить mcpName, собрать, опубликовать пакет, и только потом заводить запись в реестре. Реестр проверяет уже опубликованное.Шаг 2. Написать запись о сервере
Запись живёт в файлеserver.json. Заготовку делает утилита mcp-publisher командой init, дальше файл правится руками. В нём:- имя в форме обратного домена:
ru.invoicebox/mcp-server; - описание и версия — те же, что у пакета;
- ссылка на публичный репозиторий с исходниками;
- способ запуска: пакет из npm, запуск через
npx; - переменные окружения с пояснениями — что это, обязательна ли, где взять значение.
mcp-publisher validate — она проверяет файл по схеме, ничего не публикуя. Пошаговый порядок описан в документации по публикации.Шаг 3. Подтвердить пространство имён записью в DNS
Права на пространствоru.invoicebox подтверждаются тем, что вы управляете доменом. Механика: вы генерируете пару ключей, публикуете открытый ключ TXT-записью в DNS, а утилита публикации подписывает вход закрытым ключом. Реестр читает запись, проверяет подпись и выдаёт пространство.Значение записи выглядит так: v=MCPv1; k=ed25519; p=<открытый ключ в base64>. Допустимы два алгоритма подписи — ed25519 и ecdsap384. Порядок полей важен, пробелы после точек с запятой допустимы.Здесь легко потерять полдня, поэтому три практических замечания. Запись ставится на апекс — сам домен (invoicebox.ru), без поддомена. Заводить _mcp-auth или похожее подимя не нужно и вредно: реестр ищет запись на самом домене, не находит и честно подсказывает об ошибке, а лишняя запись остаётся висеть. Запись на апексе покрывает подпространства, то есть все имена внутри ru.invoicebox, — второй раз доказывать домен для второго сервера не придётся. Ключей можно держать несколько — так его меняют, не теряя доступ: новый добавили, выпустили, старый убрали.Для тех, у кого нет доступа к DNS, есть альтернатива: файл /.well-known/mcp-registry-auth на сайте домена с тем же значением. Выбор между DNS и файлом — вопрос того, к чему у вас быстрее доступ.Шаг 4. Сверять запись с пакетом машинной проверкой
Запись и пакет описывают одно и то же и расходятся при первой же спешке: версию подняли в пакете и забыли в записи, переменную переименовали в коде и не поправили в описании. Читатель получает инструкцию, которая не работает, и делает единственный доступный вывод — сервер заброшен.Поэтому сверка автоматизирована и выполняется при сборке. Сравниваются версия, имя, описание, ссылки,mcpName и переменные окружения — причём в обе стороны: в записи нет придуманных переменных, которых код не читает, и не забыты те, без которых сервер не поднимется. Версию в запись подставляет скрипт выпуска сразу после подъёма номера, так что руками её никто не переписывает.Про общий демо-контур
Если в документации есть демо-доступ, скажите прямо: магазин общий, и пробные операции видны всем, кто взял те же параметры из инструкции. Читатель, который узнал об этом сам, чувствует себя обманутым; читатель, которого предупредили, просто не станет заводить в демо реальные данные.Совместимость с живыми клиентами
Стандарт описывает, как должно быть; клиенты в природе спрашивают то, что спрашивают. Расхождение приходится закрывать на своей стороне, иначе подключение ломается у пользователя без объяснимой причины.Метаданные защищённого ресурса лежат на служебной странице, которая отвечает клиенту, где брать токен доступа и какие права просить. Мы отдаём её по двум адресам сразу: по короткому и по адресу с путём ресурса. Стандарт OAuth 2.0 требует второй (RFC 9728), живые клиенты спрашивают первый. Способ передачи токена ограничен заголовком: в строке запроса токен осел бы в логах промежуточных прокси, в теле — ломал бы потоковый ответ.Метаданные публикуются только тогда, когда проверка токенов на сервере включена. Пока проверки нет, эти адреса отвечают 404 с перечислением недостающих настроек: сухой отказ «адреса не существует» отправил бы человека искать ошибку в своём клиенте. Обещание «идите за токеном сюда» без проверки токена хуже молчания — клиент получит токен и откажется на каждом вызове. Поэтому размещённый демо-сервер отвечал на проверку живости и молчал про авторизацию.Клиентам без поддержки MCP тот же каталог инструментов отдаётся плоской схемой функций: строки, числа, логические значения, перечисления и массивы объектов, вложенность не глубже двух уровней, без условных конструкций. Двухфазность подтверждения при этом дописывается прямо в текст описания инструмента: аннотации — машинные пометки о характере инструмента — такие клиенты не читают, да и спецификация сама называет их подсказками и запрещает принимать по ним решения о доверии (раздел Tools). Строгость по схеме объясняется неприятным наблюдением: часть провайдеров молча отбрасывает поле вместе с непонятной ей конструкцией. Для денежного инструмента потеря поля обходится дороже честного отказа — пропавший токен подтверждения превращает подтверждение в формальность.Приёмы, которые стоит забрать
Глава практическая, для тех, кто делает свой MCP-сервер. Здесь собраны приёмы из инженерных публикаций 2025–2026 годов, каждый одной формулировкой «что делать», с причиной и ссылкой. Часть из них мы уже держим, часть забрали бы себе — это помечено по ходу.Инструменты и описания
Начинать проектирование стоит со списка задач агента, а каждый инструмент делать завершённым шагом работы. Anthropic формулирует это прямо: несколько продуманных инструментов под ценные сценарии вместо обёртки на каждый адрес метода,schedule_event целиком вместо связки из трёх вызовов (Anthropic). Причина экономическая: каждая развилка — место, где модель ошибётся, а на живых серверах успех даже сильных моделей не дотягивает до половины задач (MCP-Universe: GPT-5 в режиме Medium — 43,72 %, лучший результат у GPT-5 High — 44,16 %, Claude-4.0-Sonnet — 29,44 %).Что показывают замеры: на живых серверах успех даже сильных моделей не дотягивает до половины задач (MCP-Universe), а атака через описание инструмента у слабых моделей срабатывает в 72,8 % случаев (MCPTox).
Занять префикс имён и считать имена публичным контрактом. Пространство имён по сервису и ресурсу спасает от коллизий, когда клиент подключил пять серверов (Anthropic), а переименование параметра
question в query в Microsoft Learn сломало 2–5% запросов, пока не стали принимать оба имени: часть клиентов зашивает схему жёстко, и динамическое обнаружение от этого не спасает (Microsoft).Прятать внутренние ручки за разумными значениями по умолчанию. Microsoft Learn сознательно оставил три инструмента, спрятав от агента выбор индекса, пороги и фильтры, и построил пары «найди — прочитай», прописав связку прямо в описании; попутно выяснилось, что мелкие правки формулировок материально меняют частоту вызова, поэтому частоту начали мерить.Держать описания как промпты, а сообщения об ошибках — с примером верного вызова. Точная правка описаний однажды вывела Claude Sonnet 3.5 на лучший результат в SWE-bench Verified на тот момент, а подсказка в тексте ошибки дешевле лишнего круга рассуждений (Anthropic). Мы это применяем и считаем самой дешёвой из всех оптимизаций.Если инструментов больше нескольких десятков — переходить к схеме «мало глаголов плюс реестр ресурсов на сервере». Harness сжал 130+ инструментов до 11 глаголов с реестром на 125+ типов ресурсов: доля контекста упала с 26% до 1,6%, попутно решилась проблема лимита в 80 инструментов у Cursor (Harness). Маршрутизация должна жить в коде сервера. Взяли бы себе на вырост — сейчас инструментов у нас мало.Экономия контекста
Измерить стоимость своего сервера в токенах до первого пользовательского сообщения.Это конкретное число, которое можно замерить. Стек из трёх популярных серверов занимал 55 000 токенов определений, в другой конфигурации — 143 000, то есть 72 % окна; а одна и та же операция стоила 1 365 токенов через CLI и 44 026 через MCP — по их замерам разрыв составляет от 4 до 32 раз (Roadie). Мы этот замер держим как приёмочный.Ни один инструмент не должен возвращать неограниченный список. Пагинация, диапазон, фильтр и усечение с разумными значениями по умолчанию; параметрresponse_format с вариантами concise и detailed в примере Anthropic давал 72 токена против 206, а текст усечения должен подсказывать, как сузить запрос (Anthropic). Три уровня детализации работают лучше одного «полного» ответа (Roadie).Дать интеграторам три рычага. Группировку по наборам, флаг «только чтение» и точечный список инструментов. У официального сервера GitHub это наборы, режим динамических наборов со стартом всего с четырёх инструментов, суффикс /readonly в URL и заголовок X-MCP-Tools; мотив назван прямо — слишком много инструментов путают модель (GitHub). Это первое, что мы возьмём себе: рычаги отдают управление контекстом клиенту без форка сервера.Отложенную загрузку и программный вызов включать по замеру. Инструмент поиска по инструментам занимает наверху около 500 токенов, программный вызов на бенчмарке из 75 инструментов дал минус 38% оплаченных входных токенов, и там же честно названы случаи, где выгоды нет — строго последовательные цепочки и пара мелких вызовов на первом ходу (платформа Claude). Крайний вариант — раскладка инструментов в дерево файлов с исполнением кода, где 150 000 токенов сжались до 2 000; цена честно названа, это песочница с лимитами и мониторингом (Anthropic).Оценка качества вызовов
Завести набор из нескольких десятков многошаговых задач из реальной работы и мерить не один лишь результат. Anthropic описывает готовую методику: точность, время, число вызовов, суммарные токены и ошибки инструментов, проверка судьёй-моделью без чрезмерно строгих верификаторов и обязательный отложенный набор, на котором вы описания не правили. Число вызовов и токены здесь важнее процента успеха: именно они показывают, что инструменты плохо скомпонованы.Тестировать живыми формулировками. Разбор 28 серверов и 250 инструментов показал, что провалы концентрируются в подборе инструмента по размытому запросу без его имени, в планировании длинных цепочек и в опоре на промежуточные результаты (MCP-Bench). Значит, спрашивать надо «почему упал платёж» — теми словами, которыми спросит живой человек.Транскрипты провалов пускать обратно в правку схем, причём пакетно по всему серверу — иначе описания разъезжаются между собой (Anthropic). Этот цикл мы заводим сейчас; до него правки описаний были интуитивными.Безопасность
Считать описание инструмента исполняемым артефактом и ревьюить при каждом изменении. В показанных примерах описание безобидного калькулятора уводило модель читать приватные файлы, а замеры по 45 живым серверам и 353 настоящим инструментам показывают, что у слабых моделей успех такой атаки доходит до 72,8 %, а отказываются агенты редко: у лучшего из двадцати проверенных доля отказов ниже 3 % (MCPTox; пример с калькулятором — разбор Саймона Уиллисона). Отсюда наше правило. Ничто пришедшее от пользователя или из внешнего источника не попадает в описания и результаты без разметки как данных.Пиннить версии серверов и хешировать определения инструментов. Одобрение инструмента не переживает изменений на сервере — это подтверждённый класс атаки с CVE-2025-54136 (CVSS 8.8): сервер одобрен, каждый вызов в пределах нормы, а поменявшееся описание разворачивает поведение агента, как подменённый системный промпт. Живой инцидент цепочки поставок туда же: пакетpostmark-mcp набрал доверие честными версиями и в 1.0.16 добавил одну строку скрытой копии всех писем на адрес атакующего, около 1 500 недельных установок (разбор Koi Security, Snyk).Публиковаться в проверенном пространстве имён и заранее занять похожие написания. В крупном каталоге бейдж официального сервера нашёлся у 8 % из 847 обследованных записей (UpGuard), а подставного двойника с похожим именем приняли 9 реестров из 11 (OX Security).Разводить приватные данные, недоверенные инструкции и канал утечки по разным серверам и сессиям. Рамка «смертельной троицы» полезна тем, что работает без надежды на стойкость модели, а убедительных средств защиты от внедрения инструкций так и нет (Саймон Уиллисон). И отдельная неприятная новость для всех, кто опирается на ручное подтверждение: расхождение между тем, что показано в диалоге одобрения, и тем, что достаётся модели, воспроизведено на трёх независимо написанных реализациях сервера.Приём — блок TAG в юникоде, у которого нет изображения ни в одном привычном интерфейсе: человек одобряет чистый текст, модель получает спрятанную нагрузку (arXiv 2607.05744). Вывод неприятный и важный. Диалог одобрения сам по себе ничего не контролирует. Поэтому подтверждение у нас держится не на том, что человек увидел красивую сводку, а на подписанном токене, привязанном к отпечатку параметров операции, и на отдельном поле с суммой, которую человек называет сам. Приём деньги от покупателя вообще проходит вне диалога — на платёжной странице банка-партнёра.
Диалог одобрения сам по себе ничего не контролирует. Подтверждение держится на подписанном токене, привязанном к отпечатку параметров операции, и на отдельном поле с суммой, которую человек называет сам.Пройти список Security Best Practices как приёмку. Самое пропускаемое там — проверка того, что токен выпущен именно для вашего сервера, и запрет подстановочных символов в
redirect_uri; самое полезное для аудита — логировать факты повышения области прав с идентификатором корреляции (спецификация).Эксплуатация
Вешать лимиты частоты и правила WAF на заголовкиMcp-Method и Mcp-Name. Новая редакция спецификации сделала протокол бессессионным и добавила эти заголовки, чтобы ограничители принимали решения без разбора произвольного JSON; там же — уход с динамической регистрации клиентов на метаданные клиента (удаление после лета 2027) и подсказки кеширования ttlMs и cacheScope для каталога инструментов (Cloudflare). Забрали бы целиком. Лимит в разрезе конкретного инструмента иначе не построить.Скопировать четвёрку предохранителей Harness. Это подтверждение на записи, отказ вместо тихого выполнения при удалении, если клиент подтверждение не поддерживает, глобальный режим «только чтение» и лимит частоты по умолчанию. Плюс два правила оттуда же, которые стоят дорого при нарушении: секреты отдаются только метаданными, а область прав вычисляется на сервере из токена и параметром от модели не приходит (Harness).Итого по нам. Уже применяем осторожную позицию с деньгами (агент не держит карту, подтверждает человек), идемпотентность создающих вызовов, описания как промпты и замер токенов до промпта. Взяли бы себе в первую очередь рычаги для интеграторов из практики GitHub, лимиты по заголовкам из новой редакции спецификации, набор предохранителей Harness и постоянный набор реальных задач с метриками по числу вызовов и токенам.Мир вокруг: как крупные игроки решают ту же задачу
Механика нашего сервера разобрана, чужие приёмы собраны — остался последний взгляд наружу: что с той же задачей за последние полтора года сделали те, у кого юристов и денег заметно больше. Картина складывается ровнее, чем можно ожидать по пресс-релизам: схемы, процессинги, эмитенты и разработчики моделей пришли к одному набору приёмов и расходятся скорее в том, на каком слое каждый приём живёт. Механик шесть; под каждой видно, кто что сделал, где наш подход совпадает с общим движением и где мы держимся иначе.Делегирование
Отдельное право на каждого агента: токен вместо карты, единица отзыва — агентПризнак агента
Подписанный запрос до всякой оплаты: «это живой известный агент», право тратить — отдельноСумма и срок
Узкое окно на один платёж: валюта, максимум, срок годности, один продавецПодтверждение человеком
Согласие сдвигается раньше по времени и уходит от чата к устройствуИдемпотентность
Повтор «заверши оплату» после таймаута не должен списать деньги второй разОтслеживаемость
След согласия решает, кто платит за ошибку агентаДелегирование: отдельное право на каждого агента
Первое, что все сделали одинаково, — перестали давать агенту карту. Visa 30 апреля 2025 года объявила Visa Intelligent Commerce, где настоящий номер карты заменяется токенизированным ключом (токенизация — выдача суррогатного представления карты вместо её номера), привязанным к конкретному агенту; смысл ключа в том, чтобы «подтвердить, что выбранный потребителем агент вправе действовать от его имени», а лимиты и условия задаёт человек (пресс-релиз Visa).Днём раньше Mastercard показала Agent Pay с Mastercard Agentic Tokens — надстройкой над действующей токенизацией, где токен связан с одним названным агентом, одной политикой согласия и набором разрешённых продавцов. По материалам Mastercard эта политика проверяется при авторизации операции; формулировка про проверку именно на стороне платёжной сети в самом релизе не закреплена, поэтому полагаться на неё как на гарантию не стоит (обзор Mastercard). American Express в апреле 2026 добавила к тому же регистрацию агента с выдачей идентификатора (ACE Developer Kit).Единицей отзыва при этом становится агент. Скомпрометирован один помощник — гасится один токен, карта остаётся жить. У Mastercard это доведено до конца: лимиты переносятся внутрь самого платёжного ключа и проверяются сетью, поэтому обойти их не может даже взломанный агент.Инвойсбокс совпадает здесь в главном: агент не держит данные карты и не становится получателем платежа, он доводит дело до счёта, а деньги вносит человек на странице оплаты. Расходимся мы в единице делегирования — права агента у нас пока совпадают с правами ключа доступа, отдельного «токена под агента» нет. Такие токены выпускаются внутри программ схем, куда входят по регистрации, и готовность кода здесь ничего не решает.Признак агента: подписанный запрос до всякой оплаты
Второй слой отвечает на вопрос продавца «кто ко мне пришёл».Visa вместе с Cloudflare в октябре 2025 года выпустила Trusted Agent Protocol, где агент предъявляет подписанное намерение, признание покупателя и, по желанию, платёжные данные — поверх обычного HTTPS, с минимальными правками страницы оплаты (анонс). Механика в спецификации предельно приземлённая: пара ключей регистрируется в директории Visa, каждый запрос подписывается подписями HTTP-сообщений (RFC 9421), для просмотра берётся Ed25519, для платёжных объектов PS256, публичные ключи продавец забирает по адресу справочника ключей (JWKS), а подпись привязана к конкретному хосту и конкретной странице (спецификация).Самое полезное в этой спецификации — то, чего в ней нет: ни поля для лимита, ни постоянного мандата, ни флага согласия человека. Подпись говорит только «это живой известный агент», а право тратить приходит откуда-то ещё. Плюс подписи мало и по факту: в декабрьском отчёте Visa решение о пропуске принимает связка подписи и поведенческой оценки на границе сети от Akamai, то есть корректно подписанный агент, который ведёт себя как парсер, всё равно упрётся в блокировку (отчёт).У нас этот слой закрыт тем же ключом доступа, что и любая другая интеграция: подписей HTTP-сообщений (RFC 9421) сервер не требует. Технически совместимость с таким протоколом стоит недорого, но упирается в справочник ключей: у Visa он свой, и к российскому рынку отношения не имеет. Аналога от НСПК — места, где продавец мог бы проверить подпись агента так же, как проверяет платёж, — сегодня нет. Пока его не появится, личность агента остаётся вопросом двусторонних договорённостей.Сумма и срок: узкое окно на один платёж
Третью механику копируют чаще прочих, потому что она полностью описана в открытых документах. Stripe в рамках Agentic Commerce Protocol выпустила Shared Payment Tokens: агент получает токен, ограниченный по валюте, максимальной сумме, сроку годности и названному продавцу, отзываемый в любой момент и одноразовый по смыслу (документация).В самой спецификации ACP это описано как объект Allowance с полямиreason=one_time, max_amount, currency, checkout_session_id, merchant_id и expires_at (спецификация). Stripe вместе с Tempo добавила к этому вариант для машинного потребления — сессии Machine Payments Protocol (март 2026 года) с заранее согласованным потолком и потоком мелких списаний внутри него; протокол обратно совместим со схемой x402, которая появилась раньше и распространена шире (анонс).Работает это потому, что узкое окно делает ошибку агента конечной по цене: срок годности в минутах и привязка к одному продавцу превращают утечку токена в мелкую неприятность. Инвойсбокс приходит к тому же через саму сущность счёта — он выставлен на конкретную сумму конкретному плательщику и имеет срок. Разрешения вида «трать до N рублей в месяц» у нас пока нет для агента — хотя сама механика лимитов в платформе давно работает для людей: сотруднику можно выдать права с ограничением, и бухгалтерия этим пользуется каждый день. Перенести её на агента — вопрос не изобретения, а времени, и эта задача стоит в плане.Подтверждение человеком: согласие сдвигается раньше по времени
Здесь произошёл заметный сдвиг.Google с шестью десятками партнёров выпустил Agent Payments Protocol, где покупка представлена подписанными мандатами — объектами с проверяемым авторством, технически это подписанные токены формата SD-JWT: человек подписывает рамку с ограничениями заранее, агент позже привязывает её к конкретной итоговой сумме, и оба артефакта проверяемы после факта (AP2). Состав мандатов при этом менялся: первоначальный анонс описывает три мандата — Intent, Cart и Payment (Google Cloud), текущая редакция (версия 0.2.0 от 28 апреля 2026 года) сведена к Checkout и Payment: слой согласия ещё движется.Момент подтверждения индустрия при этом уводит от чата к устройству. В демонстрации Visa человек подтверждает привязку через FIDO и платёжный ключ доступа passkey (visa/mcp); Stripe вводит явное состояние токенаrequires_action, при котором агент обязан показать интерфейс банка; у Affirm прямо записано, что по заявке на рассрочку нажимает покупатель. Стандартизация ушла в FIDO Alliance: две рабочие группы, платёжную возглавили Mastercard и Visa, в основу положены AP2 и Verifiable Intent, сроков не объявлено (FIDO).Наш подход к подтверждению совпадает с общим направлением в самой простой форме: агент доводит до счёта, а согласие даёт плательщик на странице оплаты своими средствами. Расходимся мы в том, что подписанного артефакта согласия, который можно предъявить в споре, у нас пока нет.Идемпотентность: повтор не должен списывать дважды
Эта механика выглядит скучной, пока не посмотришь, кто её сделал обязательной.В ACP на каждом вызове обязательны подпись запроса и метка времени, а ключ идемпотентности стандарт настойчиво рекомендует (в терминах спецификации — SHOULD) (спецификация). Агент, повторяющий «заверши оплату» после таймаута, не должен списать деньги второй раз. Stripe требует ключ идемпотентности на создающих вызовах своего MCP-сервера и отдаёт асинхронные исходы вебхуками (документация); у Adyen в описании MCP-сервера такого указания нет вовсе — оно отложено на нижележащие API (документация).Цену пропуска показала академическая работа: разбор протоколов агентной коммерции нашёл 33 уязвимости, и среди них — неатомарное состояние платежа с гонкой проверки и использования (TOCTOU) в AP2 версии 0.2.0, дающее двойную трату; три находки получили советы по безопасности на GitHub (arXiv 2607.21824). Важнее всего вывод этой работы для любого, кто строит такой сервер: структурные дефекты — неподписанные ответы, токены без области прав, неатомарное состояние — срабатывают в 100% попыток независимо от того, какая модель за рулём, а подверженность подсказкам в описаниях зависела от модели. Идемпотентность — тот пункт списка, который нельзя отдать ни хосту, ни модели, и здесь мы просто повторяем индустрию.Отслеживаемость: след согласия решает, кто платит за ошибку
Последняя механика превращает журналы в доказательство. Mastercard и Google в марте 2026 года выпустили Verifiable Intent — рамку, которая создаёт «устойчивый к подделке журнал, связывающий личность, намерение и действие в одну запись», доступный покупателю, продавцу и эмитенту, с избирательным раскрытием, чтобы проверка одной покупки не открывала всю историю (Mastercard).Коммерческий смысл этого лучше всего видно у American Express: покрытие ошибок агента действует при трёх условиях — агент зарегистрирован, подтверждённое намерение покупателя передано, и ошибка именно агентская (анонс; детали состава кита разошлись по торговой прессе, сама страница новостей отдаёт только заголовок). Visa со своей стороны обусловливает контроль и права в спорах тем, что сигналы о действиях агента приходят в сеть в реальном времени.Попутно снимем частое недоразумение. Когда в релизах поминают W3C, речь обычно идёт о модели верифицируемых удостоверений, на которую опираются мандаты, — платёжный стандарт W3C здесь не участвует. Платёжная работа в консорциуме при этом идёт своим чередом: рабочая группа Web Payments действует, её мандат продлён до 31 июля 2027 года, Payment Request API в июне 2026 года получил очередную редакцию кандидата в рекомендации, а агентные платежи стоят в повестке ближайшей конференции консорциума (W3C). EMVCo в ноябре 2025 года заявила работу над поддержкой агентных платежей в 3-D Secure, токенизации и Secure Remote Commerce, сроков не опубликовав (EMVCo).Сколько всего этого уже работает
Масштаб отрезвляет.В декабре 2025 года Visa отчиталась о «сотнях» агентных транзакций при 100+ вовлечённых партнёрах, то есть протокольная готовность бежит впереди реального оборота (Visa). OpenAI запустила покупку внутри чата 29 сентября 2025 года, а в марте 2026 года свернула её и увела оформление на сторону магазинов: конверсия оформления в чате у Walmart оказалась примерно втрое ниже передачи покупателя на сайт, живыми успели стать около десятка магазинов Shopify (American Banker).Ни один протокол не выиграл: сама Visa в апреле 2026 года открыла шлюз, принимающий четыре протокола сразу (анонс), а готовность эмитентов идёт отдельным, более медленным темпом — программа Agentic Ready до сих пор подключает банки рынок за рынком (Visa). Отсюда и наш выбор. Агент доводит до счёта, а оплату принимает Инвойсбокс, поэтому смена протокола-победителя нас не переписывает.Российский контур: кто уже открыл свои операции агентам
Сбербанк
Операции СберБизнеса через MCP: рублёвый платёж и выписка; площадка GigaNetwork для агентов компанийАльфа-Банк
MCP-серверы для внешних интеграций; первым шагом — справочные данныеТ-Инвестиции
Публичный MCP-сервер к брокерскому счёту: котировки, баланс, заявки; три уровня прав токенаБитрикс24
MCP-сервер отдаёт агенту документацию REST API, чтобы модель не выдумывала методыЯндекс
MCP Hub в AI Studio, Yandex Commerce Protocol, платформа агентов в Алисе AIRobokassa
MCP-сервер агрегатора: 17 инструментов, тестовый режим по умолчанию, перевод в боевой — рукамиВсё описанное выше — программы международных схем, вход в которые идёт через регистрацию в директории и подключение банков-эмитентов по рынкам; подтверждённых данных о том, как это устроено для России, у нас нет. Зато в России 2026 год оказался годом, когда MCP перестал быть темой для конференций, и здесь первоисточники есть.Сбербанк в июне 2026 года открыл клиентам СберБизнеса банковские операции через MCP-серверы: агент компании создаёт рублёвый платёж и получает банковскую выписку, набор операций обещают расширять. В том же сообщении решение названо единственным на тот момент MCP-сервером для корпоративного сегмента на российском рынке (CNews).Одновременно Сбер показал GigaNetwork — площадку, где агенты компаний сами находят контрагентов, проводят тендеры и договариваются об условиях, со встроенными эскроу-счетами, банковскими гарантиями и фиксацией ключевых событий в блокчейне; названы пилоты с ФосАгро, Аэрофлотом и другими компаниями (CNews). Со стороны клиента у Сбера описана и обратная задача — как агент на GigaChat подключается к чужому MCP-серверу (документация для разработчиков), а для сценария умных покупок опубликована инструкция по MCP-интеграции (документация).Альфа-Банк в мае 2026 года объявил о готовых MCP-серверах для внешних интеграций и назвал себя первым банком с таким решением. Пример из релиза показателен своей осторожностью: агент отвечает на вопрос, где сегодня выгоднее купить валюту, сравнивая курсы по отделениям (пресс-релиз). Первым шагом стало чтение справочных данных, и это разумная последовательность.Т-Инвестиции пошли дальше всех по степени риска: их публичный MCP-сервер подключает агента прямо к брокерскому счёту — агент запрашивает котировки, проверяет баланс и выставляет заявки. Права токена делятся на три уровня: только чтение, полный доступ для торговых операций и доступ с переводами. В условиях прямо сказано, что брокер вправе односторонне ограничить доступ к серверу и не отвечает за решения агентов, убытки клиента и последствия компрометации доступа (документация Т-Банка). Там же виден незакрытый вопрос, интересный читателю этой статьи: обязательного подтверждения человеком у сделок в описании нет.Битрикс24 решил задачу с другой стороны.Их официальный MCP-сервер отдаёт агенту документацию собственного REST API — описания методов, параметры, допустимые значения, — чтобы модель перестала выдумывать несуществующие методы; работает он по Streamable HTTP и без авторизации (документация). Отдельно у них есть подключение самого Битрикс24 к внешним ИИ-системам, публичное с осени 2025 года (справка). Приём с документацией мы берём на заметку: машинно читаемая документация экономит агенту попытки, а вам — обращения в поддержку.Яндекс строит слой площадки: в Yandex AI Studio работает MCP Hub — конструктор и реестр MCP-серверов, где внешние серверы подключаются, а свои собираются из шаблонов и облачных функций (документация AI Studio). Параллельно Яндекс 27 февраля 2026 года анонсировал Yandex Commerce Protocol — собственный протокол агентной коммерции для магазинов, продающих внутри Алисы AI, с оплатой через Яндекс Пэй и Сплит (анонс). В июне того же года объявлена платформа интеграции ИИ-агентов в Алису AI, но пока на ней работают агенты самих сервисов Яндекса, а внешним партнёрам доступ заявлен на конец 2026 года (анонс).Robokassa 19 августа 2026 года выпустила публичный MCP-сервер платёжного агрегатора — через две недели после того, как наш пакет появился в открытом доступе, и это тот случай, когда сравнение дат полезнее спора о первенстве. Внутри 17 инструментов на полный цикл платежей — генерация счетов, проверка статуса оплаты, возвраты, отчётность, фискальные чеки. Устройство предохранителей близко к нашему: сервер по умолчанию поднимается в тестовом режиме, перевод в продуктивный делает оператор аккаунта руками после чек-листа, а списывать средства, менять настройки аккаунта и запускать возвраты без явного разрешения пользователя агент не может (отраслевая публикация с деталями).Одна нестыковка много говорит о зрелости рынка. В мае «первым банком с готовыми MCP-серверами» назвал себя Альфа-Банк, в июне «единственным MCP-сервером для корпоративного сегмента» — Сбер. Оба заявления сделаны добросовестно, просто рынок движется быстрее, чем пишутся релизы, и проверять первенство приходится самому.Слой серверов к российским сервисам собирается уже сейчас: в маркетплейсе Cloud.ru опубликовано больше пятидесяти MCP-серверов, среди них — к 1С:Предприятие, Контур.Фокус, Московской бирже, 2ГИС, HeadHunter, Авито, VK и Росстату (каталог). Здесь важна оговорка, прямо связанная с разделом про безопасность ниже: присутствие сервера в каталоге само по себе не означает, что его выпустил владелец сервиса. Издателя приходится проверять отдельно, и по нашему опыту эту проверку пропускают чаще всего.Регулятор двигает инфраструктуру, на которую всё это ляжет. Универсальный QR-код НСПК вводится поэтапно, по порогу выручки:
- с 1 сентября 2026 года — системно значимые банки и продавцы с выручкой свыше 120 млн рублей;
- с 1 сентября 2027 года — банки с универсальной лицензией и бизнес свыше 30 млн;
- с 1 сентября 2028 года — остальные банки и продавцы с выручкой от 20 млн
Разговор со скептиками
Весной 2026 года у протокола появился хор критиков, и обойти его в серии про MCP-сервер было бы странно. В марте на конференции Ask 2026 технический директор Perplexity Денис Ярац сказал, что компания внутри уходит от MCP обратно к REST API и командной строке (пересказ выступления). Гарри Тан из Y Combinator подхватил: «MCP sucks honestly» — съедает окно контекста, приходится включать и выключать, авторизация неудобная, а обёртку для командной строки он написал за тридцать минут (запись). Чэнь Чжан из Zilliz собрал эти голоса в заметку с заголовком «MCP Is Being Abandoned: How Fast Can a Standard Die?» и добавил свои доводы (текст). Мы прочитали всё это с карандашом. Их тезисы и наши ответы — ниже, включая те места, где критика попадает в нас.«Инструменты съедают 72 % контекстного окна»
Типичная связка из трёх серверов — GitHub, Playwright, интеграция с редактором — кладёт в окно 143 тысячи токенов описаний из 200 тысяч доступных, и модели остаётся меньше трети; с ростом числа инструментов точность их выбора падает с 43 % до 14 %. Числа мы не оспариваем — мы их меряли у себя и пришли к тому же выводу раньше, чем прочитали заметку. Поэтому у нашего сервера восемь инструментов, а не восемьдесят; набор для чтения стоит около 1 100 токенов, полный — около 4 000; размер описаний и ответов закреплён тестом, и тест падает от разросшегося описания так же, как от сломанной арифметики (вторая часть). Наборы для записи и возвратов включаются явно — это и есть раскрытие по мере надобности, только сделанное руками.Такая доля получается у серверов, которые сгенерированы из описания API целиком и вываливают в сессию всё, что умеет компания. Сам Тан вскоре написал, что передумал: MCP может быть отличным, если сервер лёгкий, сделан под задачу и спроектирован, а не натянут прокладкой поверх существующего REST API (запись), а в апреле добавил, что будущее — за связкой MCP и командной строки (запись). Протокол тем временем двигается в ту же сторону: Anthropic показала схему, где агент пишет код против инструментов вместо прямых вызовов, и рабочий поток с 150 тысяч токенов ужался до двух (Code execution with MCP), а редакция спецификации от 28 июля 2026 года убрала сессии и добавила ограничения по заголовкам.«CLI-обёртку я написал за тридцать минут»
Для разработчика на собственном ноутбуке это чистая правда, и спорить не с чем: командная строка с правами самого пользователя проще любого протокола. Вопросы начинаются, когда за обёрткой стоят чужие деньги. Кто держит токен и с какими правами? Как человек подтверждает сумму? Как отозвать доступ у одного агента, не трогая остальных? Как незнакомый клиент узнаёт, что ему разрешено? У протокола на каждый вопрос есть стандартный ответ: вход по OAuth 2.1 с экраном согласия, метаданные защищённого ресурса, элиситация для вопроса человеку, обязанность клиента показать команду запуска локального сервера и получить явное согласие. Обёртка за тридцать минут наследует полные права пользователя и ничего из этого не делает, пока её не допишут.«Авторизация неудобная» — здесь мы согласны по существу: это самая трудная часть сервера. Наш ответ — обмен токенов по RFC 8693, при котором у посредника нет секретов, и узкие области действия ровно под операции агента. Как именно и на что мы при этом наступили — в той же второй части.«Skills лучше: десятки токенов на старте и инструкция, что делать дальше»
Skills хранят инструкцию для модели: что сделать первым, как повторить при ошибке, когда остановиться. На старте агент видит только их заголовки, текст подгружается по надобности. Приём хороший, и мы им пользуемся: сценарии и справочник для агентов на сайте документации играют ту же роль. Но инструкция и инструмент лежат на разных слоях. Инструкция — текст, который модель может прочитать невнимательно. Предохранители для денег — две фазы у операции, подтверждение, привязанное к отпечатку параметров, идемпотентность, лимиты — обязаны жить в коде сервера, который откажет независимо от того, что модель прочитала. Одно другого не заменяет: инструкции можно раздавать и через MCP, а сервер без инструкций остаётся сервером.«Протокол отступит туда, где нужно централизованное управление»
Чжан предсказывает, что MCP перестанет быть «стандартом для всех» и останется там, где требуется единый вход, телеметрия и управление доступом. Мы с этим не спорим — платёжный сценарий и есть такое место. Токен, области действия, отзыв, след операций, согласие человека — ровно то, что критики называют тяжёлым, для денег обязательно. Сверху — сетевой эффект: продавцу нужно одно подключение для многих ассистентов, и на весну 2026 года, по данным той же заметки, работало больше десяти тысяч серверов, а SDK скачивали почти сто миллионов раз в месяц.Честная оговорка. Наш сервер — тонкий слой над открытым REST API Инвойсбокс. Если рынок уйдёт в командную строку и REST, API и справочник никуда не денутся, а самое дорогое — предохранители, описания и замеры — переедет в любую другую обёртку почти без правок. Мы ставим на протокол, но не ставим на него всё.«Тысячи серверов торчат в интернет без авторизации»
Это другая линия критики, не из заметки Чжана, и она попадает точнее всех остальных. По обзору лета 2026 года в интернете нашлось больше двадцати одной тысячи открытых MCP-серверов, и у девяти из десяти проверенных не было входа по OAuth (обзор); отравление описаний инструментов попало в отраслевые списки рисков. Отвечать тут нечем, кроме устройства собственного сервера: по HTTP он не отвечает без токена и проверяет токен до создания сессии, локальный запуск работает только на машине пользователя с его согласия, права по умолчанию только на чтение, каталог инструментов зафиксирован хешем в тесте, а чужой текст считается данными, а не указанием. Всё это разобрано во второй части — она и написана как ответ на этот класс претензий.У скептиков мы забираем три привычки — мерить токены, держать инструменты по пальцам одной руки и не стесняться REST и командной строки там, где они проще. Чего не забираем: проводить деньги через обёртку, у которой нет ни согласия человека, ни границ прав.Восемь правил, которые дешевле принять до первого выпуска
Всё, что мы поняли за эту работу, укладывается в восемь правил. Ни одно из них не про код — все про то, как работать, чтобы дорогие ошибки находились до пользователя, а не после.1
Тестовые данные придумывайте так, будто хотите сломать свой код
Проверка, где количество всегда равно единице, не найдёт ошибку в умножении. Меняйте то, что меняется в жизни: количество, ставку налога, число позиций.
2
Читайте чужой контракт, а не догадывайтесь о нём
Самое дорогое исправление выросло из догадки о смысле понятно названного поля. Пять минут чтения дешевле недели переделки.
3
Подтверждение проектируйте как разговор с человеком
Чем крупнее сумма, тем больше человека должно быть в этом разговоре. Если вышло наоборот — где-то перепутан знак.
4
Не полагайтесь на чужие настройки по умолчанию
У библиотеки может быть свой предел ожидания, о котором вы не знаете. Видно это только на настоящем вызове из настоящей сети.
5
Права называйте так, как их называет система, которая их выдаёт
Красивый собственный словарь разойдётся с реальным, и токен молча получит ноль прав.
6
Всё, что написано и в коде, и в тексте, должна сверять машина
Список инструментов, перечень прав, версия в примере установки — любое расхождение обязано ломать сборку.
7
Закладывайте второй заход проверки сразу
Исправление под давлением найденного дефекта само становится источником дефектов: три находки второго захода — следствие правок первого.
8
Не обещайте того, чего ещё нет
Открытые вопросы держите списком, с причинами. Обещанная, но не сделанная защита хуже отсутствующей — на неё рассчитывают.
