x-news-monitor

Does 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 internal pipeline (crawl, dedupe/sort, generate Chinese daily report, push to configured webhook), which tells the agent this is a net mutating/side-effecting operation. It does not state idempotency, rate limits, failure behavior, or whether the dedupe state persists between runs.

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 zero waste, describing purpose and pipeline in one compact clause. No repetition or padding.

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 zero-required-parameter, side-effecting action tool with no output schema, the description is adequate but omits important operational context: what a returned 日报 looks like, webhook failure handling, and interaction with reset_seen or push_status. It is usable but not 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 description coverage is 100%, so the schema already documents all four parameters (top, push, hours, min_heat) in Chinese. The description does not add syntax, format, or edge-case semantics beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (监控账号新帖), then enumerates the pipeline stages: 抓取、去重排序、生成日报、推送 webhook. This is clearly distinct from siblings like push_status or reset_seen.

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?

No explicit when-to-use or when-not-to-use guidance relative to alternatives. The description implies an immediate ad-hoc scan versus scheduled monitoring, but does not state this or name any sibling tool as a non-overlapping alternative.

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

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

No annotations are provided, so the description carries full burden. The verb '查看' implies a read-only observational operation and lists what is checked, but it omits authentication requirements, rate limits, side effects, and return shape.

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 parenthetical scope; no redundant text and the essential purpose is stated immediately.

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 zero-parameter read-only status tool, the description conveys the check target and the checked channels. It is largely complete, though without an output schema it does not describe the return format (e.g., per-channel boolean or summary).

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?

The tool has zero parameters, which per rubric gives a baseline of 4. The description cannot and need not add parameter semantics beyond the empty schema.

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 (view webhook push channel configuration status) and enumerates feishu/slack/discord, which is more specific than the tool name. However, it does not explicitly differentiate itself from siblings such as watch_list or check_now, so it falls short of a 5.

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?

Provides no when-to-use guidance, no exclusions, and no alternatives among the sibling tools. Usage is only implied by the purpose.

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

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

With no annotations provided, the description fully carries the burden and does so well: it discloses that this is a destructive/reset operation and precisely explains the downstream effect on monitoring (previously seen posts will be re-pushed as new).

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 tight sentence that front-loads the action and immediately supplies the critical caveat, with no wasted words.

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 zero-parameter reset tool with no output schema, the description gives enough: the action, the target, and the behavioral consequence. Only a missing note on required permissions or irreversibility keeps it from a 5.

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?

The tool has zero parameters and the schema is empty, so there are no parameter semantics to document; the description correctly adds no irrelevant parameter detail.

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 action (清空/clear) on a specific resource (已见去重库/the seen deduplication store), clearly distinguishing it from the monitoring and watch-management siblings.

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 provides an explicit warning about the consequence ('下轮监控会把时间窗内命中帖当新帖再推一遍，慎用') which tells the agent both when this is dangerous and to use it cautiously, though it does not name alternative tools.

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

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

没有任何 annotations，行为披露完全由描述承担。描述仅提到 @ 可选和标签用途，未说明重复添加、权限要求、速率限制或副作用等关键行为特征。

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?

单句完成，动作、对象和两个参数的补充信息均前置且无冗余，每个分句都有实际作用。

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?

对于参数少、schema 覆盖完整的简单添加工具，描述已覆盖核心用途、必填 handle、可选 @ 和 tag 用途。虽然未说明重复添加等行为，但整体复杂度低，基本够用。

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 覆盖率 100%，基线为 3。描述额外说明 handle 中的 @ 可有可无，并解释 tag 的分组用途，提供了 schema 之外的有用语义。

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?

明确说明了具体动作（加入监控列表）和资源（X 账号），并补充了 handle 中 @ 可选的格式细节。但未像理想定义那样点明与 watch_remove、watch_list 等兄弟工具的区分，因此未达 5 分。

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?

描述只隐含用于添加监控账号，并说明标签可用于日报分类，但没有给出何时使用、何时不使用、前置条件或与替代工具（如 watch_remove、watch_list）的选择指引。

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

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

No annotations and no output schema, so the description carries the full disclosure burden. It does the most valuable part by naming the returned fields (account, group tag, join time) and the verb 查看 implies a read-only listing, but it says nothing about ordering, pagination, or whether entries can ever be filtered.

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 the resource first and the returned fields in a compact parenthetical; nothing is padded or repeated. It is perhaps slightly terse on context, but there is no wasted wording.

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 zero-parameter read-only listing with no annotations and no output schema, the minimum an agent needs is what the tool returns and that it does not mutate anything — both are conveyed. The remaining gap is purely relational (when to prefer it over check_now or push_status), which is minor at this complexity.

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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly adds no param syntax and instead spends its budget on the return shape, which is the right call for a parameterless tool.

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 goes further by enumerating what the list contains (账号 / 分组标签 / 加入时间). This clearly separates it from the mutating siblings watch_add and watch_remove, though it never names them.

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 word 当前 (current) implies this is the retrieval tool for the existing watch state, but there is no explicit when-to-use, no prerequisites, and no pointer to siblings like watch_add or check_now. Usage is inferable but not stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only states the mutation. It says nothing about idempotency, what happens if the handle is not currently watched, required authorization, or whether the removal is reversible.

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 zero wasted words. It is appropriately terse for a one-parameter tool, though the brevity borders on under-specification rather than purposeful concision.

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 simple one-parameter tool with full schema coverage and no output schema, the description is minimally adequate. However, with no annotations to cover safety and error behavior, it leaves the agent without information about failure modes or side effects.

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 100%, so the single 'handle' parameter is already fully documented in the schema ('要移除的 X 账号'). The description adds no format, identifier, or lookup semantics beyond what the schema provides, so baseline 3 applies.

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+resource ('把账号移出监控列表' = remove account from watch list), which clearly distinguishes it from watch_add and watch_list by the direction of the operation. It does not explicitly name the sibling tools, so sibling differentiation is inferred rather than stated.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as watch_add (to subscribe) or watch_list (to inspect the list). The agent must infer usage purely from the tool name and one-line description.

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