T-Bank MCP

Подтвердить платёж, который банк держит на WAITING_CONFIRMATION (второй фактор). Это НЕ то же, что confirm_otp — тот подтверждает ЛОГИН и шлёт код в id.t-bank-app.ru/auth/step. Платёжный код идёт другим путём. Вызывай этот тул, когда transfer_requisites / transfer / pay_bill вернули «ТРЕБУЕТСЯ ПОДТВЕРЖДЕНИЕ»: спроси у пользователя код из SMS или пуша и передай attempt_id из того ответа и otp='<код>'. Код нигде не логируется. Продолжение берётся из журнала попытки по attempt_id (operationTicket, initialOperation, тип подтверждения) — новый платёж НЕ создаётся, повторно списать нельзя. Неверны…

Отправить PIN (re-auth).

Как этим MCP пользовались: какие тулы звали, в каком порядке, что получили в ответ и где застряли. Для отладки самого MCP, не для банковских задач. Пишется автоматически при каждом вызове любого тула (выключается TBANK_TRACE=0). Секретов и свободного текста в трассе нет — см. tbank_mcp/trace.py. runs — сколько последних запусков сервера взять (0 = все, что есть в файле). top — сколько строк показывать в каждом разделе. Что смотреть: «повторы» — один и тот же тул с теми же аргументами подряд. Агент не понял ответ. Это самый прямой указатель на плохую формулировку в докстринге. «ответ…

Единая точка диагностики — БЕЗ секретов. Недавние redacted-события (checkout delivery/order/payment, оплата авиа, refresh сессии) ПЛЮС реестр попыток оплаты одним списком, чтобы после неопределённого исхода смотреть в одном месте. reconstruct попытку / найти последний подтверждённый шаг. Источник событий: ~/.local/share/tbank-mcp/events.jsonl; попыток — attempts.jsonl (полный вид — payment_attempts()). limit — сколько ПОСЛЕДНИХ событий показать (0 = все); шапка называет общее число, так что видно, сколько осталось за кадром.

Документы клиента: паспорт, загранпаспорт, ВУ, СНИЛС, ИНН, ОСАГО/КАСКО, ПТС/СТС. kind — фильтр по названию или коду (напр. "паспорт", "RusDriversLic"); пусто = все. В хранилище лежат и документы РОДСТВЕННИКОВ, которые клиент когда-то вводил — они отсеиваются по дате рождения; include_others=True покажет и их.

КУПИТЬ авиабилет. РЕАЛЬНЫЕ ДЕНЬГИ. Это ОДИН шаг: у авиа нет отдельной брони, вызов сразу оформляет и списывает. Подтверждение — кнопка: тул сам покажет «Оплатить/Отмена» с итоговой суммой. НЕ спрашивай «да/нет» текстом — покажи тариф, багаж и правила из flight_offer(), согласие даёт кнопка. Клиент без элиситации получает отказ, деньги при этом не двигаются. Исходов три, и тул различает их честно: билет оформлен → в ответе PNR и заказ; подписать оплату не удалось (нет активной сессии банка) → «ОПЛАТА НЕ ОТПРАВЛЕНА», деньги не двигались, можно повторить после refresh_session(); запрос ушёл, но …

История авиапоисков — и единственный источник кодов IATA с названиями. Резолвера «название → код» у банка нет, поэтому если пользователь называет город словами, ищи код здесь, а не подставляй по памяти. Технический нюанс: как и flight_search(), этот эндпоинт отвечает по мобильной сессии благодаря X-Travel-Context='mb' — заголовку, подобранному пробой вживую, а не увиденному в пассивном перехвате трафика.

Тарифы, багаж и правила возврата по выбранному рейсу. offer_id — из flight_search(). Один рейс из выдачи разворачивается в несколько тарифов: та же дата и тот же борт, но разный багаж и разные правила возврата. Тул показывает их по возрастанию цены и нумерует — этот номер (fare=1, 2, …) уходит в flight_book(). fare=N — показать багаж и правила только по одному тарифу. Цена читается заново: та, что была в поиске, могла устареть.

