T-Bank MCP

Реквизиты счёта для перевода извне: получатель, счёт, БИК, корсчёт, ИНН/КПП. account_id — из list_accounts(). currencies — через запятую (RUB,USD,EUR).

Афиша вертикали за ПЕРИОД дат: что идёт с date_from по date_to. kind — "кино" | "концерт" | "театр". У выставок каталога по датам нет — для них search_app(screen="afisha") или place_schedule(). city обязателен (или city_id числом), даты — YYYY-MM-DD; одна дата = один день. Диапазон реально работает: неделя показывает заметно больше, чем сутки, — туда попадают разовые показы, которых в однодневной выдаче нет. У кино сеансы здесь НЕ приходят: их даёт cinema_schedule(event_id, date). У концертов и спектаклей ближайшие слоты видно сразу. query — фильтр по названию, местный.

Площадки города: кинотеатры, залы, театры, музеи — с их objectId. Это единственный способ узнать objectId площадки, не заходя через какое-то событие в ней. Дальше objectId принимают cinema_schedule(object_id=…) — весь репертуар кинотеатра на день, — place_schedule() и place_info(). kind — "кино" | "концерт" | "театр" | "выставка". city обязателен (или city_id числом). query — фильтр по названию. Он МЕСТНЫЙ: у банка текстового поиска по площадкам нет, поэтому страницы читаются целиком до фильтрации. pages — сколько страниц по 100 прочитать.

Справки, заказанные в банке (о движении средств, о доходах и т.п.).

Лимиты по карте (на покупки, на снятие) и сколько уже израсходовано. ucid — из list_cards().

Операции по КОНКРЕТНОЙ карте. card_id — поле id из list_cards(). Серверного фильтра по карте нет (API умеет только excludeCardIds), поэтому берутся операции за период и фильтруются по полю card. limit=0 — показать все за период. desc_len — ширина колонки описания (0 = описание целиком, обрезка помечена «…»).

Реквизиты карты: держатель, срок, номер. ucid — из list_cards(). По умолчанию номер маскируется, а CVV не выводится вообще. reveal=True выдаёт ПОЛНЫЙ номер и CVV — этого достаточно, чтобы платить картой. Ставь его ТОЛЬКО когда пользователь явным текстом попросил показать полные реквизиты, и предупреди, что они попадут в переписку. «Покажи мою карту» — это не такая просьба.

ЗАБРОНИРОВАТЬ места. Создаёт заказ, но НЕ платит — деньги списывает отдельный ticket_pay(). Неоплаченная бронь отваливается сама. kind — "кино" | "концерт" | "театр" | "выставка". seats — через запятую: для кино "7:10,7:11" (ряд:место из cinema_seats), для остальных — составные seatId из cinema_seats(kind=…) как есть. seat_type применяется ТОЛЬКО к кино: у трёх других вертикалей поля type в запросе нет вовсе — так в захвате. Покажи пользователю итоговую сумму со сбором ДО вызова ticket_pay.

Сеансы кино на дату. date — YYYY-MM-DD. limit — сколько площадок/фильмов показать, 0 = все (по умолчанию 20). Городской режим (event_id+city, без cinema/around) может вернуть сотни кинотеатров разом — сузь cinema/around или подними limit, если нужно больше показанных по умолчанию 20. Три режима: - object_id БЕЗ event_id — ВЕСЬ репертуар кинотеатра на день, один запрос. Так и надо отвечать на «что идёт завтра в этом кинотеатре»: перебирать афишу города по фильму и дорого, и неполно — сегодняшний список не знает о фильме, который идёт только завтра. - event_id + object_id — один фильм в одном кинотеатре. - event_id + city — этот фильм по всему городу, с сортировкой по расстоянию. objectId кинотеатра берётся из afisha_places() или из search_app(). cinema — подстрока названия кинотеатра ("каро 11"), around — время "17:00", window_min — допуск в минутах вокруг него. city — обязателен, ЕСЛИ не задан object_id, и передаётся именем (этот эндпоинт берёт название, а не числовой cityId). Он же задаёт точку, от которой считается расстояние до кинотеатров, поэтому передавай тот же город, что и в cinema_search(): расписание Петербурга, отсортированное от центра Москвы, выглядит правдоподобно и бессмысленно. С object_id город не нужен — площадка его уже задаёт. Отдаёт objectId площадки и slotId каждого сеанса — оба нужны для cinema_seats() и cinema_book(), поодиночке бесполезны. В режиме репертуара (object_id без event_id) к каждому фильму печатается ещё и eventId — он тоже нужен для cinema_seats()/cinema_book(), ведь фильм в каждой строке свой.

Найти фильм в прокате и его eventId (нужен для cinema_schedule). query — часть названия; пусто = вся сегодняшняя афиша города (её видно целиком только при limit=0 — по умолчанию показаны первые 20). city — город афиши, ОБЯЗАТЕЛЕН: молчаливая Москва даёт правдоподобный список чужого города. Известно 65 городов; если нужного нет в таблице, передай city_id числом (его видно в ошибке и в выдаче площадок). Сам eventId от города не зависит. pages — сколько страниц афиши сканировать (по 30 фильмов; раньше потолок 8 страниц был зашит). Если шапка говорит «остальные НЕ проверены» — подними pages, limit скан не расширяет.

