Filter locally collected WeChat articles by account biz ID or name and publish time. Use it to review already gathered history; unknown timestamps are listed separately.
按公众号biz（优先）或名称、文章发布时间筛选本机已获取文章。仅为已收集历史，不是完整公众号历史爬取；未知时间单列。
| Name | Required | Description | Default |
|---|---|---|---|
| end_time | No | ||
| start_time | No | ||
| account_biz | No | ||
| account_name | No |
Changes observed during successful MCP inspections.
v4.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/destructiveHint annotations, the description discloses that only collected articles are visible and that articles with unknown publish times are listed separately. This adds useful behavioral context without contradicting the 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?
Two sentences with no filler; the core filtering behavior is front-loaded and the important scope caveat follows immediately. Every clause earns 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?
The description covers scope, filter dimensions, biz priority, and unknown-time handling, which is adequate for a read-only local query tool. It does not explicitly describe the return shape or behavior when no filters are supplied, but those are minor gaps 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?
With 0% schema description coverage, the description compensates by mapping account_biz, account_name, and start/end_time to the publish-time filtering semantics, and notes that biz is prioritized over name. It could add format/unit details, but it covers all parameters meaningfully.
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 ('筛选本机已获取文章') and resource (locally fetched articles), and explicitly differentiates itself from a full public-account crawl. This lets an agent distinguish it from sibling search/import tools 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 description clearly scopes usage to already-collected local history and explicitly excludes full account-history crawling, which implies when not to use it. It does not name specific sibling alternatives such as search_wechat_articles, but the boundary is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.