Поиск авиабилетов. from_code/to_code — коды IATA (MOW, LED, SVO), date — YYYY-MM-DD. direct_only=True оставляет только рейсы без пересадок, max_price — потолок цены за всё предложение. Оба отсекают ДО limit, поэтому limit=15 с direct_only покажет 15 прямых, а не 15 самых дешёвых стыковок. Без этого прямой рейс на ближней дате лежит на сотой строке выдачи. Резолвера «название города → код» у банка нет. Коды вместе с названиями отдаёт flight_history() — оттуда их и бери, а не угадывай. only_bookable=True (по умолчанию) — только те предложения, что бронируются внутри банка; их отдаёт первый же…

Карта мест в салоне с ценами. offer_id — из flight_search(), fare — номер тарифа из flight_offer(). Места платные и НЕобязательные: без них билет всё равно оформляется, ряд выдадут при регистрации. Выбранные места передаются в flight_book(..., seats="13A,13B") — по одному на пассажира, в том же порядке.

Гид по флоу: порядок вызовов для конкретной задачи. topic — что тебе нужно, своими словами: «продукты», «перевод», «билеты», «карты», «заказы», «кбжу», «инвест», «кредит», «чат», «поиск», «логин», «поезд», «самолёт», «отель», «поездки», «маркетплейс». Без аргумента — список тем и общие правила (там же про тулы с реальными деньгами). Отдаёт только подходящие разделы, а не весь файл.

Универсальный getter. section = subscriptions | subscription_bills | credit_schedule | credit_rating | statements | invoices | templates | contacts | cards | loans | autopayments | sbp | sbp_me2me | promocodes | offers | gifts | services | bundles | manager | merchant_subs | profile | homes | cars | shortcuts | finhealth_total | finhealth_turnover | finhealth_presets | finhealth_invest | invest_accounts | invest_offers | invest_yield | pension | broker_margin | shared | shared_owned | business_info | appointments | account_details | full_debt_amount | statement_exist. Секция вне списка — отказ…

Добавить товары в корзину. items = JSON [{id, count}, ...]. app_id/point_id — из grocery_stores() (обязательны). Запомни их — тот же магазин нужен для grocery_cart и grocery_checkout. Строку, у которой итоговое количество выше остатка (countAvailable), тул отклоняет с CART_QUANTITY_CONFLICT и НЕ пишет корзину — количество сам не уменьшает. Реши расхождение (меньше или замена) и повтори.

Содержимое корзины. app_id/point_id — из grocery_stores() (обязательны) и должны совпадать с теми, что использовались в grocery_add_to_cart. По каждой строке печатает «в наличии N» (остаток countAvailable), а если запрошено больше остатка — блок CART_QUANTITY_CONFLICT с перечнем SKU и, вместо подсказки на checkout, инструкцию сначала устранить расхождение.

Полный чекаут: доставка → заказ → оплата. РЕАЛЬНЫЕ ДЕНЬГИ. app_id/point_id — из grocery_stores() (обязательны, тот же магазин что в корзине). Если корзина просит больше остатка (count > countAvailable), тул останавливается ДО доставки: отвечает CART_QUANTITY_CONFLICT с перечнем SKU, заказ не создаётся и деньги не двигаются. Это проверка по инварианту корзины, а не расшифровка кода магазина. Уменьши до «в наличии» или замени (с согласия пользователя) и повтори. Подтверждение — кнопка, не текст: тул сам делает предпросмотр (только бэкенд знает, во что пересчитаются весовые товары), показывает …

Карточка товара: состав, КБЖУ, вес, срок хранения, производитель. good_id — из grocery_search()/grocery_plan_order(). КБЖУ приводится на 100 г и на упаковку (у части сетей КБЖУ есть только текстом — он разбирается).

Отменить продуктовый заказ (Город) — оплаченный или ещё нет. Деньги за оплаченный возвращаются на счёт списания. Покажи пользователю заказ и дождись согласия, прежде чем отменять. paymentId НЕ нужен (в отличие от ticket_cancel): приложение отменяет по одному orderId. Вердикт — payload.status ("Success"/"Failed" + code; 605 = заказ уже отменён), внешний "status":"Ok" успехом НЕ является. app_id (из grocery_stores() или payment_attempts()) не обязателен, но с ним тул сразу перечитает заказ и покажет фактический статус — до перечитывания «принято» ещё не значит CANCELED. Если тул вернул ошибку,…