Свободные места на сеансе. Денег не двигает. slot_id и object_id — из cinema_schedule()/concert_schedule(). row — показать только один ряд, max_price — потолок цены за место. kind — "кино" | "концерт" | "театр" | "выставка" (принимает и movie / concert / spectacle / exhibition). sector_id — показать один сектор; без него приходят все. limit — поднять кап показа (по умолчанию 40 мест / 24 номера в ряду; хвост «…ещё N» подсказывает значение). У кино места нумерованные — бронь идёт как "ряд:место". У остальных трёх вертикалей место опознаётся составным seatId, и его надо вернуть в cinema_book ЦЕЛИКОМ, как напечатано.

Секторы со свободной рассадкой (входные билеты, фан-зоны). kind — "концерт" или "театр": у кино места нумерованные, а у выставок такого экрана в API нет вовсе. Только чтение: примера создания заказа именно с этого экрана в захвате нет, поэтому бронировать отсюда MCP не умеет — только смотреть наличие. Сами места с их seatId видны в cinema_seats(kind=…).

Показы концерта, спектакля или выставки: площадка, дата, slotId и objectId для cinema_seats(). kind — "концерт" | "театр" | "выставка". Кино сюда НЕ ходит: у него показы привязаны к дате, это cinema_schedule(event_id, date). object_id — сузить до одной площадки. limit — сколько площадок показать, 0 = все (по умолчанию 15). Даты в запросе нет — приходит всё будущее сразу, у гастрольных событий площадок может быть много. Даты в запросе нет: приходит всё будущее сразу, поэтому нужный день выбирай из напечатанного. event_id — из search_app(query, screen="afisha").

Отправить SMS-код.

НЕ вызывай напрямую из чата: пароль аккаунта не должен проходить через агента. Этот тул существует для логин-CLI (tbank-mcp-login, в репозитории — login_cli.py), который читает пароль из терминала, невидимого модели. Если банк просит password (первый логин на новом устройстве) — попроси пользователя запустить tbank-mcp-login (или login_cli.py из репозитория).

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

Отправить 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. limit — сколько ПОСЛЕДНИХ событий показать (0 = все); шапка называет общее число, так что видно, сколько осталось за кадром.

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

КУПИТЬ авиабилет. РЕАЛЬНЫЕ ДЕНЬГИ. Это ОДИН шаг: у авиа нет отдельной брони, вызов сразу оформляет и списывает. Подтверждение — кнопка: тул сам покажет «Оплатить/Отмена» с итоговой суммой. НЕ спрашивай «да/нет» текстом — покажи тариф, багаж и правила из flight_offer(), согласие даёт кнопка. Клиент без элиситации получает отказ, деньги при этом не двигаются. ⚠️ ПОДПИСЬ ВОСПРОИЗВЕДЕНА, НО ЖИВОЙ ПЛАТЁЖ НИ РАЗУ НЕ ВЫПОЛНЯЛСЯ. Схема x-api-signature восстановлена из JS travel-вебвью и совпадает с захватом байт-в-байт (HmacSHA256, ключ — travel-сессия; см. client.travel_api_signature), вместе с X-Detach-Key/X-Detach-Timeout — тул шлёт их все. Чего НЕ хватает: ключ подписи — это ОТДЕЛЬНАЯ web-сессия travel, которую даёт SSO-мост session/link (travel_link_session), а он вживую не подключён. Поэтому сейчас тул честно откажет «ОПЛАТА НЕ ОТПРАВЛЕНА» (деньги не двигаются), пока travel- сессия недоступна. Живьём платёж не гонялся — надёжный путь остаётся приложение. offer_id — из flight_search(), fare — номер тарифа из flight_offer(). passengers="me" — владелец счёта (паспорт и латиница из данных банка); для нескольких — JSON-список, как у train_book(). Детская бронь (младше 18) не поддержана — тул откажет, детский билет оформляется в приложении. seats — необязательно, «13A,13B» по одному на пассажира в том же порядке; без них место выдадут при регистрации. Сумму тул считает сам (тариф + места) и кладёт на кнопку свою цифру, а не ту, что назвал агент: цена тарифа могла измениться с момента поиска. Возврата авиабилета через MCP нет — в API банка такой операции не нашлось. force=True — повторить покупку, чей исход не подтверждён, и только после проверки в trips() и приложении, что билет не выписан.

