FinamMCP presents a mixed quality picture. The server has 17 tools across 4 domains (account, assets, market_data, order) with reasonable naming conventions (all start with action verbs like get_, place_, cancel_). However, significant gaps exist in parameter descriptions and output schema documentation. Most tools have descriptions in Russian (10-200 chars range, within baseline), but parameter documentation is inconsistent. Critical issue: The 'place_order' tool accepts an 'order' parameter with only vague description ('Order object containing symbol, quantity, side, type, and optional parameters'), no formal schema visible for the nested object structure. Output schemas are not documented anywhere in the codebase provided. Error handling is not evident. The server supports HTTP transport (good) and uses fastmcp framework, but lacks modern MCP features like tool annotations, error reporting, and structured logging.
Отмена биржевой заявки
Получение информации по конкретному счету (статус и тип аккаунта, доступные средства, дневная прибыль, открытые позиции (количество, средняя цена, прибыль/убыток), тип портфеля)
Получение информации по конкретному инструменту (лот, шаг цены, дата экспирации фьючерса)
Получение списка доступных инструментов, их описание (символы, наименование)
Получение исторических данных по инструменту (агрегированные свечи)
Получение списка доступных бирж, включая их названия и MIC-коды
place_order tool has critically underdocumented nested parameter. The 'order' parameter description states only 'Order object containing symbol, quantity, side, type, and optional parameters' with no formal schema definition visible. This violates the constrained-input pattern and forces LLMs to guess the exact structure, field types, and allowed values.
No output/return schemas documented for any tool. The rubric requires documented output schemas so LLMs know what fields to expect and can chain tool calls. This affects all 17 tools. Code inspection shows tool implementations exist but their return structures are not formalized in the tool definitions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
получение последней котировки инструмента (цена покупки/продажи, цена открытия/закрытия, цена последней сделки, дневной объем сделок, объем покупки/продажи)
Получение списка последних сделок по инструменту
Получение цепочки опционов для базового актива
Получение информации о конкретном ордере
Получение текущего стакана по инструменту
Получение списка заявок для аккаунта
Получение торговых параметров по инструменту (операции лонг/шорт, гарантийное обеспечение, ставки риска)
Получение расписания торгов для указанного инструмента
Получение истории по сделкам аккаунта
Получение списка транзакций аккаунта
Выставление биржевой заявки
Pagination parameters and output limits not documented for list-returning tools. get_transactions, get_trades, get_bars, get_last_trades accept 'limit' but no documentation of pagination strategy (offset, cursor, or total count). Returns with hundreds of items could exhaust context windows.
No error handling guidance in tool descriptions. Critical for financial APIs where errors are common (invalid symbols, insufficient permissions, market closed). Tools like place_order and cancel_order perform state-changing operations but offer no recovery hints in descriptions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares place_order as WRITE and cancel_order as REVERSIBLE but provides no formal MCP annotations. This prevents clients from understanding operation semantics automatically.
get_bars timeframe parameter lacks enum definition or format constraint. Description states only 'TimeFrame enum value' without listing valid options (e.g., 1m, 5m, 1h, 1d, etc.). LLMs cannot infer valid values.
All descriptions are in Russian, reducing accessibility for English-language LLMs and agents. While technically valid, descriptions like 'Получение информации по конкретному счету' will not parse as naturally for English prompts.
Symbol parameter validation uses regex pattern '^[A-Za-z0-9._-]+@[A-Z_]+$' but description lacks clarification of format. Should state: 'Symbol in format TICKER@MIC (e.g., YDEX@MISX, SBER@TQBR). Ticker may contain letters, digits, dots, hyphens. MIC code is uppercase with optional underscores.'
No documentation of required credentials or authentication model. Middleware shows FinamCredentialsMiddleware but tool descriptions do not explain how to authenticate or what tokens are needed.
place_order lacks confirmation/dry-run pattern for an irreversible financial operation. Should offer a 'dry_run' parameter or separate validate_order tool so agents can preview before executing.