Reconciliation: статус grocery-заказа по orderId (GET /api/grocery/order). Read-only. Проверь после UNKNOWN checkout, создался/оплатился ли заказ на бэкенде. app_id ОБЯЗАТЕЛЕН несмотря на пустой дефолт в схеме: без него банк отвечает сырым 400 вместо понятной причины. Магазин заказа известен из orders() (по имени) — соответствующий appId возьми из grocery_stores().

Спланировать заказ: для каждого ингредиента ищет (custom_ordered → global). ingredients = JSON массив, напр. ["свёкла","говядина","капуста"]. app_id/point_id — из grocery_stores() (обязательны). Каждая позиция помечена ✓ (уверенное совпадение) или «⚠ проверь» (нашёл, но токены совпали не полностью — вероятно не тот товар, сверь по имени). Матчинг чинит пунктуацию/порядок слов/словоформы, но синонимы и транслит НЕ угадывает — их добирай сам (см. лестницу в скиле: свои варианты → WebSearch → браузинг категории).

Кандидаты по запросу с атрибутами, опционально отсортированные. Это ИНСТРУМЕНТ, а не политика: сам по себе никакой стратегии выбора не применяет. Стратегию задаёт вызывающий, и только когда пользователь её попросил — иначе sort_by пустой и порядок остаётся магазинным. sort_by: price | weight | kcal | kcal_pack | protein | fat | carb (пусто = без сортировки). order: asc | desc. Питательные поля тянутся автоматически, если по ним сортируем (это +1 запрос на кандидата), либо по with_nutrition=True. Товары, у которых сеть не публикует нужное поле, всегда уходят в конец — и при asc, и при desc: «…

Поиск товара по названию. app_id/point_id — из grocery_stores() (обязательны). Возвращает товары с тегом likely_raw (сырой/готовый). limit — сколько показать (0 = все подходящие); в шапке видно, сколько нашлось всего и сколько товаров вообще вернула сеть.

Изменить или убрать товары в корзине. Считает количества АБСОЛЮТНО, в отличие от grocery_add_to_cart, который прибавляет. items = JSON [{"id": "123", "count": 2}, ...]: count > 0 — сделать ровно столько (не прибавить); count = 0 — убрать товар из корзины; товары, которых нет в списке, остаются как были. clear=True — очистить корзину целиком, items тогда не нужен. Отдельного эндпоинта удаления у банка нет: корзина всегда перезаписывается целиком, поэтому тул сам дочитывает текущий состав и шлёт полный список. Возвращает содержимое корзины ПОСЛЕ изменения — сверь его с ожидаемым. Количе…

Магазины, доступные по адресу пользователя: appId/pointId (нужны всем остальным grocery-тулам), окно ближайшей доставки, её цена, минимальная сумма заказа и кешбэк. Это ИНСТРУМЕНТ, а не политика: без sort_by порядок остаётся тем, что вернул банк. Сортируй, только когда пользователь назвал критерий. sort_by: speed (быстрее приедет) | price (дешевле доставка) | min_sum (ниже минимальная сумма). order: asc | desc. «Быстрее» считается по КОНЦУ ближайшего окна — «привезут не позже», — потому что банк отдаёт два разных вида слота: «до 15 мин» и «завтра 08:00–11:00», и сравнимы они только по этому…

Карточка отеля: адрес, время заезда, отзывы. С датами — ещё и тарифы: цена, питание, до какого числа бесплатная отмена. hotel_id — из hotel_search(). Забронировать через MCP нельзя: в API банка нет вызова, который принимал бы bookHash. Дальше — приложение или сайт.

Поиск отелей. query — город, регион или название отеля («Сочи», «Красная Поляна»); checkin/checkout — YYYY-MM-DD; children — возрасты детей через запятую («5,12»). Забронировать отель через MCP НЕЛЬЗЯ — только найти и сравнить. Тарифы и условия отмены по конкретному отелю — hotel_info(hotel_id, checkin, checkout).

