Click on "Install 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., "@morning-brief-mcp What's in today's morning brief?"
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.
An independent, deterministic A-share morning brief service. It does not rely on AlphaAgent, XQ, internal databases, or LLM Key, and exposes the existing MorningBriefService through the standard MCP stdio transport while retaining the normal Python invocation method.
The service exposes 4 MCP tools:
generate_morning_brief(target_date=None, output_format="json"|"markdown"): Generate a complete morning brief.
get_morning_news(target_date=None, categories=None, limit_per_category=5): Return events after window filtering, deduplication, clustering, classification, and relevance ranking.
get_previous_close_context(target_date=None): Return the A-share market context of the previous trading day corresponding to this morning brief.
get_news_coverage(target_date=None): Return news provider status, roles, metrics, and coverage, without raw payloads or authentication information.
All tools target a confirmed A-share target trading day; the results are deterministic compilations of source evidence and do not constitute investment advice.
Related MCP server: cn-financial-mcp
Python 3.11+
MCP Python SDK >=2.0.0,<3 (currently accepted stable version: 2.0.0)
HITHINK_FINANCE_API_KEY (used for the trading calendar and previous trading day market context)
Morning brief news comes directly from domestic public financial web providers; no Brave Key is needed. Do not commit real .env files:
$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()Start directly after installation:
morning-brief-mcpYou can also use the generic command + args + env client configuration:
{
"mcpServers": {
"morning-brief-mcp": {
"command": "python",
"args": ["-m", "morning_brief_mcp.server"],
"env": {
"HITHINK_FINANCE_API_KEY": "${HITHINK_FINANCE_API_KEY}"
}
}
}
}target_date must strictly use YYYY-MM-DD. When omitted, the current date in Asia/Shanghai is used, and is then still verified by the HiThink trading calendar; non-trading days return target_not_trading_day and the date is not silently changed.
Date, parameter, configuration, and upstream errors return stable invalid_request, target_not_trading_day, provider_unavailable, or upstream_error structures, respectively. A business report with status="partial" is still a successful tool result, for example when a single news source fails but other data is sufficient to generate the morning brief. The stdio server does not print debug information to stdout; stdout only carries the MCP protocol.
News discovery directly accesses the public web interfaces of domestic financial sites by default:
Provider | Role | Historical capability | Tier |
财联社 CLS | primary |
| 2 |
东方财富 7×24 | primary |
| 2 |
华尔街见闻 | primary |
| 2 |
金十 | supplemental |
| 2 |
MKTNews | supplemental |
| 3 |
东方财富个股新闻 | supplemental |
| 2 |
巨潮公告 | supplemental |
| 1 |
As long as at least two primary providers from different upstream domains actually paginate to news_window.start, GDELT will not be called in this round. Only when full-window coverage is insufficient is GDELT used as a last fallback; latest-only success is not counted as full-window coverage.
HiThink is only responsible for the trading calendar, the previous trading day, and previous-close market context; it does not participate in news discovery.
The morning brief window is fixed from 15:00 of the previous trading day to 08:30 of the target trading day, in the Asia/Shanghai timezone, with both boundaries inclusive. All providers are first mapped to the unified fields:
id, title, url, canonical_url, source, domain,
published_at, description, language, category, tags,
source_tier, provider, raw_source_id.
Then it continues through the existing deterministic pipeline:
exact time filter → canonicalize → dedup/event cluster → classify → relevance → today_watch
Multi-source reports of the same event display only one cluster, while retaining related_sources and related_count. The representative item is determined by Tier, time, and information completeness. The description stores only the upstream real brief/summary/content snippet/hover, without programmatic expansion.
Each domain shares one HTTP session and a rate limiter. Requests have timeout, bounded retries, Retry-After, exponential backoff, and jitter. 东方财富 defaults to serial execution with a minimum interval of 1 second. A single provider failure only records its status, warning, and metrics, and does not block other providers.
Pagination is limited by DOMESTIC_MAX_PAGES and DOMESTIC_MAX_ITEMS. Each provider records page count, raw item count, oldest time, stop reason, and HTTP request/429/403/retry counts.
The API Key is read only from environment variables; it never becomes a tool parameter and never appears in tool descriptions, logs, schema, or MCP results. Diagnostic tools do not return request headers, full upstream payloads, pre-signed URLs, or internal secrets.
Default tests are completely offline; all HTTP behavior uses fixtures/MockTransport:
PYTHONPATH=src python -m pytestAfter configuring the HiThink Key, you can use the official MCP Python client to run a real subprocess smoke and compare key Service and MCP fields:
python scripts/stdio_smoke.pyThese providers use public web interfaces solely for data discovery and link aggregation. The open-source implementation license is not equivalent to the upstream news content license; before production or commercial deployment, users must independently confirm each upstream's terms of service, crawling policy, and content usage license. See THIRD_PARTY_NOTICES.md for the reference implementation and license records.
This service is for market information organization and research and does not constitute investment advice.
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. Dates show when Glama detected each change.
v1.0.0generate_morning_briefget_morning_newsget_news_coverageget_previous_close_contextEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Read-only China A-share data for AI agents: market, limit-up, capital flow and disclosures.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mars-0310/morning-brief-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
