独立した決定論的なA株モーニングブリーフサービスです。AlphaAgent、XQ、内部データベース、LLM Keyには依存せず、
標準のMCP stdio transportを介して既存のMorningBriefServiceを公開し、通常の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)：ニュースプロバイダーのステータス、ロール、メトリクス、カバレッジを返します。生のペイロードや認証情報は含みません。
すべてのツールは確認済みのA株対象営業日を対象としており、結果は決定論的なソースエビデンスの整理であり、投資アドバイスを構成するものではありません。
Related MCP server: go-stock-mcp
Python 3.11+
MCP Python SDK >=2.0.0,<3（現在の受け入れ安定版：2.0.0）
HITHINK_FINANCE_API_KEY（取引カレンダーと前営業日の市場背景用）
モーニングブリーフのニュースは国内の公開金融Webプロバイダーから直接取得され、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プロトコルのみを運びます。
ニュース発見はデフォルトで国内金融サイトの公開Webインターフェースに直接アクセスします：
Provider | ロール | 履歴機能 | Tier |
财联社 CLS | primary |
| 2 |
东方财富 7×24 | primary |
| 2 |
华尔街见闻 | primary |
| 2 |
金十 | supplemental |
| 2 |
MKTNews | supplemental |
| 3 |
东方财富个股新闻 | supplemental |
| 2 |
巨潮公告 | supplemental |
| 1 |
少なくとも2つの異なるupstreamドメインのprimaryプロバイダーが実際に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。
その後、既存のdeterministicパイプラインを続行します：
exact time filter → canonicalize → dedup/event cluster → classify → relevance → today_watch
同一イベントのマルチソース報道は1つのクラスタのみを表示し、related_sources と
related_count を保持します。代表項目はTier、時間、情報の完全性によって決定されます。descriptionは上流の実際のbrief/summary/content snippet/hoverのみを保存し、プログラムによる拡張は行いません。
各ドメインはHTTPセッションとレートリミッターを共有します。リクエストにはtimeout、有界リトライ、
Retry-After、指数バックオフ、ジッターがあります。东方财富はデフォルトで直列かつ最小間隔1秒です。単一のプロバイダー
障害はそのstatus、warning、metricsのみを記録し、他のプロバイダーをブロックしません。
ページングはすべてDOMESTIC_MAX_PAGESとDOMESTIC_MAX_ITEMSによって制限されます。各プロバイダーは
ページ数、生データ件数、最古時刻、停止理由、HTTP request/429/403/retryカウントを記録します。
API Keyは環境変数からのみ読み取られます；ツールパラメータにはならず、ツールの説明、 ログ、schema、MCP resultにも表示されません。診断ツールはリクエストHeader、完全なupstream payload、 事前署名URL、内部secretを返しません。
デフォルトのテストは完全にオフラインで、すべてのHTTP動作はfixtures/MockTransportを使用します：
PYTHONPATH=src python -m pytestHiThink Keyを設定した後、公式MCP Pythonクライアントを使用して実際のサブプロセススモークテストを実行し、 ServiceとMCPの主要フィールドを比較できます：
python scripts/stdio_smoke.pyこれらのプロバイダーは公開Webインターフェースを使用し、データ発見とリンク集約のみを目的としています。オープンソース実装のライセンスは
上流のニュースコンテンツのライセンスとは異なります；本番環境または商用デプロイの前に、利用者は各上流サービスの利用規約、
スクレイピングポリシー、コンテンツ使用ライセンスを自ら確認する必要があります。参考実装とライセンス記録は
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.