Действующие страховые полисы (ОСАГО/КАСКО/путешествия) с суммами и сроками.

Инвест-счета: брокерские и InvestBox. brokerAccountId отсюда — единственный аргумент invest_portfolio/invest_operations/invest_securities.

Брокерские операции, новые сверху. limit применяется и к запросу, и к выводу (0 = всё, что вернул банк). operation_type — фильтр по типу; пусто = все. Полного списка банк не публикует. Наблюдались: buy, sell, payIn, payOut, tax, taxBack (живой ответ) и outMulti (захват приложения). Список не полон — сначала вызови без фильтра и посмотри, какие типы реально пришли в ответе, потом фильтруй по ним.

Статистика портфеля (ввод/вывод, купоны, дивиденды, стоимость по месяцам) за период. broker_account_id — из invest_accounts().

Бумаги в портфеле: тикер, количество, текущая цена, доля и доходность. broker_account_id — из invest_accounts(); пусто = все портфели. Учти: у брокерского счёта может быть НЕСКОЛЬКО портфелей (рублёвый, валютный), и brokerAccountId портфеля не совпадает с id счёта из invest_accounts() — поэтому пустой ответ на конкретный id ещё не значит «бумаг нет». Вызови без аргумента и посмотри, какие портфели есть.

Пинг — продлить сессию.

Счета, балансы и карты каждого счёта (id + ucid). ucid — для card_limits/card_requisites, id — для card_operations. Полный список карт с типом и статусом — list_cards().

Все карты по всем счетам: id, ucid, баланс, тип. id — для card_operations, ucid — для card_limits/card_requisites. Карты, привязанные из ДРУГИХ банков, помечены «внешняя»: у них нет ucid, и card_limits/card_requisites по ним не работают.

Операции за период, новые сверху. limit — сколько показать (0 = все). В шапке всегда указано, сколько операций всего за период, поэтому видно, обрезан ли ответ. desc_len — ширина колонки описания (0 = описание целиком). Обрезанное описание кончается на «…» — полный текст даст desc_len=0.

Начать логин. Отправляет SMS OTP. Возвращает какой шаг следующий (otp/password/pin). Спроси у пользователя код и вызови confirm_otp(otp); если банк попросит — confirm_pin(pin). Пароль вводится не через агента: пользователь запускает tbank-mcp-login (pip-установка) или login_cli.py (репозиторий) в своём терминале.

Список чатов (одна страница банка). offset — с какого чата начать (следующая страница: offset из подсказки в шапке ответа), считая С НАЧАЛА списка. archived=True — архивные чаты. Не путать с offset у messenger_messages() — там отсчёт с КОНЦА (от самых новых), это два разных тула с разной точкой отсчёта.

Скачать вложение из чата (выписку, отчёт, справку) НА ДИСК и вернуть путь. Содержимое тул не разбирает: файл лежит на той же машине, где работаешь ты, поэтому читай его своими инструментами — PDF, текст, картинку через Read по пути, таблицу (xlsx/docx) своим скриптом. file_id и conversation_id бери из ОДНОГО сообщения messenger_messages() — строка вида «[файл: имя | 67 КБ | file_id=…]». Пара обязательна: тот же file_id в другом чате отдаёт 401. Имя файла копировать не надо: его называет сам ответ банка, тул возьмёт оттуда. По умолчанию — в ~/.local/share/tbank-mcp/chat-files/ с правами 0600…

История чата, старые сверху. Банк отдаёт одну страницу истории; параметры листают её ЛОКАЛЬНО: limit — сколько сообщений показать (0 = вся страница); offset — сколько САМЫХ НОВЫХ пропустить (окно старее: offset=20, 40, …). Отсчёт с КОНЦА страницы — не то же самое, что offset у messenger_conversations(), где отсчёт с начала списка чатов; max_chars — кап текста одного сообщения (0 = целиком). Обрезка всегда помечена и называет полную длину; before_id — курсор банка: id сообщения, СТАРЕЕ которого догрузить ПРЕДЫДУЩУЮ страницу…

