독립적이고 결정론적인 A주 모닝브리핑 서비스입니다. AlphaAgent, XQ, 내부 데이터베이스 또는 LLM Key에 의존하지 않으며, 표준 MCP stdio transport를 통해 기존 MorningBriefService를 노출하면서 일반 Python 호출 방식도 유지합니다.
서비스는 4개의 MCP tools를 노출합니다:
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): 뉴스 provider 상태, 역할, 지표 및 커버리지를 반환하며, 원본 payload 또는 인증 정보는 포함하지 않습니다.
모든 tool은 확정된 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 provider에서 직접 가져오며, 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"는, 단일 뉴스 소스가 실패해도 다른 데이터로 모닝브리핑을 생성하기에 충분한 경우처럼, 여전히 성공적인 tool result입니다. stdio server는 stdout에 디버그 정보를 출력하지 않습니다. stdout은 MCP protocol만 전달합니다.
뉴스 발견은 기본적으로 중국 내 금융 사이트의 공개 Web 인터페이스에 직접 접근합니다:
Provider | 역할 | 과거 커버리지 능력 | Tier |
财联社 CLS | primary |
| 2 |
东方财富 7×24 | primary |
| 2 |
华尔街见闻 | primary |
| 2 |
金十 | supplemental |
| 2 |
MKTNews | supplemental |
| 3 |
东方财富个股新闻 | supplemental |
| 2 |
巨潮公告 | supplemental |
| 1 |
서로 다른 upstream domain의 primary provider 중 최소 두 개가 실제로 news_window.start까지 페이지를 넘기면 이번 라운드에서는 GDELT를 호출하지 않습니다. 전체 창 커버리지가 부족한 경우에만 GDELT를 최후의 fallback으로 사용합니다. latest-only 성공은 전체 창 커버리지로 계산되지 않습니다.
HiThink는 거래일 달력, 직전 거래일 및 previous-close 시장 배경만 담당하며 뉴스 발견에는 참여하지 않습니다.
모닝브리핑 윈도우는 직전 거래일 15:00부터 목표 거래일 08:30까지로 고정되며, 시간대는 Asia/Shanghai이고 두 경계를 모두 포함합니다. 모든 provider는 먼저 통일된 필드로 매핑됩니다:
id, title, url, canonical_url, source, domain, published_at, description, language, category, tags, source_tier, provider, raw_source_id.
이후 기존 deterministic pipeline을 계속 진행합니다:
exact time filter → canonicalize → dedup/event cluster → classify → relevance → today_watch
동일 이벤트의 다중 소스 보도는 하나의 cluster만 표시하며, related_sources 및 related_count를 유지합니다. 대표 항목은 Tier, 시간, 정보 완전성에 따라 결정됩니다. description은 업스트림의 실제 brief/summary/content snippet/hover만 저장하며 프로그램적으로 확장하지 않습니다.
각 domain은 하나의 HTTP session과 rate limiter를 공유합니다. 요청에는 timeout, 제한된 재시도, Retry-After, 지수 백오프 및 지터가 적용됩니다. 东方财富는 기본적으로 직렬로 처리되며 최소 간격은 1초입니다. 단일 provider의 실패는 해당 status, warning 및 metrics만 기록하며 다른 provider를 차단하지 않습니다.
페이지네이션은 모두 DOMESTIC_MAX_PAGES 및 DOMESTIC_MAX_ITEMS로 제한됩니다. 각 provider는 페이지 수, 원본 항목 수, 가장 오래된 시간, 중지 사유 및 HTTP request/429/403/retry 횟수를 기록합니다.
API Key는 환경 변수에서만 읽습니다. tool 매개변수가 되지 않으며 tool description, 로그, schema 또는 MCP result에도 나타나지 않습니다. 진단 tool은 요청 Header, 전체 upstream payload, 사전 서명된 URL 또는 내부 secret을 반환하지 않습니다.
기본 테스트는 완전히 오프라인이며, 모든 HTTP 동작은 fixtures/MockTransport를 사용합니다:
PYTHONPATH=src python -m pytestHiThink Key를 구성한 후 공식 MCP Python client로 실제 하위 프로세스 smoke를 실행하고 Service와 MCP의 주요 필드를 비교할 수 있습니다:
python scripts/stdio_smoke.py이러한 provider는 공개 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.
