list_shared_articles

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses several important behaviors: bounded pagination, URL deduplication, preserving each chat reference, and the critical caveat that the filter time is share time, not article publish time. This last warning directly prevents a likely misuse and adds real value beyond 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?

A single dense sentence front-loads the main action, then appends two important qualifiers (dedupe/references and share-time semantics). Every clause earns its place and there is no filler.

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 read-only listing tool with annotations covering safety, the description covers the core behavior and the most surprising semantic (share-time filtering). It does not describe the return structure or pagination response details, but with no output schema and five self-named parameters, the definition is still sufficient for correct selection and 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?

With schema description coverage at 0%, the description partially compensates by clarifying session scope and that time filters are share-time, not publish-time. However, it does not explicitly map offset vs scan_limit, describe pagination semantics, or explain the meaning of start_time/end_time beyond the share-time caveat, leaving some parameter meaning to inference.

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: scanning Official Account article links in specified sessions, with bounded pagination, URL deduplication, and per-chat references. This clearly distinguishes it from siblings like search_wechat_articles or get_saved_article because the scope is session-based scanning rather than search or single-article retrieval.

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 clear context for when to use the tool: when article links shared within specific chat sessions need to be scanned and deduplicated. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the session-scoped wording is specific enough to imply the intended use case.

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