Отправить сообщение в чат — НЕОБРАТИМО, его прочитает живой человек (обычно поддержка банка). Денег не двигает, но и отозвать нельзя. Покажи пользователю текст и дождись согласия, прежде чем отправлять. conversation_id — из messenger_conversations().

Чаты с непрочитанными сообщениями (по названиям, а не по сырым id).

Траты, сгруппированные банком. Возвращает сырой JSON (дерево summary + intervals[].aggregated[]); для готовой разбивки по категориям бери spending_categories() — он это дерево уже разворачивает. Внутренние переводы (между своими счетами) ИСКЛЮЧЕНЫ: эндпоинт всегда вызывается с config=allNotInner, как в приложении. Полный список операций, включая внутренние, — list_operations(). max_chars — предел размера ответа (0 = без предела). Шапка всегда называет, что урезано и на сколько. В захвате приложения этот эндпоинт вызывался 27 раз и КАЖДЫЙ раз с period=«day», group_by=«category» — только эта …

Детали одного заказа (места, зал, код брони, состав корзины). Работает для развлекательных заказов (кино/концерты); для продуктов — grocery_order_status, для поездок — travel_order_details(order_id) (вагон, места, маршрут, отель).

Все заказы клиента: продукты, кино, концерты, авиабилеты, ж/д, отели. kind — "афиша" | "кино" | "путешествия" | "продукты" | код objectType; пусто = все. Отсортировано по дате создания, новые сверху. limit=0 — показать все.

Оплатить счёт: ЖКХ, связь, интернет, штраф, налог. РЕАЛЬНЫЕ ДЕНЬГИ. provider_id и fields — из payment_providers(provider_id=…), fields — JSON вида {"account": "1234567890"}. Имена полей у каждого провайдера свои, угадывать их нельзя: тул сверяет значения с регуляркой из каталога и откажет до отправки. Перед оплатой тул сам считает комиссию (это же и проверка тела банком) и показывает пользователю кнопки «Оплатить/Отмена» с ИТОГОВОЙ суммой и комиссией (для сумм от TBANK_CONFIRM_ABOVE) — подтверждение даёт кнопка, НЕ спрашивай «да/нет» текстом заранее. Клиент без элиситации получает отказ «ПЛА…

Недавние попытки ОПЛАТЫ (read-only) — для reconciliation после неопределённого результата (UNKNOWN). Общий реестр: продукты (checkout), авиабилеты и прочие денежные операции, что ведут журнал попыток, — не только grocery. Показывает status/step/order_id/attempt_id/sum и детали ответа. Это же хранилище блокирует повторное списание, пока исход не подтверждён. Более широкая лента событий — diagnostics(), она же показывает и эти попытки одним списком. limit — сколько последних попыток показать (0 = все); в шапке видно общее число.