История авиапоисков — и единственный источник кодов 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. Резолвера «название города → код» у банка нет. Коды вместе с названиями отдаёт flight_history() — оттуда их и бери, а не угадывай. only_bookable=True (по умолчанию) — только те предложения, что бронируются внутри банка; их отдаёт первый же батч, поэтому поиск быстрый. False дочитывает весь поток: это десятки секунд и тысячи предложений, почти все — от партнёров, которые уводят на свой сайт. Оформление и оплата — flight_book(offer_id, fare, passengers): один шаг, он же бронь, он же оплата. ⚠️ Этот путь экспериментальный и ни разу не выполнялся — запрос уходит без подписи, которую шлёт приложение, и шлюз может его отвергнуть («ИСХОД НЕИЗВЕСТЕН»). Поиск, тарифы и места (этот тул, flight_offer, flight_seats) — полноценные; для надёжной покупки — приложение. Технический нюанс: заголовок X-Travel-Context='mb', который делает этот эндпоинт доступным по мобильной сессии, не встречался в пассивном перехвате трафика — он был подобран пробой вживую. Если банк когда-нибудь изменит поведение этого хоста, это первое место, куда стоит посмотреть.

Карта мест в салоне с ценами. 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. Секция вне списка — отказ со списком допустимых, а не запрос наугад. Платёжный QR разбирает payment_qr(qr), не эта секция. ⚠️ Счета к оплате лежат в ДВУХ разных местах, и «пусто» в одном не значит, что счетов нет: invoices — выставленные счета (e-invoicing). Часто пусто. subscription_bills — счета по подпискам на ЖКХ и прочие услуги. Именно здесь обычно и лежит неоплаченная квитанция, вместе с paymentFields, которые нужны pay_bill(). Проверяй ОБА, прежде чем сказать «неоплаченных счетов нет». СЕМИ секциям НУЖЕН arg — без него тул не вернёт пустоту, а поднимет ошибку: sbp_me2me — arg = СВОЙ телефон. Отвечает, из каких банков клиент может стянуть собственные деньги по СБП. Это НЕ поиск получателя — для него transfer_sbp_resolve(phone). providers — arg = список id через запятую («fns-rf,gibdd-online-rf»). Перечислить все провайдеры этим эндпоинтом нельзя, только найти известные по id. requisites — arg = телефон. Обычно вместо этого нужен transfer_sbp_resolve(phone); а реквизиты СВОЕГО счёта — это account_requisites(account_id). statements — arg = номер счёта из list_accounts(). days задаёт окно выписки (по умолчанию 30 — раньше это окно было зашито и нигде не упоминалось; другие секции days не принимают). account_details — arg…

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

Недавние попытки grocery checkout (read-only) — для reconciliation после неопределённого результата (UNKNOWN). Показывает status/order_id/attempt_id/sum. limit — сколько последних попыток показать (0 = все); в шапке видно общее число.

Содержимое корзины. 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, заказ не создаётся и деньги не двигаются. Это проверка по инварианту корзины, а не расшифровка кода магазина. Уменьши до «в наличии» или замени (с согласия пользователя) и повтори. Подтверждение — кнопка, не текст: тул сам делает предпросмотр (только бэкенд знает, во что пересчитаются весовые товары), показывает пользователю кнопки «Оформить заказ на N ₽ / Отмена» с ФИНАЛЬНОЙ суммой и оформляет заказ ровно на неё. Покажи состав корзины ДО вызова (кнопка называет только итог), но НЕ спрашивай «да/нет» текстом — согласие даёт кнопка. Клиент без элиситации получает отказ «ПЛАТЁЖ НЕ ВЫПОЛНЕН» — деньги там не двигаются вообще. dry_run=True — ПРЕДПРОСМОТР: доводит до доставки и возвращает финальную сумму, НЕ создавая заказ и НЕ списывая деньги. Работает в любом клиенте. Нужен, если хочешь назвать пользователю итог и слот доставки заранее; для оплаты не обязателен — чекаут делает свой предпросмотр сам. СЧЁТ СПИСАНИЯ по умолчанию — тот, которым пользователь последний раз платил за продукты В ПРИЛОЖЕНИИ (банк отдаёт его сам), а НЕ первый счёт с балансом. Хочешь другой — передай account_id из list_accounts(). Списанный счёт печатается в ответе. expected_sum — необязательная сверка: сумма, которую ты уже называл пользователю (из dry_run). Если она разошлась с предпросмотром чекаута, кнопка покажет ОБЕ суммы («… было N — банк пересчитал»), а спишется та, что на кнопке. Банк дважды пересчитывает корзину уже ПОСЛЕ кнопки (веб-корзина, затем доставка); расхождение с суммой на кнопке (допуск 0.01 ₽) отменяет чекаут ДО создания заказа. При неопределённом результате (заказ мог создаться) повтор БЛОКИРУЕТСЯ — сначала grocery_attempts() и проверь заказ в приложении. force=True — только если пользоват…

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

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

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 тогда не нужен. Отдельного эндпоинта удаления у банка нет: корзина всегда перезаписывается целиком, поэтому тул сам дочитывает текущий состав и шлёт полный список. Возвращает содержимое корзины ПОСЛЕ изменения — сверь его с ожидаемым. Количество выше остатка (countAvailable) тул НЕ принимает: отвечает CART_QUANTITY_CONFLICT с перечнем SKU и не пишет корзину. Молчаливого clamp'а до остатка нет — уменьшить или заменить решает пользователь.

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

Карточка отеля: адрес, время заезда, отзывы. С датами — ещё и тарифы: цена, питание, до какого числа бесплатная отмена. 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.