Loading ToolBench
BCS-MCP unified server and worker for market data, portfolio management, and trading operations with PostgreSQL backend and Python/Node.js components
BCS-MCP has 19 tools with explicitly defined schemas and descriptions in TypeScript/Zod format. However, critical issues emerge: (1) PARAMETER DESCRIPTIONS ARE MISSING, the Zod schemas visible in index.ts define types and constraints but NO description strings are attached to parameters. For example, market.fetch has 'table', 'columns', 'filters', 'range', 'limit', 'offset', 'order' parameters with type constraints but zero description text explaining what they do or when to use them. (2) OUTPUT SCHEMAS ARE NOT DOCUMENTED, no tool explicitly declares what fields it returns or what structure downstream tools should expect. (3) NAMING IS INCONSISTENT, 'market.fetch', 'private.fetch', 'bcs.signin' use both dot notation and verb_noun patterns, with some verbs ambiguous (e.g., 'market.compute' runs arbitrary scripts; unclear what 'compute' means). (4) ERROR HANDLING IS ABSENT, no evidence of actionable error messages, recovery guidance, or categorization (retryable vs fatal). (5) SECURITY CONCERNS, bcs.signin exposes login/password as tool parameters (pattern:secret-injection violation); credentials must never be parameters. (6) IRREVERSIBLE OPERATIONS LACK SAFEGUARDS, bcs.order.open creates real trades but has no dry-run, confirmation step, or explicit 'this is irreversible' warning in the description. Tools 12-14 (trading operations) are extremely high-risk. Despite clear schema structure, the lack of parameter descriptions and output documentation, combined with security vulnerabilities and missing error handling, places this in the D range.
Получить лимиты по кредитованию (своб. средства, маржин. требования, резерв).
Отменить открытую заявку по ID.
Открыть новую заявку (BUY/SELL).
Получить текущий портфель (позиции, кэш, маржинальные показатели).
Вход в систему BCS (получение токена).
Выход из системы BCS.
Проверка состояния сервера и баз данных
Получить вектор-эмбеддинг текста (используется для хранения в базе и семантического поиска).
CRITICAL: Credentials exposed as tool parameters, bcs.signin requires login and password parameters. Credentials must NEVER be exposed as parameters; use server-side secret injection via environment variables or secure vault. Agent traces log all parameters, causing credential leakage into logs and prompt history.
CRITICAL: Irreversible trading operation lacks safeguards, bcs.order.open creates real trades with IRREVERSIBLE risk. No dry-run mode, no confirmation step, no explicit 'this will execute immediately' warning in the tool description. An LLM mistake results in real financial loss. Add a confirmation_required parameter or split into bcs.order.preview + bcs.order.confirm.
HIGH: Parameter descriptions are missing, all 19 tools define Zod schemas with type constraints (enum, minLength, minimum, etc.) but the Zod objects lack .describe() annotations. JSON Schema generation produces schemas with only types, no human-readable descriptions. LLMs cannot infer parameter purpose from field names alone. E.g., market.fetch 'filters' parameter: what structure does it expect? What fields are valid? market.compute 'script': is this Python, JavaScript, or SQL? Undocumented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Получить рекомендацию по направлению (bullish/bearish) из моделей ML (ONNX, sklearn) с вероятностями.
Агрегировать временной ряд из bcs_market. Возвращает min/max/avg/sum/count по бакетам.
Выполнить скрипт над временным рядом из bcs_market (значения не выходят наружу).
Чтение рыночных данных из bcs_market. Поддерживает фильтры и диапазоны дат.
Получить последнюю запись из bcs_market с проверкой актуальности.
Получить справку по комиссиям и ограничениям на торговлю (брокер/биржа, маржина, сборы, сессии, API лимиты).
Агрегировать временной ряд из bcs_private (по дням, по часам).
Чтение приватных данных из bcs_private (портфель, заявки, сделки, лиц. счет).
Получить последнюю запись из bcs_private с проверкой актуальности.
Список доступных скриптов для вычисления индикаторов.
Выполнить скрипт и получить результат (индикаторы, сметы комиссий, анализ стакана).
HIGH: Output schemas not documented, no tool declares what it returns. E.g., market.fetch returns a list of records, but what fields does each record have? market.aggregate returns aggregated data, but what columns? bcs.portfolio.get returns portfolio state, but what's the structure? LLMs cannot chain tools without knowing output structure. No response examples or field documentation.
HIGH: Error handling is completely absent, no evidence of actionable error messages, recovery guidance, error classification (retryable vs fatal), or suggestions for next steps. When market.fetch fails, does it return a raw DB error? When policy.read can't find a key, is it 'not found' or a 500? LLMs receive no guidance on how to recover.
MEDIUM: Ambiguous tool names, 'market.compute' and 'private.compute' (if it exists) are vague. Does 'compute' mean aggregate, transform, validate, or execute arbitrary code? 'compute' alone does not clearly signal what happens. Rename to 'market.run_script', 'market.transform_timeseries', or similar. Similarly, 'policy.read' is passive; 'policy.fetch' or 'get_policy' is clearer.
MEDIUM: Inconsistent naming convention, tools use both dot notation ('market.fetch', 'bcs.signin') and natural verb_noun ('health'). While dot notation groups related tools, it conflicts with the Arcade pattern recommendation of verb_noun_object (get_market_data, search_trades). Standardize on one scheme.
MEDIUM: Pagination not clearly supported, market.fetch, market.latest, and private.* tools accept limit and offset, but it's unclear if they return total_count or next_cursor. When an LLM requests 'all instruments', does limit=10000 get them all or only a page? Add total_count to responses and document pagination in tool descriptions.
MEDIUM: Tool descriptions lack WHEN/WHY context, descriptions state WHAT (e.g., 'Чтение рыночных данных') but not WHEN to use each variant. When should an LLM call market.fetch vs market.latest? market.aggregate vs market.compute? The Russian descriptions do not guide tool selection. Add English, LLM-optimized descriptions that explain selection criteria.
MEDIUM: Dangerous default parameters, market.fetch, market.latest, and private.* lack explicit defaults for limit and offset. If limit defaults to a large value (e.g., 10000), a single query could exhaust memory. If limit defaults to 1, simple queries are useless. Document defaults and cap maximum limits (e.g., 10000 max).
LOW: Lack of tool annotations, no evidence of tool annotations (readOnlyHint, destructiveHint, idempotentHint) in the MCP schema. MCP 2026-07-28 supports risk annotations. bcs.order.open should be marked destructiveHint=true and idempotentHint=false. health and read tools should be marked readOnlyHint=true. This helps clients route calls appropriately.