Предпросмотр комиссии (денег НЕ двигает). body обязателен — это JSON-строка. Форма (сверена с захватом): {"payParameters": { "account": "<счёт списания из list_accounts()>", "moneyAmount": 1500, "currency": "RUB", "paymentType": "Transfer", // "Payment" для оплаты услуг "provider": "p2p-anybank", // или transfer-inner / id провайдера "providerFields": { ... } // для перевода по телефону — }} // provider_fields из одного кандидата // transfer_sbp_resolve(), как есть НЕ пиши pointe…

Каталог платёжных провайдеров (ЖКХ, связь, штрафы, налоги, интернет…) — только чтение, денег не двигает. Без аргументов печатает ГРУППЫ провайдеров — с них и начинай, дальше payment_providers(group="ЖКХ"). group — это НАЗВАНИЕ группы, не id. query — подстрока по названию провайдера внутри группы (фильтрует ТЕКУЩУЮ страницу). page — номер страницы каталога, шапка подсказывает следующую. provider_id="<id>" печатает ПОЛЯ, которые провайдер требует для платежа: id поля, человеческое название, обязательность, подсказку и регулярку, по которой значение проверяется. Это единственный источник формы …

Прочитать платёжный QR со счёта/квитанции (ГОСТ Р 56042-2014, строка ST0001…). ТОЛЬКО ЧТЕНИЕ, денег не двигает. Показывает получателя, его реквизиты, сумму из QR и комиссию — то есть всё, что нужно показать пользователю ПЕРЕД transfer_requisites(). Спрашивает у банка, каким провайдером этот QR платится: реквизитный счёт юрлица → transfer-legal (плати через transfer_requisites), любой другой провайдер → pay_bill. Назначение платежа в QR есть не всегда, а банк его требует — если в выводе «Назначение платежа» пусто, спроси у пользователя и передай comment=… .

Скачать PDF-чек по платежу. По умолчанию — в ~/.local/share/tbank-mcp/receipts/. save_to — свой путь файла. Существующий файл НЕ перезаписывается: чтобы заменить, передай overwrite=True. Чек — это платёжное поручение (плательщик, получатель, сумма, назначение), поэтому файл создаётся с правами 0600. payment_id берётся ровно из пяти мест, других производителей нет: orders() (поле paymentId в строке заказа), grocery_order_status(), и ответы transfer(), pay_bill() и ticket_pay(). В list_operations() его НЕТ — операция и платёж нумеруются по-разному.

Состояние платёжной попытки по attempt_id: висит ли она на подтверждении, подтверждена или её исход неизвестен. Показывает то, что MCP записал в журнал попытки. Наземная правда — в операциях по счёту: если для висящего платежа списания в list_operations нет, деньги ещё не ушли и его можно подтвердить через confirm_payment(attempt_id, otp).

Карточка площадки: название, город, метро, залы. Адрес в самой карточке приходит ПУСТЫМ — во всех захваченных ответах, — так что with_halls=True дочитывает залы, где адрес есть. limit — сколько залов показать (<=0 — все), с честным «N всего, показано M».

Что идёт на площадке: концерты, спектакли, выставки. КИНО здесь НЕТ — репертуар кинотеатра берётся cinema_schedule(object_id=…, date=…). object_id — из afisha_places() или search_app().

Число непрочитанных push-уведомлений.

Обновить сессию. Сначала пробует refresh_token, при invalid_grant — silent re-login через SSO_SESSION (без OTP). Если оба пути не работают — REAUTH_REQUIRED.

Полнотекстовый поиск по разделу приложения. screen — СТРОГИЙ enum, угадывать бесполезно (всё остальное → 400): afisha — кино, концерты, театр, выставки, спектакли (по умолчанию); отдаёт eventId, готовый для cinema_schedule/concert_schedule movie_main — только фильмы services — самый широкий: та же афиша плюс контакты из телефонной книги и сервисные блоки; id приходится доставать из диплинка concerts_main — только концерты (уже сузка внутри afisha) spectacle_main — только театр exhibition_main — только выставки grocery …

Проверить жива ли сессия. Сам поднимает уровень до CLIENT, если окно портальной сессии (~11 минут) успело закрыться.

Корзины маркетплейса — по одной на продавца. Оформление заказа через MCP не поддерживается: подтверждённого шага размещения в захвате нет. Корзину видно, оплатить её надо в приложении. limit — сколько позиций одной корзины показать (<=0 — все); каждая корзина рассчитывается отдельно, с честным «N всего, показано M».

Поиск товаров в маркетплейсе Т-Банка (Город → Шопинг). Пагинация СЕРВЕРНАЯ: offset листает выдачу, всего результатов видно в шапке. limit<=0 здесь НЕ значит «показать всё» (в отличие от большинства других тулов этого сервера) — молча используется 20; листай через offset. Печатает skuId, pointId и shopId — они опознают позицию, но добавить её в корзину через MCP нельзя: тула для этого нет, shop_cart() только читает. Оформить и оплатить заказ отсюда НЕЛЬЗЯ: в захвате нет подтверждённого шага размещения, только расчёт доставки. Собранную корзину пользователь оформляет в приложении.

Траты по категориям.

Отменить заказ билета. kind — "movie" или "concert". Отменяется заказ, у которого банк сам выставил isCancelAvailable=true — это видно в order_details(). Такой заказ уходит в PARTIALLY_CANCELED, а не CANCELED: билеты возвращают, сервисный сбор — нет, и «частично» здесь не ошибка. Билеты вернут, сервисный сбор не возвращается — покажи это пользователю и дождись согласия, прежде чем отменять. Заказ, помеченный isCancelAvailable=false, хост отменять отказывается: отвечает status=Failed с кодом и НИЧЕГО не меняет. Повторять такой вызов бессмысленно. Тул сначала читает заказ и, если банк отменят…

ОПЛАТИТЬ бронь билета. РЕАЛЬНЫЕ ДЕНЬГИ. Подтверждение — кнопка: тул сам покажет пользователю «Оплатить/Отмена» с суммой заказа (для сумм от TBANK_CONFIRM_ABOVE). НЕ спрашивай «да/нет» текстом заранее — покажи места и итог со сбором (из cinema_book), потом вызывай; согласие даёт кнопка. Клиент без элиситации получает отказ «ПЛАТЁЖ НЕ ВЫПОЛНЕН» — деньги там не двигаются. Все три первых аргумента бери из ответа cinema_book(): order_id, итоговую сумму и nfs_payment_token. Токен живёт только в ответе на создание заказа — order_details() его не отдаёт, поэтому переспросить потом будет негде. accoun…

Сам билет по оплаченному заказу: код брони, QR и ссылка на PDF. Лежит это в ленте заказов, а НЕ в order_details(), который отдаёт только код брони. Что именно есть — зависит от партнёра: из 75 афишных заказов код брони был у всех, QR у 53, а Ticketland не даёт ни QR, ни PDF. Тул печатает то, что есть, и прямо говорит, чего нет. QR — это короткая строка-payload, которую показывают сканеру, а не картинка. Пустой ответ означает «билета ещё нет» (или бронь не оплачена — неоплаченные в ленту не попадают), а не «заказа не существует».

ЗАБРОНИРОВАТЬ места в поезде. Денег НЕ списывает, но ДЕРЖИТ места ~15 минут. train_id — из train_search(); seats — «вагон/место» через запятую, ровно как их печатает train_seats(): seats="03/10,03/12". passengers="me" — сам владелец счёта, паспорт берётся из данных банка (documents()). Для нескольких пассажиров — JSON-список: [{"me":true},{"first":"Имя","last":"Фамилия","middle":"Отчество", "birthDate":"1990-01-31","number":"1234567890","sex":"female"}] Число пассажиров должно совпадать с числом мест — кто первый в списке, тот едет на первом месте. Детская бронь (пассажир младше 18) через…

Даты, на которые открыта продажа по направлению. Заодно дешёвая проверка пары кодов станций: на неверной паре ответ пуст.

ОПЛАТИТЬ бронь поезда. РЕАЛЬНЫЕ ДЕНЬГИ. Подтверждение — кнопка: тул сам покажет «Оплатить/Отмена» с суммой заказа. НЕ спрашивай «да/нет» текстом — покажи места и сумму из train_book(), согласие даёт кнопка. Клиент без элиситации получает отказ, деньги при этом не двигаются. БЕЗ card_id ничего не оплачивает: возвращает список КАРТ, которыми можно заплатить (счета показаны для справки — оплата со счёта только в приложении, этот тул принимает card_id). Выбери карту вместе с пользователем и вызови ещё раз с её card_id. Сумму тул берёт из самого заказа, а не из аргумента, — её нельзя разойтись с …

ВОЗВРАТ ЖД-билета. Необратим: место уходит обратно в продажу. Без confirm=True ничего не возвращает — показывает расчёт: сколько вернут за каждый билет и сколько удержат сборами. Покажи этот расчёт пользователю и только потом вызывай с confirm=True. ticket_ids — если пусто, возвращаются ВСЕ возвратные билеты заказа.

Поиск поездов. origin/destination — ЧИСЛОВЫЕ коды станций банка (2000000 — Москва, 2004000 — Санкт-Петербург), date — YYYY-MM-DD. Резолвера «название станции → код» у банка нет. Если кода не знаешь, проверить пару можно train_calendar(origin, destination): она скажет, какие даты вообще в продаже, и на неверной паре ответит пусто. Дальше: train_seats(train_id) — вагоны и места, оттуда train_book().

Вагоны и свободные места в поезде. train_id — из train_search(). car_type — фильтр по типу («плац», «купе», «сид»), max_price — верхняя граница цены места. Места печатаются как «вагон/место» — именно в таком виде их ждёт train_book(train_id, seats="03/10,03/12"). Цены и наличие читаются заново на каждый вызов: место могли занять минуту назад.

Перевод (РЕАЛЬНЫЕ ДЕНЬГИ). Подтверждение — кнопка, не текст: тул сам покажет пользователю выбор банка (если их несколько) и кнопки «Перевести/Отмена» (для сумм от TBANK_CONFIRM_ABOVE). НЕ спрашивай «да/нет» заранее — вызывай, когда сумма и получатель известны; согласие даёт кнопка. Клиент без элиситации получает отказ «ПЛАТЁЖ НЕ ВЫПОЛНЕН» — деньги там не двигаются вообще. from_account — счёт списания из list_accounts(). Пусто = первый рублёвый Current с положительным балансом; это ДОГАДКА, поэтому если пользователь выбирал счёт — передай его явно, иначе спишется с другого. Кредитную карту как…

Перевод юрлицу или ИП по банковским реквизитам (БИК + счёт + ИНН). РЕАЛЬНЫЕ ДЕНЬГИ. Подтверждение — кнопка, не текст: тул сам покажет пользователю «Перевести/Отмена» (для сумм от TBANK_CONFIRM_ABOVE) ДО отправки. НЕ спрашивай «да/нет» заранее — покажи реквизиты и назначение (payment_qr для QR), потом вызывай; согласие даёт кнопка. Клиент без элиситации получает отказ «ПЛАТЁЖ НЕ ВЫПОЛНЕН» — деньги там не двигаются вообще. Два способа задать реквизиты, их можно смешивать: - qr="ST00012|Name=…|PersonalAcc=…" — строка платёжного QR со счёта. Заполняет всё сразу, включая сумму. Сначала покажи по…

Резолвинг получателя по номеру (read-only, БЕЗ денег) — счёт в Т-Банке И банки СБП. Возвращает маскированное имя + банк + isDefaultBank и готовый provider_fields. Используй ПЕРЕД transfer()/payment_commission() для НОВОГО (несохранённого) получателя. provider_fields вставь в payParameters.providerFields комиссии — не пиши 8276 руками. Счёт в Т-Банке — отдельный кандидат (перевод внутри банка, не через СБП): у него НЕТ bankMemberId. Если он в списке, получатель — клиент Т-Банка, даже когда в СБП Т-Банка не видно; это разные списки, и раньше тул показывал только второй. Для transfer() передай p…

Детали поездки по orderId из orders("путешествия") — отель, поезд, самолёт. Для ЖД показывает вагон, места и статус электронной регистрации; для авиа — маршрут и документы; для отеля — даты, номер, питание, гостей. Билет или маршрутную квитанцию в файл — travel_ticket_file(order_id).

Чем платить за поездку и сколько это стоит на самом деле: доступные счета, сколько бонусов можно списать, сколько кэшбэка вернётся, какие есть рассрочки. amount — сумма покупки (из flight_offer() или train_book()). Ничего не платит и ничего не меняет.

Сохранить билет в файл: ЖД-бланк или маршрутные квитанции по перелёту. По умолчанию — в ~/.local/share/tbank-mcp/receipts/. order_id — из orders("путешествия"), train_book() или flight_book(). Тул сам определяет вертикаль: у ЖД это один PDF-бланк на заказ, у авиа — по квитанции на пассажира плюс общая; сохраняются все. Файлы создаются с правами 0600: в билете паспортные данные пассажиров. Существующий файл не перезаписывается — для замены overwrite=True.

Поездки — самолёты, поезда и отели одной лентой. Без аргумента — список; с trip_id — карточка поездки: маршрут, статус, страховка. Это НЕ то же самое, что orders(): там заказы всех вертикалей вместе с продуктами и кино, здесь только поездки.