x-news-digest

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

No annotations are provided, so the description must carry the behavioral burden. It discloses return content ('含 views/媒体信息') and accepted input forms, and the verb '读取' implies a read-only operation, but it omits auth requirements, rate limits, error behavior, and explicit side-effect guarantees.

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 description is a single, front-loaded sentence with zero waste. It front-loads the core purpose and follows with input and return details, earning its place.

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 getter with no output schema, the description covers purpose, accepted input, and returned facets. It lacks usage guidance and operational details, but those gaps are minor given the tool's simplicity.

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 parameter is fully documented in the schema. The description restates that it accepts a URL or numeric id but adds no format examples or constraints beyond what the schema already provides. Baseline 3 is appropriate.

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 (单条 X 帖子详情), with added scope (single post) and return facets (views/媒体信息). It is clear what the tool does, but it does not distinguish itself from any sibling tool, 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?

There is no guidance on when to use this tool versus alternatives. It does not name any sibling tool or describe conditions that select this tool over search_x_news or others. The usage context is only implicit in the phrase '读取单条'.

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 burden, and it only implicitly signals the operation is a harmless read of a built-in static list ('内置'). It says nothing about return format, ordering, pagination, or whether any auth is required, which is a modest gap for a zero-parameter list tool.

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 short sentence that front-loads the action and resource, with the cross-tool relationship tucked into a parenthetical. 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?

With no output schema and no annotations, the description should carry the full picture, but it only hints that names are returned and never describes the actual shape of each preset entry. Adequate for such a simple tool, but incomplete.

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 per the baseline there is nothing for the description to disambiguate. The parenthetical about pack names being usable in scan_accounts adds a little semantic value about what the returned values mean.

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?

Names a specific verb and resource ('列出内置精选账号包'), and the parenthetical clarifies it is the source of pack names consumed by the sibling scan_accounts, so it is distinguishable from get_post, reset_seen, and search_x_news. An agent can tell what this returns without opening the schema.

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 note that scan_accounts can reference the pack names directly conveys when this tool is useful (as a discovery step feeding scan_accounts). It gives clear context but stops short of an explicit 'call this before scan_accounts' instruction or any exclusions.

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 burden, and it does disclose the key side effect: the next scan will treat posts matching the time window as new and re-deliver them. That is exactly the behavioral context needed for a destructive reset. It stops short of covering permissions, reversibility, or whether the cleared data can be recovered.

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 sentence that front-loads the action and then the consequence and warning, with no filler. Every clause earns its place and nothing is repeated from structured fields.

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 destructive tool with no annotations and no output schema, the description supplies the essential behavioral fact (the re-push side effect) plus a caution. Only permission/auth requirements and reversibility are absent, which are minor gaps here.

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 there is nothing to document and the schema cannot be improved upon. The baseline of 4 applies; no parameter-level ambiguity exists.

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 action and target: clearing the seen/dedup store ('清空已见去重库'). It is unambiguous about what is reset, though it does not explicitly contrast itself with siblings like scan_accounts, which is the tool whose behavior it affects.

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?

Usage is implied rather than stated: the parenthetical warning '慎用' (use with caution) and the explanation of the downstream effect tell the agent to avoid this casually, but no explicit when-to-use/when-not-to-use condition or named alternative is given. The agent must infer the context from the scan-related consequence.

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. It discloses the output shape (heat-sorted Chinese digest) but omits key behaviors: the default mark_seen=true means it writes to a seen-library and alters future results, and that side effect is never surfaced in the description. No mention of rate limits, auth, or reversibility.

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?

Two compact sentences with the core action and output front-loaded, then the accounts format detail. Every clause earns its place; no 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?

There is no output schema, and the description compensates partially by naming the return (heat-sorted Chinese daily digest). But with no annotations and a state-mutating default (mark_seen), the description is only marginally sufficient for correct invocation.

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 baseline is 3 and the schema already documents all five parameters. The description restates the accounts format (comma-separated or preset packages, mixable), adding a small amount of framing but nothing the schema does not already contain.

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+resource (扫描 X 账号帖子) and the produced artifact (按热度排序输出中文资讯日报), which is concrete and informative. It self-labels as 核心工具, helping the agent prioritize it. However it does not explicitly distinguish itself from the sibling search_x_news, so it stops 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?

The '（核心工具）' tag implies this is the primary/aggregate tool versus siblings like get_post and search_x_news, giving implied usage context. But there is no explicit when-to-use, when-not-to-use, or named alternative, so guidance remains inferential.

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 burden. It usefully discloses a real behavioral caveat (shallow free-mirror index, unreliable empty results), which is more than most definitions offer. However it says nothing about rate limits, authentication, result freshness beyond the hours param, or sorting edge cases.

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?

Two sentences, zero waste. The core action is front-loaded and the reliability caveat plus alternative-channel routing follow immediately after.

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 3-parameter read tool with no output schema and no annotations, the description covers the essential operational risk (unreliable results, preferred alternative). It does not describe return shape, but the schema already documents all inputs completely.

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%, with query, count, and hours all documented in the schema including example query syntax like 'from:OpenAI'. The description adds no parameter-level detail beyond that, so the 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 and resource ('按关键词搜索 X 帖子') plus the ordering behavior ('按热度排序'). It implicitly distinguishes itself from scan_accounts by being a keyword search rather than an account scan, so an agent can tell them apart without opening either schema.

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?

Explicitly routes the agent: the '主通道请用 scan_accounts' instruction names the alternative and the condition under which it is preferred. It also warns that empty results are not conclusive, which is actionable guidance. It stops short of stating when keyword search itself should be chosen over account scanning.

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