Независимый, детерминированный сервис утреннего обзора A-акций. Он не зависит от AlphaAgent, XQ, внутренних баз данных или LLM Key и предоставляет существующий MorningBriefService через стандартный MCP stdio transport, сохраняя при этом обычный способ вызова из Python.
Сервис предоставляет 4 инструмента MCP:
generate_morning_brief(target_date=None, output_format="json"|"markdown"): генерирует полный утренний обзор.
get_morning_news(target_date=None, categories=None, limit_per_category=5): возвращает события после фильтрации по окну, дедупликации, кластеризации, классификации и сортировки по релевантности.
get_previous_close_context(target_date=None): возвращает рыночный контекст A-акций за предыдущий торговый день, соответствующий данному утреннему обзору.
get_news_coverage(target_date=None): возвращает статус новостных провайдеров, роли, метрики и покрытие без исходных payload и учётных данных.
Все инструменты ориентированы на подтверждённый целевой торговый день A-акций; результат — детерминированная сводка доказательств из источников и не является инвестиционной рекомендацией.
Related MCP server: go-stock-mcp
Python 3.11+
MCP Python SDK >=2.0.0,<3 (текущая стабильная версия для приёмки: 2.0.0)
HITHINK_FINANCE_API_KEY (для торгового календаря и рыночного контекста предыдущего торгового дня)
Новости для утреннего обзора берутся напрямую из публичных финансовых веб-провайдеров Китая; Brave Key не требуется. Не коммитьте реальный .env:
$env:HITHINK_FINANCE_API_KEY="your-key"python -m venv .venv
# Windows
.venv\Scripts\python -m pip install -e ".[test]"
# macOS/Linux
.venv/bin/python -m pip install -e ".[test]"from morning_brief_mcp.renderers.markdown import render_markdown
from morning_brief_mcp.services.morning_brief import MorningBriefService
service = MorningBriefService()
try:
report = service.generate("2026-08-17")
markdown = render_markdown(report)
finally:
service.close()После установки запустите напрямую:
morning-brief-mcpТакже можно использовать универсальную конфигурацию клиента command + args + env:
{
"mcpServers": {
"morning-brief-mcp": {
"command": "python",
"args": ["-m", "morning_brief_mcp.server"],
"env": {
"HITHINK_FINANCE_API_KEY": "${HITHINK_FINANCE_API_KEY}"
}
}
}
}target_date должен строго использовать формат YYYY-MM-DD. Если он опущен, используется текущая дата в Asia/Shanghai, после чего она всё равно проверяется по торговому календарю HiThink; для неторгового дня возвращается target_not_trading_day, без тихой подмены даты.
Ошибки даты, параметров, конфигурации и вышестоящего сервиса возвращаются в стабильных структурах invalid_request, target_not_trading_day, provider_unavailable или upstream_error соответственно. status="partial" в бизнес-отчёте по-прежнему является успешным результатом инструмента — например, когда один источник новостей недоступен, но остальных данных достаточно для формирования утреннего обзора. stdio-сервер не выводит отладочную информацию в stdout; stdout используется только для протокола MCP.
По умолчанию обнаружение новостей напрямую обращается к публичным веб-интерфейсам китайских финансовых сайтов:
Provider | Роль | Исторические возможности | Tier |
财联社 CLS | primary |
| 2 |
东方财富 7×24 | primary |
| 2 |
华尔街见闻 | primary |
| 2 |
金十 | supplemental |
| 2 |
MKTNews | supplemental |
| 3 |
东方财富个股新闻 | supplemental |
| 2 |
巨潮公告 | supplemental |
| 1 |
Если по крайней мере два primary-провайдера с разных upstream-доменов реально дошли до news_window.start, GDELT в этом цикле не вызывается. GDELT используется только как последний запасной вариант, когда покрытие полного окна недостаточно; успех в режиме latest-only не засчитывается как покрытие полного окна.
HiThink отвечает только за торговый календарь, предыдущий торговый день и рыночный контекст previous-close и не участвует в обнаружении новостей.
Окно утреннего обзора фиксировано: с 15:00 предыдущего торгового дня до 08:30 целевого торгового дня, часовой пояс Asia/Shanghai, обе границы включительно.
Все провайдеры сначала отображаются в единые поля:
id、title、url、canonical_url、source、domain、
published_at、description、language、category、tags、
source_tier、provider、raw_source_id.
Затем продолжается существующий детерминированный конвейер:
exact time filter → canonicalize → dedup/event cluster → classify → relevance → today_watch
Многоисточниковые сообщения об одном и том же событии отображаются одним кластером, сохраняя related_sources и related_count. Представительный элемент определяется по Tier, времени и полноте информации. В description сохраняется только реальный brief/summary/content snippet/hover от источника, без программного расширения.
Каждый домен использует общую HTTP-сессию и rate limiter. Запросы имеют timeout, ограниченное количество повторов, Retry-After, экспоненциальную задержку и джиттер. 东方财富 по умолчанию выполняется последовательно с минимальным интервалом 1 секунда. Сбой одного провайдера фиксируется только в его status, warning и metrics и не блокирует других провайдеров.
Пагинация ограничена DOMESTIC_MAX_PAGES и DOMESTIC_MAX_ITEMS. Каждый провайдер записывает количество страниц, исходное количество элементов, самое старое время, причину остановки и счётчики HTTP request/429/403/retry.
API-ключ читается только из переменной окружения; он не становится параметром инструмента и не появляется в описании инструмента, логах, schema или MCP result. Диагностические инструменты не возвращают заголовки запросов, полные upstream payload, предварительно подписанные URL или внутренние секреты.
По умолчанию тесты полностью офлайн, всё HTTP-поведение использует fixtures/MockTransport:
PYTHONPATH=src python -m pytestПосле настройки HiThink Key можно запустить реальный smoke в дочернем процессе с помощью официального MCP Python client и сравнить ключевые поля Service и MCP:
python scripts/stdio_smoke.pyЭти провайдеры используют публичные веб-интерфейсы только для обнаружения данных и агрегации ссылок. Лицензия открытой реализации не равна лицензии на контент вышестоящих новостных источников; перед производственным или коммерческим развёртыванием пользователь должен самостоятельно проверить условия обслуживания, политику парсинга и лицензии на использование контента каждого вышестоящего источника. Справочная реализация и сведения о лицензиях приведены в THIRD_PARTY_NOTICES.md.
Сервис предназначен для систематизации рыночной информации и исследований и не является инвестиционной рекомендацией.
Generate a deterministic A-share morning brief for a confirmed target trading date; source evidence only, not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| target_date | No | ||
| output_format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses meaningful traits: determinism, evidence-only sourcing, and non-advisory status. It does not cover edge behaviors or failure modes, but for a non-destructive briefing generator the key expectations are clearly set.
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?
A single front-loaded sentence with no filler; every qualifier ('deterministic', 'confirmed target trading date', 'source evidence only, not investment advice') adds valuable scoping.
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 tool is simple with two optional parameters and an output schema present, so the description is largely sufficient for invoking it. The main gap is what happens when target_date is null/defaulted, but this is inferable from the schema default and context.
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 0% and the description only gestures at target_date via 'confirmed target trading date', adding no format or explicit meaning for output_format beyond what the enum/default already provide. This is insufficient compensation for the absence of schema-level descriptions.
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?
States a specific verb and resource ('Generate a deterministic A-share morning brief') and identifies the target date as a confirmed trading date. This clearly distinguishes the tool from the raw-data siblings like get_morning_news and get_news_coverage.
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 implies the tool is for producing a morning brief on a confirmed trading date, but it does not explicitly say when to prefer this over the sibling tools or exclude other use cases. The usage context is present but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get deterministic clustered and ranked A-share morning news events for a target trading date; never raw upstream feeds or investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| categories | No | ||
| target_date | No | ||
| limit_per_category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful non-obvious traits: deterministic, clustered/ranked, and not raw upstream feeds or investment advice. However, it does not mention behavior around missing dates, default category handling, or what happens when no news exists, leaving those to be inferred.
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 a single sentence with no filler, and the key distinguishing traits (deterministic, clustered, ranked, A-share, not raw) are front-loaded. Every phrase 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 zero annotations and zero schema descriptions, the description should compensate with parameter and usage guidance, but it only covers the tool's purpose and processing nature. The output schema may describe return values, but invocation context and sibling differentiation remain incomplete for an agent.
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 0%, so the description must compensate, but it only hints at target_date via 'target trading date'. Categories and limit_per_category receive no explanation, leaving their formats and semantics unclear beyond the parameter names and defaults.
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 has a specific verb ('Get'), a specific resource ('deterministic clustered and ranked A-share morning news events'), and a clear scope ('for a target trading date'). It also distinguishes itself from raw upstream feeds, which helps separate it from the sibling get_news_coverage.
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 implies when to use the tool (when deterministic A-share morning news events are needed for a target date), but it does not explicitly name alternatives or state conditions for choosing this tool over siblings like generate_morning_brief or get_news_coverage. The exclusion of raw feeds/advice is about output boundaries, not about when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose deterministic domestic A-share morning-news coverage for a target trading date without exposing raw payloads, headers or secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| target_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that the tool is deterministic and does not expose raw payloads, headers, or secrets, which gives agents a meaningful safety boundary. However, it does not explicitly state whether this is read-only, whether it has side effects, or what other operational constraints apply.
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 a single, dense sentence with no filler. The primary action, target resource, and a key constraint are all present. It is concise and front-loaded, though it could be slightly clearer about parameter usage and sibling differentiation.
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?
An output schema exists, so return-value details are not required from the description. The description states the core purpose and a key security boundary, but for a tool with no annotations and ambiguous sibling overlap, it lacks usage conditions and explicit alternative routing. It is adequate but leaves meaningful 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 description coverage is 0%, so the description must compensate. It does tie the parameter to a 'target trading date' and gives A-share context, which is helpful. But it does not explain the expected date format, how null is handled, or how the parameter influences the deterministic coverage diagnosis. The parameter meaning is only partially conveyed.
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 uses a specific verb ('diagnose') with a clear resource ('domestic A-share morning-news coverage') and a target trading date. It also adds a distinguishing security constraint ('without exposing raw payloads, headers or secrets'). However, it does not explicitly differentiate from sibling tools such as get_morning_news, so differentiation is implicit rather than direct.
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?
There is no guidance about when to use this tool versus get_morning_news, generate_morning_brief, or get_previous_close_context. The phrase 'diagnose deterministic coverage' implies an investigative or audit-like use case, but no explicit conditions, exclusions, or alternative selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get deterministic HiThink previous-close A-share market context for a confirmed target trading date; not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| target_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by calling the result 'deterministic' and scoping the data source/region, but it does not describe side effects, input validation behavior, or what happens when target_date is null or non-trading.
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?
A single front-loaded sentence that names the action, scope, and source without excess. The trailing 'not investment advice' is compliance boilerplate but does not make the description bloated.
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 one-parameter read-style tool with an output schema, this is minimally adequate for selection, but it leaves important gaps: parameter format/null behavior and when to prefer sibling tools. More explicit usage guidance would make it fully complete.
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 0%, so the description must compensate, but it only echoes 'target trading date' without specifying the expected date format or the meaning of null/default. An agent cannot confidently construct the target_date parameter from the description alone.
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?
States a specific verb ('Get') and a narrowly scoped resource: 'HiThink previous-close A-share market context' for a 'confirmed target trading date.' This clearly differentiates it from the sibling news/brief tools, so an agent can select it without opening the schema.
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?
Implies when to use it: when previous-close A-share context for a confirmed target trading date is needed. However, it does not explicitly state when not to use it or name alternatives among the sibling tools, leaving some selection judgment to the agent.
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.
v1.0.0generate_morning_briefget_morning_newsget_news_coverageget_previous_close_contextScored across 4 tools
Each tool has a distinct role: generating the brief, fetching news events, retrieving previous-close context, and diagnosing news coverage. No two tools appear to target the same resource or action.
Three tools follow a clear get_<noun> pattern, while generate_morning_brief uses a different verb. The deviation is minor and the names remain predictable and readable.
Four tools is well-scoped for a focused morning-brief server. Each tool serves a clear purpose in the brief-generation workflow without unnecessary overlap.
The server covers the full workflow: generating the brief, retrieving source news, retrieving market context, and diagnosing coverage issues. There are no obvious dead ends or missing operations for its stated purpose.
China A-share market data for research, backtesting and AI agents via MCP.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
Daily A-share market brief with LG phase signals. No auth required.
China A-share market data over MCP: 22 tools for quotes, K-line, financials, money flow, top-trader boards, sectors, macro, convertible bonds and factor screening. Five tools need no API key, so you can connect and try it immediately.
