Check crawl engine health, including crawl counts, per-site status, and stale monitoring alerts, so you can confirm price tracking is working correctly.
检查后台采集引擎的运行状态，包括采集次数、各站点采集情况、过期监控检测。
用户可能的问法：
"采集系统运行正常吗"
"今天采集了多少次"
"各站点的采集情况怎样"
"有没有监控很久没更新了"
无需参数，直接返回采集系统健康报告。数据范围为当前用户自己的监控商品。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the important scoping constraint (data covers only the current user's monitored products) and that it is a direct, no-arg read of a health report, but it doesn't state permissions, rate limits, or freshness semantics. An output schema exists, so return-shape details are reasonably omitted.
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 purpose is front-loaded in the first sentence, followed by example intents and a scope note. The example list is slightly padded but each line serves routing value, so it stays efficient overall.
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?
No parameters, an output schema, and no annotations make this a simple tool, and the description covers purpose, scope, and invocation. An agent has enough to call it correctly; only minor behavioral detail (e.g. what 'stale' means) is missing.
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?
With zero parameters and 100% schema coverage, the baseline of 4 applies. The description correctly reinforces that it takes no parameters, adding no contradictory or missing parameter guidance.
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 ('检查后台采集引擎的运行状态') and enumerates what the report contains: crawl counts, per-site status, and stale-monitor detection. It doesn't explicitly name a sibling it is not (e.g. get_monitor_overview or get_smart_follow_stats), so an agent must infer differentiation from content rather than explicit disambiguation.
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?
Four example user phrasings map clear intents to this tool, which is strong routing guidance for an intent-matched agent. It also states that no parameters are needed. It lacks explicit when-not-to-use or named alternatives, keeping it at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.