Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@market-mcp Show me the current quote for SBER"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Локальный MCP-сервер, через который Claude получает данные Московской биржи (MOEX ISS) и брокерского счёта в Т-Инвестициях (T-Invest API). Сервер только читает данные: методов выставления заявок в коде нет.
Нужны Python 3.12+ и uv (pip install uv или winget install astral-sh.uv).
git clone <repo> C:\projects\market-mcp
cd C:\projects\market-mcp
uv sync
copy .env.example .env # при необходимости впишите TINVEST_TOKEN
uv run pytest # юнит-тесты на фикстурах, без сетиБез токена работают котировки, свечи, скринер, индексы и купоны через MOEX ISS с задержкой 15 минут. С токеном котировки идут в реальном времени, а ещё появляются стакан, дивиденды и (при ENABLE_PORTFOLIO=true) данные счёта.
Токен T-Invest: в приложении Т-Инвестиций откройте Настройки → Токены T-Invest API и выпустите токен «Только чтение». Для разработки можно включить TINVEST_SANDBOX=true.
Related MCP server: t-invest-mcp
Добавьте блок в %APPDATA%\Claude\claude_desktop_config.json и перезапустите Claude:
{
"mcpServers": {
"market": {
"command": "uv",
"args": ["--directory", "C:\\projects\\market-mcp", "run", "market-mcp"],
"env": { "TINVEST_TOKEN": "t.…", "ENABLE_PORTFOLIO": "true" }
}
}
}Если uv не находится, укажите полный путь к uv.exe (where uv). Токен можно не писать в конфиг: сервер читает .env из папки проекта.
Для Claude Code: claude mcp add market -- uv --directory C:\projects\market-mcp run market-mcp.
Инструмент | Параметры | Источник | Что возвращает |
|
| оба | Кандидаты: ticker, board, figi, secid, название, тип |
|
| T-Invest → ISS | Цена, изменение за день, объём, статус торгов |
|
| ISS / T-Invest | OHLCV, не больше 1000 за вызов |
|
| T-Invest | Стакан bids/asks |
|
| ISS | Бумаги режима торгов, не больше 500 строк |
|
| ISS | Текущее значение и история |
|
| T-Invest (купоны — и ISS) | Дивиденды или купоны с датами отсечки |
|
| T-Invest | Стоимость, доли классов, позиции, P&L |
|
| T-Invest | Сделки, комиссии, выплаты |
get_portfolio и get_operations не регистрируются, пока ENABLE_PORTFOLIO не равен true.
В ТЗ параметры периода названы from/to. В сервере это date_from/date_to: from — зарезервированное слово Python, а MCP SDK не умеет переименовывать аргументы.
{
"data": { "ticker": "SBER", "board": "TQBR", "price": "279.26", "change_day_pct": "-0.24",
"volume": 10617169, "currency": "RUB", "trading_status": "normal_trading" },
"source": "moex",
"as_of": "2026-09-17T10:06:23Z",
"stale": true,
"delay_minutes": 15
}Цены и суммы передаются строками, чтобы не терять точность Decimal. Все метки времени в UTC. Даты YYYY-MM-DD на входе считаются торговыми днями по Москве.
stale: true означает, что данные не в реальном времени (ISS). Вне торгов price — цена закрытия, а в ответе есть notice.code = "market_closed".
Цена облигации в price — рубли за бумагу с НКД. Цена в процентах от номинала лежит в price_pct_of_face.
Если ответ разбит на страницы, в нём есть next_cursor: передайте его в cursor следующего вызова.
Ошибка приходит как {"error": {"code", "message", "retriable"}}. Коды: instrument_not_found, ambiguous_instrument (+candidates), auth_failed, token_required, rate_limited (+retry_after_seconds), upstream_unavailable, portfolio_disabled, invalid_argument, account_not_found.
Переменная | Назначение | По умолчанию |
| Токен «только чтение» | — |
| Работа через песочницу |
|
| Регистрировать инструменты счёта |
|
| Базовый URL ISS |
|
| Файл SQLite-кэша |
|
| Уровень логов |
|
| Таймаут запроса, с |
|
src/market_mcp/
├─ server.py регистрация инструментов и запуск по stdio
├─ tools/ market.py, portfolio.py — схемы и описания инструментов
├─ app.py сборка зависимостей; ошибки превращаются в {"error": …}
├─ domain.py выбор источника, нормализация, кэш, постраничность
├─ providers/ moex.py (ISS), tinvest.py (REST-фасад, только методы чтения)
├─ mapping.py справочник ticker ↔ figi ↔ instrument_uid ↔ SECID в SQLite, обновление раз в сутки
├─ cache.py SQLite + TTL, ключ sha256(tool + аргументы)
├─ ratelimit.py token bucket (ISS 5 rps) и учёт квот T-Invest по x-ratelimit-*
├─ http.py общий httpx-клиент, 3 повтора (0.5 → 2 → 8 с) на сетевые ошибки, 429 и 5xx
├─ money.py Quotation / MoneyValue ↔ Decimal
├─ models.py Instrument, Quote, Candle, Position, коды ошибок, конверт ответа
└─ logging_setup.py JSON-логи только в stderr, токен вырезаетсяTTL кэша: справочник — 24 ч, свечи закрытых дней — бессрочно, свечи текущего дня — 60 с, котировки — 15 с, скринер — 5 мин. Портфель, операции и стакан не кэшируются, данные счёта в SQLite не пишутся.
Безопасность: токен передаётся только в заголовке Authorization, в логи, ошибки и ответы не попадает. Номера счетов маскируются до ****1234, и тот же формат принимается в account_id.
TLS: у T-Invest сертификат выдан российским удостоверяющим центром, поэтому httpx проверяет его по системному хранилищу сертификатов через truststore. Если T-Invest отвечает ошибкой TLS, установите в Windows корневой сертификат Минцифры.
uv run ruff check src tests
uv run mypy # strict
uv run pytest # фикстуры + respx, без сети
uv run pytest -m live # реальные API, запускать вручную
uv run python scripts/smoke.py # живой прогон всех рыночных инструментов через stdio
npx @modelcontextprotocol/inspector uv run market-mcpВ VS Code конфигурации из .vscode/launch.json запускают MCP Inspector, smoke-тест и pytest.
Главное правило: никаких print(). stdout занят протоколом MCP, а все логи пишутся через logging в stderr.
Найти биржевой инструмент по тикеру, названию или ISIN (Мосбиржа и справочник Т-Инвестиций).
Используй, когда пользователь называет компанию словами («Сбер», «Яндекс», «ОФЗ 26238»)
или когда другой инструмент вернул instrument_not_found / ambiguous_instrument.
Возвращает кандидатов с ticker, board, figi, secid, названием, типом и валютой.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Тип инструмента. | |
| limit | No | ||
| query | Yes | Тикер, название или ISIN. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, and non-destructive hints. The description adds that it returns a list of candidates with specific fields (ticker, board, figi, secid, name, type, currency), which is useful behavioral context. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that state purpose, usage triggers, and return fields. No fluff, and the most critical information (purpose) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, when to use, and what is returned. It doesn't mention pagination or disambiguation strategies, but the output schema likely covers return structure, and the tool's simplicity means these gaps are minor. It is sufficient for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides descriptions for query and kind, but limit has no description. The tool description does not add parameter-level detail beyond what the schema already says (e.g., query accepts ticker/name/ISIN). With 67% schema coverage, the description doesn't compensate for the missing limit semantics, but limit is a simple numeric bound so this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'найти' and the resource 'биржевой инструмент', specifying it searches by ticker, name, or ISIN. It also distinguishes itself from sibling tools by framing it as a lookup/fallback tool, not a data retrieval tool like get_quote or get_candles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when the user mentions a company by name or when another tool returns instrument_not_found / ambiguous_instrument. This gives clear conditions and implies the alternative (other tools) without naming them, which is sufficient for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Исторические свечи OHLCV от 1 минуты до месяца — для динамики цены, доходности за период, графиков.
Дневные, недельные и месячные свечи берутся с MOEX ISS без ограничения глубины;
внутридневные — из T-Invest, если есть токен. По умолчанию: день — последний год, внутри дня — сутки.
За один вызов не больше 1000 свечей: при next_cursor повтори запрос с cursor.
Время: дата YYYY-MM-DD для day/week/month, иначе UTC ISO 8601.
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | Режим торгов (class code): TQBR, TQCB, TQOB, TQTF, CETS, SPBFUT. Нужен только если тикер неоднозначен. | |
| cursor | No | next_cursor из предыдущего ответа для следующей страницы. | |
| ticker | Yes | Тикер или SECID: SBER, SU26238RMFS4, CNYRUB_TOM, IMOEX. | |
| date_to | No | Конец периода включительно: YYYY-MM-DD или ISO 8601. По умолчанию — сейчас. | |
| interval | No | Интервал свечи. | day |
| date_from | No | Начало периода: YYYY-MM-DD (дата торгов, МСК) или ISO 8601 в UTC. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, and the description adds substantial operational behavior beyond that: data source differences (MOEX ISS vs T-Invest), the 1000-candle pagination limit, default time ranges, and interval-specific date formats. This is exactly the kind of contextual behavior an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose first, then source behavior, pagination, and time conventions. The formatting is scannable and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with six parameters, the description covers all operationally critical details: intervals, data sources, token dependency, pagination, defaults, and date formatting. Since an output schema exists, return-value details are not required, and nothing essential for calling the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds valuable semantic context on top: default periods, the meaning of next_cursor for pagination, and the YYYY-MM-DD vs ISO 8601 distinction based on interval. This goes beyond the baseline without replacing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Исторические свечи OHLCV' (historical OHLCV candles) with a clear interval range from 1 minute to month. It also states concrete use cases — price dynamics, period returns, charts — and the 'historical' framing distinguishes it from sibling tools like get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: for price dynamics, period returns, and charts requiring historical candles. It does not explicitly name sibling alternatives or state when not to use it, so it falls short of a full 5, but the use-case framing is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Значение биржевого индекса Мосбиржи сейчас и, если задан период, дневная история закрытий.
Используй для сравнения доходности бумаги или портфеля с рынком (IMOEX, MCFTR — полной доходности).
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | next_cursor из предыдущего ответа для следующей страницы. | |
| date_to | No | Конец периода включительно: YYYY-MM-DD или ISO 8601. По умолчанию — сейчас. | |
| index_id | No | IMOEX, RTSI, MOEXBC, RGBI, MCFTR и т.п. | IMOEX |
| date_from | No | Начало периода: YYYY-MM-DD (дата торгов, МСК) или ISO 8601 в UTC. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description does not need to restate safety. The description adds valuable behavior: without a period it returns the current value, with a period it returns daily closes, and MCFTR is marked as total return. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core result, and the usage note adds direct value without any filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are rich, the description is sufficiently complete for correct invocation: it covers the main output, the period-dependent behavior, and a concrete use case. It does not mention pagination, but the schema documents the cursor parameter, so no critical gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented. The description adds a general behavior link (period triggers daily history) but gives no per-parameter detail beyond the schema. This matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Moscow Exchange index value now and, if a period is provided, daily closing history. It also names the intended use case (comparing a security/portfolio return to IMOEX/MCFTR), making the resource and outputs unambiguous. It does not explicitly contrast with sibling tools like get_candles or get_quote, but the index-specific scope is largely sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for comparing the yield of a security or portfolio against the market (IMOEX, MCFTR), giving clear context for when it is appropriate. It does not name alternatives or state when not to use it, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Биржевой стакан: лучшие заявки на покупку (bids) и продажу (asks) с количеством в лотах.
Нужен для оценки ликвидности и спреда. Требует токен T-Invest.
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | Режим торгов (class code): TQBR, TQCB, TQOB, TQTF, CETS, SPBFUT. Нужен только если тикер неоднозначен. | |
| depth | No | Глубина стакана. | |
| ticker | Yes | Тикер или SECID: SBER, SU26238RMFS4, CNYRUB_TOM, IMOEX. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive hints, so the bar for additional behavioral disclosure is lower. The description adds the token requirement (T-Invest), which is a critical prerequisite not covered by annotations. It also hints at output format (quantity in lots), though the output schema covers that. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose, followed by usage and auth requirement. No redundant or filler content; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers purpose, usage, and auth adequately. It does not mention edge cases or alternatives, but for a straightforward order book query, nothing critical is missing. The token requirement and liquidity/spread use case fill the main gaps beyond annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – all three parameters (ticker, board, depth) have descriptive text and examples. The tool description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool returns the exchange order book (best bids and asks) with quantity in lots, which clearly distinguishes it from siblings like get_quote (single price) and get_candles (historical data). It also includes the intended use case for liquidity and spread assessment, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool ('needed for assessing liquidity and spread'), but does not explicitly mention alternatives or exclusions. This is clear context without active routing to sibling tools, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Дивиденды по акции или купоны по облигации: суммы на одну бумагу, даты отсечки и выплаты.
По умолчанию — от года назад до года вперёд, включая объявленные будущие выплаты.
Дивиденды требуют токен T-Invest; купоны доступны и через MOEX ISS.
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | Режим торгов (class code): TQBR, TQCB, TQOB, TQTF, CETS, SPBFUT. Нужен только если тикер неоднозначен. | |
| ticker | Yes | Тикер или SECID: SBER, SU26238RMFS4, CNYRUB_TOM, IMOEX. | |
| date_to | No | Конец периода, по умолчанию год вперёд. | |
| date_from | No | Начало периода, по умолчанию год назад. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds the default date range, inclusion of future announced payments, and the token/ISS access nuance, which is valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and then add essential behavioral details. No fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and the description covering purpose, defaults, and access requirements, an agent has everything needed to correctly invoke the tool. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter clearly described (ticker, board, date_from, date_to). The description does not add extra meaning about parameters beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: retrieving dividends or coupons, specifying amounts per security, record dates, and payment dates. It uses a specific verb and resource, and clearly distinguishes this tool from sibling market data tools like get_quote or get_candles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on default time range (year back to year ahead) and access requirements (T-Invest token for dividends, MOEX ISS for coupons). It does not explicitly contrast with alternatives, but the purpose is unambiguous enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Текущая котировка бумаги: цена, изменение за день в %, объём, статус торгов.
Источник — T-Invest в реальном времени (если задан токен), иначе MOEX ISS с задержкой 15 минут
(stale: true). Вне торгов price — цена закрытия, в ответе notice.code = market_closed.
Для облигаций price — рублёвая цена одной бумаги с НКД, price_pct_of_face — цена в % от номинала.
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | Режим торгов (class code): TQBR, TQCB, TQOB, TQTF, CETS, SPBFUT. Нужен только если тикер неоднозначен. | |
| ticker | Yes | Тикер или SECID: SBER, SU26238RMFS4, CNYRUB_TOM, IMOEX. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotation, the description discloses fallback data sources, the stale flag, market-closed notice codes, and bond price semantics with NKD. This gives an agent important behavioral expectations that annotations alone do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the core purpose and result fields, then subsequent sentences add only high-value behavioral context: source, staleness, after-hours behavior, and bond pricing. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and read-only annotations are present, the description covers the key invocation contexts: real-time vs delayed, stale data, market-closed behavior, and bond-specific price interpretation. An agent has enough to call the tool correctly in normal and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents ticker and board adequately. The description adds no new parameter-level meaning; its extra details are mostly about output behavior, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('котировка бумаги') and the exact data returned: price, daily change percent, volume, and trading status. This clearly distinguishes it from siblings like get_candles or get_orderbook even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: real-time T-Invest when a token is set, otherwise 15-minute delayed MOEX ISS data, and after-hours behavior. It does not explicitly name alternative sibling tools or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Скринер всех бумаг режима торгов Мосбиржи с фильтрами и сортировкой.
Для вопросов «самые ликвидные акции», «кто сильнее всех упал сегодня», «ОФЗ с доходностью выше 15%».
Строки: secid, name, price, change_pct, volume, value_rub, capitalization; для облигаций ещё
yield_pct, duration_days, maturity. Данные ISS с задержкой 15 минут. Не больше 500 строк за вызов.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Поле сортировки. | value_rub |
| board | No | Режим торгов: TQBR — акции, TQTF — фонды, TQCB — корп. облигации, TQOB — ОФЗ, CETS — валюта, RFUD — фьючерсы. | TQBR |
| limit | No | ||
| order | No | desc | |
| cursor | No | next_cursor из предыдущего ответа для следующей страницы. | |
| filters | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it discloses the 15-minute data delay from ISS, the maximum of 500 rows per call, and the specific output columns for stocks vs bonds. This complements the readOnlyHint/openWorldHint annotations without contradicting them. It does not explain pagination behavior, but the schema already covers the cursor parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, front-loaded with purpose, followed by example use cases and key constraints. It earns its place with essential info, though it could be slightly more structured to separate purpose, output, and limits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 top-level params, nested filter object, output schema), the description provides key context: output columns, delay, row limit, and example scenarios. It covers most operational essentials, but the weak parameter semantics leave some gaps for an agent trying to craft precise filters without opening the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description needs to compensate for undocumented parameters like max_price, min_price, max_yield_pct, max_change_pct, limit, and order. The description only generically mentions 'filters and sorting' and lists output fields; it does not clarify units, inclusion of boundaries, or how these parameters behave. The schema's own descriptions cover some, but the main description adds little param-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('screener of all securities'), the resource (Moscow Exchange trading modes), and gives concrete example questions ('most liquid stocks', 'OFZ with yield above 15%') that clearly distinguish it from sibling tools like get_quote or get_candles. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context through example questions, implying when to use the tool for market-wide screening rather than single-instrument queries. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_instrumentget_candlesget_indexget_orderbookget_payoutsget_quotescreen_marketScored across 7 tools
Each tool targets a distinct purpose: instrument lookup, current quote, historical candles, order book, screening, index data, and payouts. There is no meaningful overlap; even get_quote and get_candles are clearly separated by real-time vs historical scope.
All tool names follow a snake_case verb_noun pattern: find_instrument, get_quote, get_candles, get_orderbook, screen_market, get_index, get_payouts. The verbs (find/get/screen) are distinct and consistent with each tool's action, and the overall pattern is uniform.
Seven tools is well within the ideal range for a market-data server. Each tool covers a necessary data type without redundancy, making the set feel complete yet focused.
The surface covers the core market-data lifecycle: searching instruments, current quotes, historical candles, order book depth, market screening, index comparison, and dividend/coupon payouts. No obvious missing operations for the stated domain.
Agentic brokerage access to a US brokerage account: quotes, orders, positions, cash and documents.
Trade journal plus read-only market, research, and brokerage data tools for external AI clients.
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
Connect your portfolio to Claude, ChatGPT, or Codex to analyze it and make smarter investments.
