Scans recent company announcement titles for red-line keyword hits, returning each match’s date, title, source link, and rule number for initial risk screening.
只做风险信号扫描：拉最近公告标题，按红线关键词命中列出。
适合快速初筛。返回每条的日期、标题、原文链接和命中的规则编号。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| pages | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does disclose the mechanism (pulls recent titles, matches keyword rules) and what is returned per item. However it omits auth/permission expectations, scope limits, and how 'recent' is bounded, which a no-annotation read operation should ideally cover.
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?
Compact and front-loaded: the scope constraint leads, then the use case, then the return fields. No wasted wording, though the line-broken fragments read slightly choppy.
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 the return-field sentence is somewhat redundant, and the description is reasonably complete on purpose. But with zero param documentation and no annotations, the gaps around 'name'/'pages' semantics and permission behavior leave an agent under-informed relative to a 2-param scanning tool.
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, yet it never explains what 'name' means (presumably the company/target) or what 'pages' controls. The phrase about fetching recent titles vaguely implies paging but adds no concrete meaning for either parameter.
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 states a specific verb and resource: it scans recent announcement titles for red-line keyword hits and says '只做风险信号扫描' (only does risk signal scanning), which distinguishes it from heavier report-building siblings like build_report. It stops short of naming a specific alternative sibling, so it misses the top bar.
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?
'适合快速初筛' gives implied when-to-use guidance: fast initial screening. There is no statement of when NOT to use it, no explicit alternatives, and no prerequisites, leaving usage largely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.