Skip to main content
Glama
Sign In
T-Bank Invest MCP Server (read-only)

T-Bank Invest MCP Server (read-only)

by Sicness
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_operations_by_cursor

Read-only

Retrieve account operations with cursor-based pagination for large histories. Use returned nextCursor to fetch the next page; hasNext shows if more results exist.

Instructions

Get operations with cursor-based pagination. Better for large histories.

Returns hasNext and nextCursor for pagination: pass nextCursor as cursor to get the next page. Each operation item includes detailed info: id, type (the code, e.g. OPERATION_TYPE_BUY), name and description, state, date, payment, price, commission, yield, accruedInt, quantity, quantityDone, quantityRest, ticker, classCode, figi, instrumentType, instrumentUid, positionUid, tradesInfo.trades (the trades of the order) and childOperations (its commissions and taxes). A field that is zero or empty is left out, and so are fields that repeat another one or the request (instrumentKind, assetUid, brokerAccountId, the per-item cursor).

Canceled orders are operations as well, and carry the quantity and the payment they asked for — a canceled buy with a positive payment, where an executed one is negative: pass state="EXECUTED" before adding up money or quantities. quantity is what the order asked for, quantityDone what was executed (left out when nothing was) and quantityRest what was not — an order can be executed in part. A bond repayment has no quantity. Prices and quantities are as they were at the time: unlike candles, they are not adjusted for later splits. positionUid is the key of a position: one paper can come under several figi and instrumentUid. The API can send an operation twice under one id; within a page the two are merged, across pages add up by unique id.

Common operation types: BUY, SELL, DIVIDEND, COUPON, TAX, BOND_TAX, INPUT, OUTPUT, BROKER_FEE, BOND_REPAYMENT_FULL, BOND_REPAYMENT; DIV_EXT is a dividend paid out to a card, which never reaches the account.

Args: account_id: Account ID from_date: Start date (YYYY-MM-DD), default: 1 year ago to_date: End date (YYYY-MM-DD, inclusive), default: now cursor: Cursor from previous response for pagination limit: Number of operations per page (1-1000, default: 50; a page of 50 is about 28,000 characters, and a client refuses a result twice that) instrument_id: Filter by instrument — ticker, FIGI, ISIN or UID operation_types: Comma-separated operation types (e.g. "BUY,SELL,DIVIDEND"); a type the API does not have is an error state: Filter by state: EXECUTED, CANCELED, PROGRESS without_commissions: Exclude commission operations without_trades: Exclude trade details from response

Input Schema

NameRequiredDescriptionDefault
limitNo
stateNo
cursorNo
to_dateNo
from_dateNo
account_idYes
instrument_idNo
without_tradesNo
operation_typesNo
without_commissionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly/openWorld, but the description discloses rich behavior: zero/empty fields are omitted, duplicate operations under one id are merged within a page, canceled orders carry positive payment while executed are negative, prices are not split-adjusted, and partially executed orders split quantity/quantityDone/quantityRest. This is far beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the pagination contract, then Args, then return-value semantics. It is long and dense, but nearly every sentence adds distinct value; the volume is justified by the missing output schema and the complex domain, with only minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully specifies return fields (id, type, state, date, payment, price, commission, yield, quantities, childOperations, tradesInfo, etc.), pagination contract, and operation-type enumeration. An agent has everything needed to call and interpret it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden and does so: it documents every Arg including formats (YYYY-MM-DD), defaults (1 year ago, 50, now), ranges (1-1000), the ~28,000-char payload note, filter semantics for instrument_id/operation_types/state, and the error case for unknown types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (get operations) and identifies the distinguishing trait (cursor-based pagination, better for large histories). It clearly differentiates from get_operations by pagination style, though it never names the sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Better for large histories' gives a clear selection condition against the sibling get_operations, and it adds actionable usage notes (pass state="EXECUTED" before summing money). It stops short of explicitly naming the alternative or stating when-not-to-use, so it falls under a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools