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

Beyond the readOnlyHint=false annotation, it discloses that this is a checkpoint/commit action with a side effect in a success group, and it cautions against premature confirmation. Nothing contradicts 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 short sentences with no filler; the warning clause earns its place. The phrasing is somewhat dense/jargon-heavy, but it is economically structured and the key precondition is stated up front.

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 2-parameter ack tool, it covers what to do and when to do it, and there is no output schema to document. However, parameter semantics and the exact meaning of the success-group checkpoint are left implicit, so completeness is only minimal.

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 0% and the description never explains what id versus batch_id identifies or how they relate. The only phrase '关注批次' is generic and not mapped to either parameter, so the agent gets no parameter-level 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 concrete action: explicitly confirm the watchlist batch and submit a success-group checkpoint after all pages are read and organized. This makes it clearly distinct from sibling read/poll tools such as read_watchlist_batch.

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 gives a clear precondition (all pages read/processed) and an explicit warning not to confirm while output is unsaved/unprocessed. It does not name an alternative tool, so it stops short of full routing guidance.

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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses a key side effect: it can write raw JSON, analysis JSON, and Markdown to the local workspace. It also clarifies the read scope (paged, up to 5000 messages) and the analysis pipeline. It does not mention overwriting behavior or whether source messages are modified, but the main side effect is explicitly surfaced.

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 compact sentence that front-loads the core action (paginated read + analysis) and then adds output details. No filler or redundant restatement; every clause contributes meaningful information about purpose, behavior, or outputs.

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 complex tool with 9 parameters, no output schema, and 0% schema description coverage, the description is incomplete. It does not explain time-range filtering, cursor parameters, the exact structure of the analysis outputs, how output_dir is used (file naming, overwrite), or what the tool returns. An agent would likely need to ask follow-up questions to invoke it correctly.

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 0%, so the description must compensate. It explains several parameters implicitly: '最多5000' maps to limit, '分页' maps to offset/page_size, '指定会话' maps to session_id, and '写入本地工作区' maps to output_dir. However, start_time, end_time, after_local_id, and after_timestamp are entirely unexplained, leaving significant gaps for a 9-parameter 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: '分页读取最多5000条指定会话消息' (paginated read of up to 5000 session messages), then enumerates distinct analysis actions (multi-label classification, risk/asset extraction, evidence indexing) and output-writing behavior. This clearly differentiates it from sibling read-only tools like get_recent_messages or search_messages, which only retrieve messages without analyzing or writing artifacts.

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 provides clear context: this tool is for reading a specified session's messages, applying analysis, and writing outputs to a local workspace. It implies when to use it (when analysis, risk/asset extraction, or evidence indexing is needed) but does not explicitly name alternatives or state when-not-to-use conditions, so it falls short of a 5.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool has two modes (all recent sessions or a specific session), which is useful, but it does not explain what 'new' means relative to since_minutes or how message_types affect results.

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 concise sentence with no fluff and is front-loaded with the action. However, it is too sparse for a tool with six parameters and no schema descriptions, so the brevity undermines its usefulness.

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?

Given the absence of an output schema and the large sibling toolset, the description should clarify what the tool returns and how parameters interact. It does neither, leaving the agent to guess the return shape and filtering behavior.

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 0%, so the description must compensate for documenting the six parameters. It only hints at session_id ('指定会话') and since_minutes ('最近'), leaving limit, sender_id, text_only, and message_types entirely unexplained.

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 clear verb ('检查'/'check') and resource ('会话'/'sessions') with a specific focus: finding sessions with new messages, either across recent sessions or for a specified session. It is distinct in intent from siblings such as list_sessions or search_messages, though it does not explicitly differentiate itself by name.

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 guidance is given about when to use this tool versus alternatives like get_recent_messages or scan_sessions. The description implies the use case by stating the function, but there are no exclusions, prerequisites, or alternative routing clues.

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 already state it's not read-only and not destructive, which the description aligns with. It adds behavioral detail about replace=true rebuilding the baseline and pausing, plus explicitly notes it doesn't run automatically or notify—useful context beyond the annotation booleans. No contradictions detected.

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 concise sentences, with the core purpose front-loaded. Every clause adds value: the action, the key inputs, the toggles, and the non-execution caveat. Zero 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?

The tool has 8 params and no output schema. The description covers the essential behavior (save, modify, pause) and clarifies it's a configuration action without immediate side effects. It leaves some parameter details to the schema, which is acceptable given the schema is available. It's adequately complete for an agent to decide when to call it.

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 coverage is 0%, so the description must compensate. It explains replace and paused and maps 'sessions, keywords, persons' to the relevant parameters (session_ids, keywords, sender_ids). However, it doesn't cover id, name, or match_mode, though the latter has an enum that is self-explanatory. Partial coverage of the 8 parameters earns a 3.

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 clearly states the tool saves a watchlist locally ('在本机保存多群关注列表'), specifying the key inputs (sessions, keywords, persons). It differentiates from siblings like list_watchlists, poll_watchlist, and read_watchlist_batch by emphasizing this is configuration-only, giving a distinct verb-resource pairing.

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 explicitly says '仅配置，不自动运行或发通知' (config-only, no auto-run or notifications), making it clear this is for setup rather than execution. It mentions replace and paused behaviors, which informs usage for creating vs. updating. It doesn't name alternatives explicitly, but the context with sibling tools like poll_watchlist and list_watchlists implies the distinction well enough.

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?

Beyond annotations, it discloses the local write destination, exclusive directory behavior, default first-12-image limit, and the return of per-image results, SHA256 hashes, and missing ranges. It does not mention overwrite or file-conflict behavior, but the disclosed side effects are useful and consistent with readOnlyHint=false and destructiveHint=false.

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 sentence, and every clause adds value: action, target, destination, return contents, and default count. It is front-loaded with the core action and destination.

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 two-parameter tool with no output schema, the description covers the return contract and destination well. However, it omits parameter semantics, error/overwrite behavior, and criteria for what counts as an archived article, leaving notable gaps for an agent to resolve elsewhere.

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 0%, so the description must carry parameter meaning, but it never explains that article_id identifies an archived article or that image_indices selects specific images by 1-based index. The 'default first 12' clause hints at behavior when image_indices is omitted, but this does not compensate for the overall lack of parameter documentation.

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 uses a specific verb (下载/download), names the target resource (已存档公众号文章配图/archived article images), and specifies the local destination (本机output/articles独占目录). This clearly distinguishes it from siblings like read_article_image or get_saved_article without needing schema inspection.

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 phrase 已存档 (archived) implies the tool is for previously saved or imported articles, but no alternative tools or when-not-to-use conditions are named. An agent can infer moderate usage context, yet explicit routing guidance is missing.

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 declare a write operation (readOnlyHint=false) but no destructiveness, and the description adds real value: the output is a private-content ZIP that must be reviewed before external sending, plus the distinction between explicitly-extracted attachments and merely-listed candidates. It does not contradict the annotations. It stops short of describing output location/format or overwrite behavior.

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?

Three tight sentences, front-loaded with the primary action, then parameter nuance, then the privacy warning. No filler; the warning earns its place given the private-content output.

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 14 parameters, 0% schema coverage, and no output schema, the definition is too thin for an agent to invoke confidently: most pagination, time-range, and output-destination parameters are unexplained, and the ZIP's structure/return is undescribed.

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 0% across 14 parameters, so the description carries the full burden. It usefully disambiguates attachment_paths (files actually extracted) versus auto_link_attachments (candidates only listed), but leaves the other twelve parameters — paging (limit/offset/page_size), time windows (start_time/end_time/after_timestamp/attachment_time_window_seconds), output_dir, attachment_scan_limit, max_chars_per_attachment — completely undocumented.

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: exporting a session-evidence ZIP locally on this machine. This is the only export/write tool among siblings dominated by readers, so its identity is distinguishable. It lacks an explicit contrast with siblings, but no sibling overlaps.

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 indication of when to reach for this over the many read tools (search_messages, get_recent_messages, list_wechat_attachments) or of prerequisites. It explains parameter behavior for two flags but never states the triggering scenario for choosing export.

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 already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds that neighboring context can be padded in (补前后语境) and that identity must be exact, which is useful behavioral context, but it says nothing about result limits, ordering, or output 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?

Two dense sentences: purpose and scope first, then the identity-verification precondition. Little waste, though it could be slightly tighter.

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 10-parameter tool with no output schema and 0% schema coverage, the description is thin: it omits time filtering, keyword matching, session offsets, and pagination limits, leaving an agent unable to use most of the parameters correctly.

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 0% across 10 parameters, so the description must carry the load. It only clarifies sender_ids (exact sender ID) and implicitly context_before/context_after (补前后语境); session_ids, start_time, end_time, keywords, match_mode, offsets, and per_session_limit are all left unexplained.

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 (提取…发言, extract messages of a person) with scope (multiple sessions) and mechanism (by exact sender ID, with optional surrounding context). It is clearly a target-person extraction tool, though it does not explicitly name how it differs from the close sibling get_messages_by_sender.

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 gives concrete workflow guidance: first confirm identity via the contact list or sender list, and do not substitute fuzzy nickname matching. This is a real precondition (routing to list_contacts / list_session_senders). However, it stops short of naming the alternative extraction/search siblings and when to prefer them.

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 annotation contradiction: annotations say readOnlyHint=true and destructiveHint=false, which aligns with 'extract' being a read operation. The description adds useful behavioral context by enumerating supported formats (ZIP text items, OCR, ASR, keyframe OCR, timestamp evidence), which is beyond the generic annotations. However, it does not disclose details like output format, limits, or failure modes, so the description only partially carries the burden.

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 two sentences, front-loaded with the main purpose ('extract downloaded WeChat file text or media evidence'), followed by a compact enumeration of supported types. Every part adds value, though the second sentence could be more structurally organized; overall it's efficient.

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 tool has moderate complexity (multiple file types, OCR/ASR), and the description lists supported types, but it lacks details on output schema (no output schema given), parameter semantics (especially max_chars), and any required preconditions (e.g., file must exist). For a complex extraction tool, this is adequate but not comprehensive.

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 0%, so the description must add meaning to parameters. The description conveys that the tool processes a downloaded file path, which aligns with 'source_path', but it does not explain what 'max_chars' controls or how to specify it, leaving the parameter semantics partly inferred from the name alone.

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 ('extract') and resource ('wechat attachment text'), and lists the supported file types, which conveys the core function. It is somewhat distinguishable from siblings like 'search_wechat_attachment_text' (which searches rather than extracts), though it doesn't explicitly name alternatives.

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 does not state when to use this tool versus siblings like 'read_wechat_image' or 'search_wechat_attachment_text'. It implies extraction from downloaded files but gives no conditions or exclusions, leaving the agent to infer context from the file-type 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?

Annotations include readOnlyHint=false (implying writes) and openWorldHint=true, and the description confirms it saves to a local library, which matches the mutation intent. It also discloses failure behavior (stops on verification/login) and a limitation (cannot use chat card instead of full text), adding 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?

The description is compact: one concise sentence covering the main action and two short clarifications, with no redundancy. Every phrase adds useful information about behavior.

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 is sufficient for a simple single-parameter tool, but it lacks details on output format or confirmation of saving, and does not explain the difference from similar tools like 'read_wechat_post' or 'import_wechat_article'. Given the complexity of web fetching and the lack of an output schema, more behavioral detail would help.

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 schema only defines 'url' with a maxLength, and the description does not elaborate on the URL format, accepted protocols, or any constraints. With 0% schema description coverage, the description should compensate but only implies the URL is for a WeChat article, leaving ambiguity about what types of URLs are accepted.

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 clearly states the tool fetches WeChat article content, images, and publish time from the web, and saves to a local library. It distinguishes itself from siblings like 'read_wechat_post' which reads existing posts, but does not explicitly name alternatives.

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 includes explicit stopping conditions (when verification/login encountered) and a negative instruction ('cannot use chat card instead of full text'), which gives clear usage context. However, it does not explicitly state when to use this tool versus alternatives like 'search_wechat_articles' or 'import_wechat_article'.

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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral detail beyond annotations: it explicitly states that if the message is not found, the tool reports it as uncovered and does not guess context. This is valuable context for the agent's expectations.

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 sentence that front-loads the core action and includes the failure behavior. It is concise with no filler, 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?

Given six parameters, two required, and no output schema or parameter descriptions, the description is too brief. It covers the required parameters but leaves the optional ones unexplained, and it does not describe the return format or structure. An agent would have to guess the meaning of after/before/offset/scan_limit, which is a significant omission for a tool with 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?

Schema description coverage is 0%, so the description must compensate. It mentions session_id and local_id by name, but does not explain the other four parameters (after, before, offset, scan_limit). Without any schema descriptions, the agent cannot infer their purpose or constraints from the tool description alone, leaving a significant gap.

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 clear action: reading message context (before/after) by session and localId. It also specifies behavior when the message is not found. This distinguishes it from siblings like search_messages or get_recent_messages, though it does not explicitly name an alternative.

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 implies usage: when you need surrounding context for a specific message. However, it does not explicitly state when not to use it or mention alternatives like search_messages or get_recent_messages. There is no guidance on selecting this over other context-related 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 already declare readOnlyHint=true and destructiveHint=false, and the description adds value beyond them by disclosing the return shape (scan count, cursor, coverage boundaries) and the bounded-window scope consistent with openWorldHint=false. The exact-match-not-nickname caveat further discloses behavior. No contradiction with 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 dense sentences with zero filler. The primary action is front-loaded, followed by the return disclosure and a single high-value caveat. 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?

With no output schema and 0% schema coverage, the description carries the full burden. It conveys purpose, return format, and matching semantics, but leaves pagination parameters (limit/offset), scan_limit semantics, and time-window conventions to inference — a real gap for a 7-parameter tool an agent must invoke correctly.

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 0%, so the description must compensate — and it does partially, explaining the core semantics (sender_id exact filter, bounded window) and hinting at scan_limit/offset via 'scan count' and 'cursor'. But it leaves limit, start_time, end_time, and the precise meaning of coverage boundaries unexplained across 7 parameters, falling short of full compensation.

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 (precisely filter messages by sender ID) within a clearly bounded scope (bounded window of a session). The nickname caveat ('不会把昵称相似当同一人') sharpens its identity against fuzzy-search siblings like search_messages, making the tool's exact-match purpose unmistakable.

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 by the precise-filter semantics — an agent can infer it is for exact sender-ID lookups rather than fuzzy search — but the description never names alternatives or states when not to use it. With 38 siblings including search_messages, get_recent_messages, and extract_person_messages, explicit routing would materially help.

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 already declare readOnlyHint=true and destructiveHint=false, which the description aligns with (it is a read operation). The description adds a behavioral nuance: it returns the 'most recent' messages, implying time-based ordering. However, it does not disclose other behaviors like pagination details or order direction, which the many pagination parameters suggest are important.

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 concise sentence that front-loads the core purpose. It is efficient with no extraneous words. However, given the complexity of parameters, a bit more detail could be added without becoming verbose.

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 tool has 9 parameters and likely complex retrieval logic, but the description only covers the basic purpose. It lacks information on default behavior (e.g., sort order), interaction between parameters (e.g., time range vs limit), and output format (no output schema). The absence of this context makes it challenging for an agent to construct correct calls, especially with filters and pagination.

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 0%, so the description must compensate for parameter documentation. It only explains session_id and part of limit ('recent N'), but does not explain the meanings of offset, start_time, end_time, sender_id, text_only, message_types, or page_size. Given the 9 parameters and 0% coverage, the description fails to add meaningful semantics for most parameters.

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 ('get'), resource ('recent messages'), and scope (specified session, N most recent). It clearly communicates the core function. However, it does not explicitly differentiate from sibling tools like get_messages_by_sender or get_message_context, which have overlapping purposes.

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 implies usage for retrieving recent messages from a session, but provides no explicit guidance on when to use this tool versus alternatives such as search_messages, get_messages_by_sender, or get_message_context. Sibling tools with similar functions exist but are not mentioned, leaving the agent to infer the appropriate use case.

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 already carry the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds mild value by specifying what is returned — body text plus an image list — but says nothing about not-found behavior, error handling, or how the content is structured. No contradiction with 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 front-loaded sentence with zero filler. The verb, resource, and output contents all appear in the first clause, and there is nothing unnecessary to trim.

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 1-parameter, read-only, annotation-covered tool, the description—along with the schema pattern and annotations—is mostly adequate and hints at return contents. Remaining gaps are the unspecified source of article_id and missing error behavior, which are notable but not crippling for a get-by-ID operation.

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 0%, so the description must compensate for the undocumented parameter, but it never mentions article_id at all. Only the parameter name and the 64-char hex pattern in the schema communicate meaning; the description doesn't say where the ID comes from (e.g., list_shared_articles) or what format is expected beyond the regex.

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 (读取/read), a specific resource (本机文章库/local article library), and a specific scope (a single article's body text and image list). The '本机' qualifier implicitly distinguishes it from network-fetching siblings like fetch_wechat_article, but it does not explicitly separate it from read_wechat_post or list_shared_articles, so differentiation is only partial.

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 'local article library' phrasing implies this is for reading already-saved/imported articles rather than fetching from the network, so usage context is roughly inferable. However, there is no explicit when-to-use statement, no named alternatives, and no exclusion conditions for the close siblings read_wechat_post or query_article_history.

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?

The description explicitly discloses important behaviors beyond annotations: it does not execute scripts and does not request cookies ('不执行脚本、不索取Cookie'), and it marks the imported data as a caller-side snapshot ('标记为调用方快照'). This is valuable behavioral context, and it does not contradict 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?

The description is compact and every sentence carries meaning: what to import, the source/precondition, safety constraints, and when to use it. There is no redundant wording or repetition of schema 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?

The description covers the key use case, constraints, and side-effect marking, but it omits parameter semantics, return behavior, and what happens if the provided HTML is invalid or incomplete. Given there is no output schema or parameter descriptions, this is a noticeable gap.

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 0%, so the description must compensate, but it only hints at the HTML content structure and never explains what `url`, `html`, or especially `partial` mean. The parenthetical content clarifies part of the HTML payload but leaves parameter semantics largely under-specified.

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 ('导入' / import), a specific resource ('本人或AI浏览器已正常打开的文章HTML'), and the exact contents expected (标题、账号、时间、#js_content). This clearly distinguishes it from sibling tools like fetch_wechat_article or get_saved_article, which handle different retrieval or storage paths.

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 gives a concrete trigger: use it when HTTP requests require verification ('可在HTTP要求验证后使用') and when the article HTML is already open in a browser. It does not explicitly name alternatives or say when not to use it, but the intended context is clear enough for an agent to select it appropriately.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing further — no pagination behavior (limit cap of 200), no result shape, no auth context — which leaves the behavioral burden unmet.

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?

It is a single short, front-loaded sentence with zero wasted words. But it is terse to the point of under-specification rather than effectively concise, so it earns only a middling score.

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 tool with no output schema and 0% schema documentation, the description should explain the filter parameters, the list semantics and the return behavior. It supplies none of this, leaving the definition too thin for an agent to call it correctly.

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 0%, so all three parameters (limit, keyword, username) are undocumented anywhere. The description does not mention any of them, nor explain that keyword/username are optional filters or that limit caps at 200, so it fails to compensate for the coverage gap.

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 verb and resource (查询微信联系人信息), so the agent knows it deals with WeChat contacts. However it is vague about scope — it doesn't say whether it lists all contacts or searches/filters them, and it offers no differentiation from the many sibling list_/search_ tools in the catalog.

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 such as list_session_senders or search_messages, nor any prerequisites (e.g. auth/export requirement). Usage must be entirely inferred from the name.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds ordering and the private/group scope, but says nothing about pagination, default limit, or what a returned session entry contains.

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 compact sentence with the resource front-loaded and the scope and ordering appended, with zero redundant 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?

With two undocumented parameters and no output schema, the agent still lacks default limit behavior and the shape of a returned session. The description covers scope and ordering but leaves these gaps for a tool an agent would call frequently.

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 coverage is 0%, so neither the 'kind' enum nor the 'limit' bound is explained in the schema. The description only loosely hints at the private/group distinction (and omits 'all') and never mentions the limit parameter, so it fails to compensate for the coverage gap.

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 adds useful scope (私聊/群聊) plus ordering (按最近活跃时间排序). However, it does nothing to distinguish itself from siblings like scan_sessions or list_session_senders, which an agent could easily confuse with this tool.

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 statement of when to use this tool versus alternatives such as scan_sessions, list_contacts, or get_recent_messages. Usage is only implied by the word 'list', leaving the agent to guess at the routing.

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 already declare the operation read-only and non-destructive. The description adds useful behavioral context beyond annotations: results are limited to scanned messages and aggregated by sender, and the output is not a full roster. This helps set accurate expectations.

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 sentence that front-loads the action and target, then adds purpose and a key limitation. Every part earns its place with no redundant 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 read-only list operation, the description adequately conveys what is returned (speakers and counts) and the important scope restriction (scanned messages only). Pagination and exact return shape are not detailed, but the absence of an output schema and the simplicity of the tool make this a minor gap.

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 0%, and the description does not explain the meaning or usage of session_id, limit, or offset. The pagination parameters are left entirely to inference from their names, and the description does not compensate for the lack of schema documentation.

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?

Description states a specific verb and resource: it lists speakers and their counts within a session's scanned messages. It also distinguishes itself by clarifying it is not a complete group member list, which separates it from sibling tools like list_contacts.

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 gives clear intended use ('供按人精确筛选') and an explicit exclusion ('不是完整群成员名单'). However, it does not name a specific alternative tool, so the guidance is strong but not fully explicit about when not to use it in favor of a sibling.

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?

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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine scope context beyond that: it lists what states are surfaced and explicitly bounds the tool with 不读取聊天, though it says nothing about ordering or completeness of the watchlist set.

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 well-structured sentence, front-loaded with the verb and semicolon-delimited; each clause adds content. Slightly dense but 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 parameterless, read-only listing tool with no output schema, the description conveys enough: what is listed and what is excluded. It could say more about the shape/ordering of results, but the picture is adequately 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?

The tool takes no parameters, so the schema baseline of 4 applies. The description's enumeration of returned facets is a mild bonus but not a substitute for the absent output 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 (列出/list) and resource (本机保存的关注列表/watchlists) and even enumerates the returned facets (暂停状态, 待确认批次). It is clearly a listing tool, distinct from configure/poll/ack siblings, though it doesn't name a specific alternative to route away from.

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 clause 不读取聊天 is a useful negative boundary, but there is no explicit when-to-use guidance or reference to the sibling watchlist tools (configure_watchlist, poll_watchlist, read_watchlist_batch). Usage is only implied by the listing verb.

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 already declare readOnlyHint and destructiveHint, and the description adds valuable context that it only scans local whitelist directories and does not trigger downloads. This goes beyond the annotations by specifying the exact scope and side-effect-free behavior. No contradiction with 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?

The description is a single, concise sentence with no waste, which is positive. However, it lacks crucial information such as parameter explanations, return format, or any caveats, making it arguably too minimal for a tool with five optional parameters.

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?

Given there is no output schema and five parameters, the description is incomplete. It explains the scanning behavior but omits what the output looks like, how filtering parameters interact, and any performance or limit considerations. This leaves significant gaps for an agent to call it correctly.

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 0% and the description does not mention any of the five parameters (limit, keyword, end_time, extensions, start_time). The agent receives no semantic guidance beyond parameter names, making it hard to know how to format or use them.

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 clearly states the verb 'list' and the resource 'WeChat downloaded files and attachments', and specifies the scanning scope as local whitelist directories. It is distinguishable from sibling tools like search_wechat_attachment_text by its listing nature, though it does not explicitly name alternatives.

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 provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about typical use cases. It only states what it does, leaving the agent to infer usage.

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 annotations only telling us it is a non-destructive, non-readonly, closed-world call, the description adds the real behavioral contract: first-run baseline creation, repeated return of pending batches until acked, no checkpoint advance on backlog or upstream failure, and no persistent background execution. This is exactly the stateful nuance an agent needs.

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?

Five tight clauses, purpose front-loaded, then behavior and the ack requirement, then the no-background constraint. Every clause carries information and none is padded.

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?

Behavior is well covered for a stateful polling tool absent an output schema, and the batch-repetition note hints at return shape. However, with 0% parameter coverage and no output schema, an agent still lacks the meaning of id, delivery_limit, include_initial, and per_session_limit.

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 0% across four parameters (id, delivery_limit, include_initial, per_session_limit). The description never explains any of them beyond a vague nod to first-run baseline behavior, leaving the agent to guess at id format and the two limit semantics from the schema alone.

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 (检查/poll) and resource (指定关注列表各群的新消息), which cleanly separates it from generic siblings like check_new_messages or read_wechat_post. It also adds scope qualifiers (first-run baseline, one round per call). It does not name any sibling explicitly, 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?

Gives concrete operational guidance: call once per round rather than backgrounding it, and ack batches only after reading fully. The ack/re-read workflow implicitly routes the agent to the read/ack sibling tools, but no alternative tool is named and no explicit when-not condition is given.

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 already establish readOnly, non-destructive, closed-world behavior. The description adds real value beyond that: it discloses that the tool returns an evidence package with per-person/day statistics and per-group rule candidates, and that natural-language summarization is done by the caller, which shapes how the agent should expect to use the output.

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 dense sentences with no filler; the core purpose and the division of labor with the calling AI are front-loaded. The focus enumeration is long but serves the enumeration of supported use cases.

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 12-parameter tool with a nested offsets object, two enums and no output schema, the description leaves most parameter semantics and the shape of the evidence package unexplained. It conveys the concept of the output but is not sufficient for an agent to invoke the tool correctly across its many options.

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 12 parameters and 0% schema description coverage, the description carries the full documentation burden but only references the focus categories, implicitly mapping to one enum parameter. The other eleven parameters (offsets, time windows, keywords, match_mode, sender_ids, context windows, per_session_limit) receive no explanation in either schema or description.

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 ('prepare a citable evidence package') and enumerates the focus categories it supports. It also distinguishes its role by noting the calling AI completes the summarization, which separates it from a summary-generating sibling like analyze_wechat_chat, though no sibling is named explicitly.

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 focus list implies the scenarios (daily/weekly reports, project progress, risks, etc.), giving a soft sense of when the tool fits. However, there is no explicit when-to-use versus alternatives guidance and no exclusions, leaving the agent to infer the comparison with siblings such as analyze_wechat_chat.

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?

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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the return is a native MCP image block, visibility depends on the client's vision support, and there is a 4MiB per-image ceiling — all of which the annotations do not convey.

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 tightly packed sentence with the resource and return format front-loaded and constraints (one-at-a-time, size cap) trailing. No filler, though the client-dependency clause is slightly tangential to invocation.

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?

It covers the return type and size limit, which is important given there is no output schema. However, it omits how an agent discovers the valid range/count of images for a given article, leaving a practical gap for a tool that reads one image at a time.

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 0% and neither parameter is explained: the 64-hex article_id source is unstated, and image_index's 1-based indexing and 1–100 range are left entirely to the schema. '每次一张' hints at index semantics but does not clarify whether indices are contiguous or gapless.

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 (读取) plus resource (已存档公众号文章的一张配图) and the return modality (原生MCP image块). An agent can distinguish it from generic sibling tools like read_wechat_image or download_article_images, though it does not name those siblings explicitly to sharpen the boundary.

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?

Gives operational constraints (每次一张, 最多4MiB) that imply how to call it repeatedly for multiple images, but never says when to prefer this over download_article_images or read_wechat_image, nor that an article_id must come from a prior fetch/get_saved_article call.

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 already establish read-only, non-destructive, closed-world behavior, so the bar is lower; the description still adds real value by disclosing that it returns only nested text currently retrievable from the database and explicitly flags whether the record is the complete original. This partial-data warning is exactly the kind of behavioral context annotations cannot convey.

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 resource stated first, then the invocation key, then the return semantics. No filler, though the semicolon-joined second clause bundles key and return behavior together.

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?

Return-value semantics are well covered (nested text plus completeness flag) even without an output schema, and the read-only profile is clear. However, the two optional parameters are undocumented anywhere, so an agent cannot know what max_queries or keyword_hint do.

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 0% across 4 parameters, so the description must compensate. It identifies session_id + local_id as the lookup key but adds no format details, and leaves max_queries and keyword_hint entirely unexplained in both schema and description.

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: read one WeChat merged-forward chat record. No sibling tool covers merged-forward records, so the resource is inherently distinct, though the description never explicitly contrasts itself with the messaging siblings (search_messages, get_message_context, read_wechat_post).

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 names the required identity pair (session_id + local_id) but gives no when-to-use versus when-not guidance and no alternatives. Nothing tells the agent when a merged-forward read is preferred over, say, analyze_wechat_chat or get_message_context.

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?

The description adds a behavioral note that it does not rescan WeChat, which is useful context beyond annotations. However, annotations set readOnlyHint to false, implying possible side effects, but the description does not disclose any such effects (e.g., marking items as read). This is a transparency gap.

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 concise, front-loaded with the main purpose, and delivers the key behavioral note in a short second clause. It wastes no 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 parameter explanations, the description is incomplete. It does not describe what the tool returns, how to obtain or use the nextOffset, or what id and batch_id represent. For a pagination tool, this is insufficient.

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 0%, so the description must explain parameters, but it does not. It mentions 'nextOffset' which is not a schema parameter (offset is), and provides no meaning for id, batch_id, limit, or offset. This fails to compensate for the schema gap.

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 clearly identifies the action (continue reading) and resource (multi-group watchlist batch), and adds a distinguishing note that it does not rescan WeChat. This differentiates it from scanning-related tools, though it does not explicitly contrast with sibling read tools like get_recent_messages.

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 implies usage for paginating through watchlist batches but does not state when to use this tool over alternatives such as poll_watchlist or ack_watchlist_batch. There are no explicit exclusions or conditions.

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 already indicate readOnlyHint and destructiveHint, so the safety profile is covered. The description adds genuine behavioral disclosures beyond that: it explicitly states encrypted DAT files are not decrypted ('加密DAT不解密') and that the path does not prove session ownership ('路径不证明会话归属'). These are warnings about the tool's limitations that an agent would not otherwise know, justifying a 4.

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?

One dense sentence with three distinct clauses, each earning its place: the action/return, the path constraint, and the behavioral caveats. Information is front-loaded with the core function first, followed by the necessary restrictions. No filler or repetition.

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 tool with one parameter and no output schema, the description covers the key operational constraints (whitelist path, no decryption, session attribution caveat). It could mention error behavior for invalid paths, but that is a minor gap given the simple scope and the standard MCP image return type.

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 coverage is 0%, so the description must carry the meaning of source_path. It does so by defining it as a local WeChat standard image path inside the whitelist ('只能使用本地附件白名单路径'). It doesn't detail path format or error handling, but given a single simple parameter, this is adequate and clearly compensates for 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?

The description states a specific verb (读取/read) and resource (本机微信标准图片, local WeChat standard image) and clarifies it returns a native MCP image. The constraints on path whitelist and encryption disambiguate it from sibling read tools like read_article_image or read_merged_forward, making its scope clear without opening schemas.

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 gives a concrete usage rule: '只能使用本地附件白名单路径' (only use local attachment whitelist paths), which tells the agent what inputs are acceptable. It implies this is for standard WeChat images rather than article images or merged forwards, but it stops short of explicitly naming alternatives or when-not-to-use scenarios, so it earns a 4 rather than a 5.

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?

Beyond the annotations (read-only, non-destructive, closed-world), the description discloses source preference (database body first) and a key limitation (external URLs are not fetched). This adds meaningful behavioral context, though it stops short of describing fallback behavior or return format.

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 short, front-loaded with the core purpose, and contains no filler. It loses a point because, with zero schema descriptions, slightly more parameter or usage context would make the compactness better earned.

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 0% schema coverage, the description alone must carry parameter and return-value semantics. It covers data-source behavior well but leaves the meaning of all four parameters and the result shape unstated, making it minimally viable rather than 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 0% and the description adds no parameter-level meaning. Property names like session_id, local_id, max_queries, and keyword_hint provide partial clues, but nothing explains how they map to selecting or retrieving the post.

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 ('read') and a specific resource ('posts, articles, link cards, or long text in WeChat chat'). It also differentiates from network-fetching siblings by explicitly saying it returns database-retrievable body text rather than crawling external pages.

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 gives useful context: it is for stored or database-backed WeChat post content and explicitly says external pages are not auto-fetched. However, it never names alternatives such as fetch_wechat_article or states a clear when-to-use versus when-not-to-use rule, so routing is mostly implied.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: per-group failure reporting, coverage range, and resume offset, plus the explicit scope limitation of only scanning specified sessions. This exceeds the annotation baseline without contradicting it.

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 two compact sentences that front-load the main purpose, use case, and key constraint. Every clause carries information with no redundancy, making it highly efficient.

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 10 parameters, no output schema, and only 0% schema description coverage, the description is incomplete. It explains the main filtering logic but omits semantics for offsets, context windows, and per_session_limit, and does not describe the full response structure beyond failures, coverage, and offset. An agent would need to infer or experiment to use it correctly.

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 0%, and the description only hints at a subset of parameters. It mentions time, keywords, any/all, and sender IDs, which maps to start_time, end_time, keywords, match_mode, and sender_ids, but leaves offsets, context_before/after, per_session_limit, and session_ids unexplained. Given 10 parameters and no schema descriptions, the description should compensate more comprehensively.

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 (batch read), resource (specified sessions), and filtering dimensions (time, keyword any/all, sender ID). It also distinguishes itself from siblings by explicitly noting it does not scan unspecified groups, making its scope unmistakable.

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 provides a clear use case ('multi-group topic, information, and resource aggregation') and a constraint ('does not scan unspecified groups'), implying when to choose this over broader search tools. It stops short of naming specific alternative tools, but the context is sufficient for an agent to infer its niche.

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 already declare readOnlyHint=true and destructiveHint=false, so the operation is known to be safe and non-destructive. The description adds useful scoping context ('可限定会话和时间范围') but does not disclose other behavioral aspects such as pagination, default limits, or whether results are ordered, which are not covered by 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?

The description is a single concise sentence with no filler. The core capability is front-loaded, and the optional constraints are stated naturally. It is as short as possible while still conveying the primary purpose and main filtering dimensions.

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 tool with 12 parameters, no output schema, and zero schema description coverage, this description is far too thin. It gives a minimally viable search invocation but omits return-value expectations, pagination defaults, filter interactions, and context-window behavior, making it insufficient for reliable tool selection and correct calling in complex cases.

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 0%, so the description must compensate, but it only glosses over three concept areas: keyword, session, and time range. It does not clarify the relationship between date and start_time/end_time, the meaning of sender_id, text_only, message_types, context_before/after, or context_scan_limit, leaving most of the 12 parameters underspecified.

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 clearly identifies the action ('按关键词搜索') and the resource ('微信聊天记录'), while also noting optional scoping by session and time range. This distinguishes it from sibling tools like get_recent_messages, get_messages_by_sender, and search_wechat_attachment_text, which target different resource types or operations.

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 implies when to use the tool: when searching chat messages by keyword with optional session/time filters. However, it does not explicitly state when not to use it or mention any alternatives, such as get_message_context or search_wechat_attachment_text, leaving some routing decisions to inference.

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?

Beyond the readOnlyHint=true annotation, the description adds important behavioral context: it does not guarantee complete history and it returns a search redirect link that must be opened in a browser for verification. This is a key limitation an agent must know before calling, and it goes beyond what annotations provide. No contradiction with 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?

The description is two sentences, front-loaded with the purpose and source, then caveats. It is efficient with no filler. The structure is clear, though it could be slightly more organized with explicit parameter mentions.

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 tool with 5 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not explain pagination (page), the exact format of time filters, or the structure of the returned redirect link (e.g., how to follow it). An agent would need to infer several details, making the description insufficient for reliable 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 0% schema description coverage, the description must compensate for all 5 parameters. It mentions filtering by account name (account_name) and search index time (start_time/end_time), but it does not explain the 'page' parameter or the nature of the required 'query' beyond its obvious meaning. This partial coverage leaves several parameters underspecified for the agent.

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 clearly states the verb 'discover' and the resource 'WeChat articles via Sogou's public index'. It specifies the source, which helps distinguish it from sibling tools like search_wechat_articles_tencent, though it doesn't explicitly name alternatives. The filtering capabilities are mentioned, adding clarity, but the description doesn't differentiate it from the batch variant.

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 implies this is for searching WeChat articles through Sogou's index but provides no guidance on when to choose this tool over siblings like search_wechat_articles_batch or search_wechat_articles_tencent. It also doesn't mention any exclusions or prerequisites, leaving the agent without routing information.

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 already declare readOnlyHint=true and destructiveHint=false, but the description adds real behavioral context beyond them: cross-query and cross-page deduplication, retained source counts and run records, failure boundaries, and the caveats that results require original-text verification and history may be incomplete. These are non-obvious traits that materially shape how an agent should treat the output.

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 with the discovery behavior front-loaded, followed by caveats. Every clause carries information, though the run-on structure packs several distinct ideas together, slightly reducing readability.

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 tool with no output schema, safety is covered by annotations and return-value explanation is not needed. However, with six undocumented, all-optional parameters and no usage gating, the definition leaves meaningful gaps about what to pass and when this tool beats its many siblings.

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 0% across 6 parameters, and no parameter is required. The description only loosely gestures at query terms and paging ('多个查询词和分页结果') while saying nothing about account_name, start_time/end_time, or the max_pages cap. It does not compensate for the coverage gap.

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: multi-round discovery of WeChat public-account articles, with batch behavior implied by '多个查询词' (multiple query terms). However, it does not explicitly distinguish itself from the sibling search_wechat_articles or search_wechat_articles_tencent beyond the name-level 'batch' prefix, so sibling differentiation relies on inference.

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, and no alternative tools are named. The multi-query framing implies a batch scenario, but the agent must infer that this tool is preferred over search_wechat_articles for multi-term coverage rather than being told.

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 already mark this as read-only and non-destructive, and the description adds meaningful behavioral context beyond that: credential pre-configuration, potential Tencent Cloud charges, no guarantee of full public-account history, and no automatic fallback to free search. These details directly inform agent expectations and invocation decisions.

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 compact but information-dense, front-loading the core function and scope before layering in prerequisites, costs, and limitations. Every clause adds necessary context; there is no filler or repetition of schema information.

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?

Given two simple parameters, no output schema, and the real-world complexity of a paid, credential-gated external search, the description covers the essential operational facts: result shape, time scope, credentials, billing, historical coverage limits, and fallback behavior. An agent has enough context to decide whether to invoke it and what to expect.

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 schema has 0% description coverage, so the description must compensate. It clarifies that 'days' represents a recent-N-day window and that the search is scoped to WeChat official-account domains, but it does not explicitly explain the 'query' parameter beyond what the tool name and schema constraints imply.

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 (search) and resource (WeChat public-account articles via Tencent Cloud WSA), and adds clear scope constraints: restricted to official-account domains, recent N days, returning candidate URLs and images. It also differentiates itself from the free search by explicitly stating it will not automatically switch from free search.

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 conveys when this tool is appropriate: when an official Tencent Cloud WSA search is desired, within a recent time window, and when credentials are already configured. It warns that it will not automatically fall back to free search and that full history is not guaranteed, implicitly steering agents away when free or broader search is required. It does not name a specific sibling alternative, so it stops short of fully explicit routing.

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 already declare readOnlyHint=true and destructiveHint=false. The description adds specific reassurance that the scan does not modify WeChat files or the database, which gives concrete behavioral context beyond the generic annotations. No contradiction exists.

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 that states the action first and the safety guarantee second. There is no redundant wording or 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?

With no output schema and no parameter descriptions in the schema, the description is too thin. It explains what the tool searches but not the optional filtering parameters, result shape, or any usage details an agent would need beyond the required keyword.

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 0%, so the description must compensate. It only clarifies the keyword concept, while limit, scan_limit, extensions, start_time, and end_time remain semantically undefined, including timestamp units and the distinction between limit and scan_limit.

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 uses a specific verb and resource: 'search keyword in the content of WeChat's downloaded local files.' This clearly distinguishes it from sibling tools like search_messages or extract_wechat_attachment_text, since it targets full-text search over local attachment content.

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 gives clear context for use: search keyword text inside locally downloaded WeChat files. It does not explicitly name sibling alternatives or state when not to use it, but the context is direct and unambiguous enough for an agent to know when this tool applies.

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?

The description adds context beyond the readOnlyHint=true annotation by mentioning '解析器可用性' (parser availability) and '安全边界' (security boundaries), which are behavioral facets of the extension. However, it does not explain what those boundaries are or how the returned data behaves (e.g., format, dynamic nature), so the disclosure is useful but shallow.

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 entire description is one short sentence that states the purpose without filler words. It is front-loaded with the verb and directly lists the three components of the return value, making it efficiently scannable for an agent.

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 parameterless tool with no output schema, the description must convey what the agent can learn from the result. It mentions capabilities, parser availability, and security boundaries, but lacks concrete detail about the structure or content of the response (e.g., what capabilities are listed, what parser statuses exist). Given the complexity of the sibling tools and the absence of an output schema, a bit more detail would improve completeness.

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 fully covered (100%). With only an empty properties object, there is no parameter semantics to describe, so the base score is 4 as per the rule for parameterless tools.

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 clear verb ('returns') and specific resources ('capabilities', 'parser availability', 'security boundaries'), which sets it apart from siblings that list messages, contacts, or sessions. It is not perfectly concrete about what these capabilities entail, but the intended purpose is unambiguous.

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 offers no guidance on when to call this tool versus alternatives, nor does it mention any conditions or exclusions. It only states what it returns, leaving an agent to infer it is a capability-check tool. No exclusions, prerequisites, or alternative tool routing is provided.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds helpful context that it checks configuration, connectivity, and parser availability, and that it does not require WeChat to be running, but it does not explain outputs, error cases, or effects beyond inspection.

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 compact sentence that front-loads the diagnostic scope and then adds the key operational condition. Every part contributes information, with no filler or repetition.

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 diagnostic tool, the description is sufficiently complete to invoke it: it names what is checked and notes that it runs without WeChat open. It could mention what the result looks like, but no output schema exists and the complexity is low, so this is a minor gap.

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 in the schema, so the description does not need to explain parameter meaning. Per the baseline for zero-parameter tools, a score of 4 is appropriate; no parameter information is missing.

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 diagnostic action ('检查' / check) against concrete resources: Yan's configuration, WxLens connection, and optional parsers. This clearly separates it from sibling tools that read messages or articles, since it is the only diagnostic tool.

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 gives one useful usage condition—it can run even when WeChat is not open, implying it works as a preflight diagnostic. However, it does not explicitly state when to prefer this tool over alternatives or what circumstances should trigger its use.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the payload is guidance text aimed at clients lacking resources/prompts support, which is useful context, but says nothing about the size, language, or structure of the returned guide.

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 verb and enumerates the covered topics, then closes with the client-condition. No padding, though the long topic list is dense and could be trimmed without losing meaning.

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 guidance tool with no output schema, the description conveys what the guide covers and who it is for, which is enough to invoke it correctly. It could go one step further by noting that the response is prose documentation so an agent knows to read rather than parse structured data.

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 no parameter semantics to explain and the baseline is 4. Nothing in the description misrepresents the empty input schema or implies hidden arguments.

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: it returns a guide covering tool selection, person extraction, multi-group monitoring, summarization workflow, and source citation. That is far more informative than a tautology, but it never names or contrasts with the closest sibling (wechat_reader_capabilities), so sibling differentiation is left to inference.

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 an explicit audience/trigger: AI clients that do not support MCP resources/prompts, implying the alternative (native resources/prompts) should be used when available. It stops short of saying when this is unnecessary in an MCP-capable client or how it relates to wechat_reader_capabilities.

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