Skip to main content
Glama
AmyYingTang

mcp-news-briefing

by AmyYingTang

briefing_stock_digest

Fetch scraped stock news for a ticker to assess bullish/bearish sentiment and flag potential risks, providing early warning signals for monitoring.

Instructions

获取已抓取的股票新闻列表,供分析利好/利空。核心定位是帮用户提前看到风险。拿到数据后请:

  1. 根据该股票的侧重面(focus)逐条分析

  2. 每条新闻标注:🟢🟢 强利好 | 🟢 弱利好 | ⚪ 中性 | 🔴 弱利空 | 🔴🔴 强利空

  3. 跟侧重面无关但重大的消息也要标注

  4. 对🟢🟢和🔴🔴级别的消息,用 web search 查证官方来源

  5. 检查该股票的 active alerts(返回的 stock_alerts + global_alerts):

    • 对每条新闻,检查是否命中任一 alert 的 keywords

    • 命中时根据 alert 的 sensitivity 判断相关性: loose = 可能相关即触发 / normal = 直接相关才触发 / strict = 确定性进展才触发

    • 判断为相关后,触发前先做事件去重: · 提取新闻中的事件日期(事件本身发生的日期,非新闻发布日期)和事件摘要 · 调用 briefing_stock_alert_trigger 检查是否重复 · 如果返回 near_date_found + near_entries,比对新闻内容与已有 event_signature:

      • 语义相同 → 调用 action='append_duplicate' 追加来源,不重复触发预警

      • 有实质性进展 → 调用 action='confirm', is_update=true,触发并标注为事件更新

      • 不同事件 → 调用 action='confirm', is_update=false,正常触发

    • 触发的新闻用 ⚠️ 标注并附上 alert 描述

    • 事件更新用 ⚠️🔄 标注,附上"此前已有相关预警,本次为事件进展"

    • 触发后立即 web search 深度查证,侧重"这个风险有多大、是否需要关注"

    • 通用预警触发用 🌐⚠️ 标注

  6. 呈现顺序:预警触发和利空消息优先排列,利好消息正常列出但不渲染成"机会"

  7. 整体情绪总结

  8. 如有 alert 被触发,在总结末尾单独列出预警触发情况,并调用 briefing_stock_alert_trigger 记录

  9. 分析完成后,调用 briefing_stock_history_record 记录情绪快照(含 alert_triggers)

  10. 如果历史快照 >= 5 天(通过返回的 divergence 字段判断),检查情绪与股价背离:

  • 情绪偏正面 + 股价跌 + alert 触发利空 → 预警捕捉到了尚未被充分定价的风险,重点提示

  • 情绪偏正面 + 股价跌 + 无 alert 触发 → 可能遗漏了某个风险信号,建议用户检查是否需要补设预警

  • 将背离分析作为单独板块呈现

  1. 不要主动给出买入/卖出/加仓/减仓建议,只提供风险信息

  2. 使用中性语气呈现所有信息:

    • 不说"建议关注"、"持续关注"、"值得注意"、"需要警惕",说"以下是匹配到的消息"或直接呈现内容

    • 不说"风险较大"、"情况不乐观"、"前景堪忧",说"新闻情绪偏负面"并附上具体新闻

    • 不说"利好消息令人鼓舞"、"表现强劲",说"新闻情绪偏正面"并附上具体新闻

    • 不说"可以考虑..."、"或许应该...",只呈现信息,不引导任何行动

    • 预警触发时,只说"以下新闻匹配了你设定的预警条件",不说"你担心的事情发生了"

    • 查证结果只呈现事实("该消息来源为路透社,引述两位匿名官员;公司官方尚未确认"),不做可靠性判断(不说"可靠性中等"、"基本可信")

用中文回复。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo日期(YYYY-MM-DD),不填则默认今天。用于回溯分析历史日期的已缓存数据。
limitNo返回条数(默认30)
tokenNo用户token或用户名。留空则自动使用默认身份。
tickerNo只看某只股票(可选,不填则返回全部)
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure. It reveals that using this tool involves calling other tools (briefing_stock_alert_trigger, briefing_stock_history_record), performing web searches, deduplicating events, and following strict tone guidelines. It also implies side effects like recording history and triggering alerts, which is far more transparent than a typical tool description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long, with 12 numbered steps and redundant stylistic instructions (e.g., multiple examples of forbidden phrasing). While it's front-loaded with purpose, the sheer verbosity makes it less concise. Several instructions could be condensed without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the lack of output schema and annotations, the description is remarkably complete for a complex analytical tool. It covers sentiment labeling, alert checking, event deduplication, presentation ordering, summary, divergence detection, and tone restrictions. The only gap is that it doesn't describe the exact structure of the returned news list, but the workflow makes it largely inferable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters (date, limit, token, ticker) are already well-documented. The description adds no additional meaning for these parameters—it doesn't mention them at all. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb+resource: '获取已抓取的股票新闻列表' (get fetched stock news list) and states its core purpose '帮用户提前看到风险' (help users see risks early). This clearly distinguishes it from siblings like briefing_get_articles or briefing_stock_fetch, which are more about raw retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a detailed 12-step workflow for how to use the returned data (analyze, label sentiment, verify, check alerts, trigger, record history, etc.), giving strong implied usage context. However, it never explicitly mentions when to use this tool versus alternatives like briefing_get_articles or briefing_stock_fetch, nor does it state exclusions or preconditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AmyYingTang/mcp-news-briefing'

If you have feedback or need assistance with the MCP directory API, please join our Discord server