get_news_stock_hits新闻命中个股：主流财经媒体新闻点名了哪些股票。把新华网、财联社、新浪财经、同花顺等主流媒体的快讯/新闻与 A 股简称做匹配，给出每条新闻的发布时间、媒体、命中的股票（不输出标题和正文），以及窗口内被新闻点名最多的股票排行（附熔岩同期 24 小时热度）。不给股票时看全市场；给股票时只看点名它的新闻。约 2 分钟更新。（每次调用计费 1 次）
| Name | Required | Description | Default |
|---|---|---|---|
| src | No | 只看某家媒体（精确匹配，如 财联社 / 新浪财经 / 同花顺 / 新华网） | |
| hours | No | 回看小时数：全市场默认 24、最多 72；指定股票默认 72、最多 168 | |
| limit | No | 返回条数，默认 50，最大 200 | |
| ts_code | No | 股票代码，如 300750.SZ（与 stock_name 二选一） | |
| stock_name | No | 股票简称（与 ts_code 二选一） |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses non-obvious traits: output omits titles and body text, data refreshes roughly every 2 minutes, and each call costs 1 billed call. It also states the applicable time-window bounds per mode. These are operational facts the agent cannot get from structured fields alone.
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 compact paragraph, front-loaded with the resource and source list, then the output shape, then mode behavior, then freshness and pricing. No sentence is padding; the billing note earns its place as decision-relevant information.
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?
There is no output schema, so the description carries the return-shape burden and does so: publish time, media, matched stocks, plus a top-mentioned-stock ranking with 24h heat. Combined with the refresh cadence, cost, and window bounds, an agent has everything needed to call it correctly.
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 100%, so the baseline is 3, but the description adds the mode semantics that the schema does not state: omitting a stock means market-wide view, while supplying ts_code/stock_name restricts to news mentioning that stock. This complements the schema's per-parameter notes on source and hours 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 names a specific verb and resource: it matches financial-media news to A-share tickers and returns the hits plus a ranking. It also scopes the tool by listing the media sources and by explicitly excluding titles and body text, which helps separate it from siblings like search_news_flow. It never names a sibling directly, so the differentiation is implied rather than explicit.
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?
It gives conditional usage guidance ('不给股票时看全市场；给股票时只看点名它的新闻'), which tells the agent how parameters change behavior. However, it gives no guidance on when to prefer this over related tools such as get_first_mention_stocks or get_stock_news_heat, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.