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?

Annotations declare readOnlyHint=false and destructiveHint=false, and the description usefully adds that output lands in an exclusive local output/articles directory and that each image yields a SHA256 plus a missing-range report, plus the batch cap. It does not explain permissions or whether existing files are overwritten.

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 action and destination, then packs return shape and batch limits with no filler. Every clause carries information an agent needs.

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, the description dutifully describes results (per-image, SHA256, missing range) and destination. Minor gaps remain around indexing semantics and overwrite behavior, but the definition is largely self-sufficient.

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 supplies the otherwise undocumented default of the first 12 images when image_indices is omitted and the 20-image per-call maximum. It does not clarify the expected 1-based indexing or the SHA256 format of article_id, both of which the schema constrains silently.

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: downloading images of already-archived WeChat articles to a local directory. It clearly differs from read-oriented siblings like read_article_image and read_wechat_image by concentrating on batch local download.

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?

Implied that it operates on stored articles and gives defaults/caps (12 default, 20 max), but never states when to choose it over read_article_image or read_wechat_image, or any prerequisites for having an archived article first.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it reveals the tool performs heavyweight local processing (local ASR, keyframe OCR, timestamp evidence), which tells an agent this call may be slow/resource-intensive in a way the annotations do not.

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 core purpose before the format list, with no filler. The format enumeration is long but each item maps to a real capability, so it largely 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?

There is no output schema and 0% parameter documentation, so the description should carry the burden of explaining return shape and the offset/max_chars pagination contract. It explains neither, leaving an agent unable to know how to page through large attachments or what the extraction result looks like.

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% for three parameters, and the description names none of them. offset_chars and max_chars strongly imply character-windowed pagination, but the description never explains chunking, how to continue extraction, or what source_path accepts, so it 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?

States a specific verb (提取/extract) and resource (已下载微信文件正文或媒体证据) and enumerates the supported input types (documents, sheets, presentations, ebooks, text, ZIP, images, audio/video). This is far more specific than the bare name, though it never names the close sibling search_wechat_attachment_text to differentiate reading vs. searching.

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 '已下载微信文件' implies a precondition (the attachment must already be downloaded) which is useful context. However, there is no explicit when-to-use guidance, no exclusion criteria, and no routing to the obvious alternative search_wechat_attachment_text or list_wechat_attachments, leaving selection 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?

Adds meaningful behavioral context beyond the annotations: it discloses network access, stops when verification/login is encountered, and describes candidate verification with conflicting marking. It does not contradict the annotations, and it gives useful caveats that annotations alone would 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?

Two concise sentences with the core function front-loaded, followed by the critical failure mode and optional-parameter behavior. No filler or redundant 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?

Covers the main outputs (article body, image list, publish time), the failure mode (verification/login stops), and optional candidate_id behavior. However, it lacks detail on the return structure and how candidate_id is obtained or used in workflow, and there is no output schema to fill that 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. It explains candidate_id semantics reasonably (account-name verification and conflict marking), but the required url parameter has no explicit format or meaning beyond the general 'read article online' context.

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: '联网读取公众号文章正文、配图清单与发布时间' (read article body, image list, publish time online). This is clear and distinguishes online fetching from saved/local variants, though it does not explicitly name a sibling 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?

No explicit when-to-use guidance or alternative routing. It implies online use and mentions a candidate verification flow, but it never tells the agent when to prefer this tool over read_wechat_post, get_saved_article, or search_wechat_articles.

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=false, so safety is covered. The description adds genuinely non-redundant behavior: content is returned without character truncation and can be resumed via nextOffset, which tells the agent to expect paged, complete content rather than a clipped snippet.

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 no filler, which is appropriately sized. However it leads with the mechanism (bounded re-query) rather than the action, and contains a garbled phrase ('眼提供') that obscures what content is being returned.

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 5-parameter tool with no output schema and no parameter descriptions, the definition is too thin: scan_limit's role, page_size limits, and the relationship between offset and nextOffset are never explained. The only return-related information is that a content field comes back untruncated.

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 all five parameters, but it only addresses session_id, local_id and (implicitly) offset via nextOffset. page_size and scan_limit are left entirely unexplained, and the description does not say what nextOffset maps to in the 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 action (bounded re-query / fetch of a message's content) scoped to a single session and a stable localId, so the agent knows it retrieves one message rather than searching. It does not name a sibling, but the 'single session + stable localId' framing already separates it from search_messages and get_message_context.

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 only implied: the mention of a stable localId hints you need a known id, but there is no when-to-use, when-not-to-use, or named alternative among the many message-reading siblings. An agent must infer the precondition that a localId was already obtained elsewhere.

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 discloses meaningful behavioral details beyond the annotations: it does not execute scripts and does not request cookies. These reassurances are valuable given the lack of readOnlyHint. However, it does not state what happens after import, such as storage side effects or return 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?

The description is a single, tight sentence that front-loads the core actionholiday, then adds safety constraintsaba, then mentions the optional parameter. It has no redundant wording, though it could be slightly more structured for 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?

The description provides enough for a basic call: required HTML plus optional candidate_id. However, with no output schema, it does not describe what the tool returns, and it leaves partial undefined. For an import operation, this is a noticeable gap in 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?

Schema description coverage is 0%, so the description carries the burden for explaining parameters. It explains candidate_id's purpose, but the required fields url and html are left entirely to inference, and partial is not mentioned at all. The description only partially compensates for the missing 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?

The description clearly states the action: importing article HTML that has already been opened in the user's or AI browser. It also distinguishes itself from sibling fetch tools by emphasizing the 'already opened' source and the optional candidate_id verification, though it does not name a specific 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 gives clear context for when to use this tool: when article HTML is already available from an opened page, as opposed to fetching fresh content. It does not explicitly list exclusions or alternative tools, but the 'already opened' condition effectively routes away from fetch_wechat_article and similar 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, so the safe read-only nature is covered. The description adds valuable behavioral context about the data semantics: that 'candidate' is not original-verification and 'verified' only means local verification passed, not full history. This helps the agent interpret results correctly beyond 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 two short sentences, with the core purpose front-loaded in the first sentence and semantic clarifications in the second. Every word earns its place, with no redundant 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, the description is incomplete for a list tool. It doesn't specify the return format, fields of returned items, pagination, or sorting behavior. An agent can infer some behavior from the name and schema, but critical details are missing.

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 two parameters (limit and status). It only indirectly clarifies two of the four status enum values ('candidate' and 'verified') but does not explain 'conflicting' or 'unknown', nor the limit parameter. The description adds minimal value over the raw 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 clearly states the tool reads the WeChat official account candidate ledger ('读取公众号候选账本'), naming the specific resource and action. It adds semantic differentiation by clarifying that 'candidate' and 'verified' have specific meanings, which helps distinguish from other tools like query_article_history, though it does not explicitly name sibling tools.

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 such as query_article_history, get_saved_article, or update_article_candidate. It does not mention exclusions or preferred contexts, leaving the agent to infer usage solely from the tool 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 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?

The description adds meaningful behavioral context beyond the readOnlyHint and destructiveHint annotations: it only returns previously collected local articles, not complete account history, and indicates that biz is preferred over name during filtering. This prevents a likely misuse of the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences with no filler. The core filtering action and criteria are front-loaded, and the crucial scope limitation follows immediately. Every phrase 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?

Although the primary purpose and key limitation are clear, the tool has five optional parameters and no output schema. The description does not clarify identity_status, time range formatting, or what the returned article objects contain. For a query tool with zero schema descriptions, more context is needed 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?

Schema description coverage is 0%, so the description must compensate for explaining parameters. It explains account_biz, account_name, and general time filtering, but omits identity_status entirely and does not specify the format or semantics of start_time/end_time. This leaves a meaningful gap for an agent choosing 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 clearly states the tool's function: filter locally fetched articles by account biz (prioritized) or name and publish time. It also explicitly distinguishes itself from a complete official-account history, which helps disambiguate it from sibling search tools.

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 '仅为已收集历史，不是完整公众号历史' provides a clear when-not-to-use condition: this is not the tool for authoritative or full history. However, it does not explicitly name an alternative tool, so it falls just short of full 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?

Annotations cover the safety profile (readOnly/openWorld/non-destructive), and the description adds real behavioral context beyond them: the return is an MCP image block, calls are one-at-a-time, payload caps at 4MiB, and the index bound is deliberately raised past the legacy 100-image limit. That last note preempts a plausible false assumption.

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 short sentences, front-loaded with the action and return type, then constraints. Every sentence carries information; the only minor overhead is the slightly verbose framing of the legacy-limit rationale.

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, the description correctly states the return type and its size limit, and discloses the index-bound behavior — enough for an agent to invoke it. The unexplained article_id identifier format is the remaining 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 coverage is 0%, so the schema only gives types and a pattern. The description explains the meaning behind image_index's otherwise puzzling maximum of 200000 (4MiB page capacity) but says nothing about article_id being a 64-hex hash, leaving half the parameters unclarified.

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: read a single image from an archived WeChat article, returning a native MCP image block. It implicitly differentiates from live-image siblings (read_wechat_image) via '已存档', but never names an alternative, so no explicit sibling routing.

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 only implied by the 'archived article' framing and the 'one image per call' constraint. There is no when-to-use/when-not guidance and no pointer to download_article_images or read_wechat_image as alternatives for other cases.

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 safe read-only profile, so the bar is lower. The description adds real behavioral context beyond that: it discloses a two-phase lookup strategy, that only nested text visible in the current database is returned, and that it explicitly signals whether the record is the complete original — a meaningful completeness caveat.

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 purpose front-loaded and the retrieval strategy following. No wasted filler, though the internal-mechanism detail crowds out parameter explanation.

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 7 undocumented parameters, the description carries substantial burden. It does cover purpose, retrieval strategy, and return semantics (nested text + completeness flag), but leaves the pagination/scan parameters completely opaque, which is a clear gap for a tool with this many controls.

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 7 parameters, so the description must compensate. It only implies session_id, local_id, and keyword_hint; the pagination and scan-control parameters (offset, page_size, scan_limit, max_queries) are 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?

The description states a specific verb+resource: reading a WeChat merged-forward chat record (读取一条微信合并转发聊天记录). It is clearly distinguishable from siblings like get_message_by_id or read_wechat_post. It does not, however, explicitly contrast itself against those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the two-phase retrieval strategy (exact session_id + local_id lookup, then keyword variants), which tells the agent the tool handles merged-forward records specifically. But there is no explicit when-to-use/when-not guidance and no named alternative for non-merged messages.

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 signal readOnly, so the description does not need to restate safety. It adds real behavioral detail beyond annotations: encrypted DAT files will not be decrypted, and the supplied path does not prove conversation ownership. This is valuable context an agent needs before calling the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short, front-loads the core action and return type, and each sentence adds necessary information. There is no repetition of schema fields or annotation facts.

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, single-parameter, read-only tool, the description is mostly complete: it states what is returned and the key limitations around DAT files and session ownership. It could briefly mention expected source_path characteristics, but no output schema exists, so the stated return type is helpful.

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 does add meaning to source_path by specifying it should be a local WeChat standard image path and not an encrypted DAT path, but it does not describe path formats, allowed extensions, or how paths are resolved.

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'), the resource ('local WeChat standard image'), and the return type ('native MCP image'). It differentiates itself from related tools like read_article_image by restricting to WeChat standard images, though it does not explicitly call out sibling tools 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?

It provides useful context about what input paths are expected ('explicitly selected local WeChat standard image') and gives exclusions ('encrypted DAT is not decrypted; path does not prove session ownership'). However, it does not state when to prefer this tool over alternatives such as read_article_image or when a different tool would be more appropriate.

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 and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing the local index lookup strategy and reinforcing that no live web fetch occurs, giving useful behavioral context about what will and will not be returned.

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 focused sentences with the core purpose front-loaded, followed by the retrieval approach and boundary. No filler, though the external-page caveat partly restates the openWorldHint=false annotation.

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 7-parameter tool with no output schema and 0% schema description coverage, the description covers purpose, strategy and one boundary but leaves four pagination/query-limit parameters unexplained. It is adequate to select the tool but incomplete for invoking it confidently.

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 7 parameters, so the description carries the full burden. It does explain the role of the required session_id + local_id (exact back-lookup) and implies keyword_hint (关键词查询), but offset, page_size, scan_limit and max_queries remain entirely undocumented 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?

Names a specific verb (读取) and resource (帖子、文章、链接卡片或长文本 within WeChat chats), which is concrete enough to distinguish from sibling readers like get_message_by_id or fetch_wechat_article. It does not explicitly name which sibling to prefer in overlapping cases, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It describes a two-step retrieval strategy (exact session_id + local_id lookup, then bounded keyword index queries) and notes a boundary — external web pages are not fetched. However, it never states when to choose this tool over the many sibling article/message readers, leaving the agent to infer 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 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable context beyond them: results are written to a recoverable ledger and complete history is not guaranteed. This complements the openWorldHint and gives the agent concrete expectations about side effects and data completeness.

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 that front-loads the core purpose, then adds the two most important constraints (filtering and incomplete history). No redundancy, 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?

The description covers the essential purpose and key filtering behavior, but with no output schema it does not state the return format, how results map to the ledger, or how the agent should handle pagination. For a search tool with several siblings, more context about output structure and integration would be needed for full 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?

With 0% schema description coverage, the description carries full responsibility for parameter meaning. It explains account_name and the time-range filters ('search index time') but omits semantics for the required query parameter and the page parameter. Time units and pagination behavior are not mentioned, leaving significant gaps for a 5-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 clearly states a specific verb-resource relationship: 'discover article candidates through Sogou public WeChat index.' It identifies the source (Sogou) and the action (discover candidates), which distinguishes it from some siblings like search_wechat_articles_tencent. However, it does not explicitly name or differentiate against sibling tools, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for use: it is for discovering candidates via the Sogou public WeChat index, with optional filters by account name and index time. It does not explain when NOT to use this tool or directly compare against search_wechat_articles_batch/tencent, but the context is sufficiently scoped to guide selection.

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 transparently discloses operational behavior beyond the readOnlyHint annotation: request interval 1.2 seconds, max 12 calls per 45 seconds, captcha or 429/403 terminates the batch, candidates are written to a recoverable ledger, and complete history is not guaranteed. These specifics on rate limiting, failure handling, and recovery add substantial 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 a single dense sentence with semicolons, efficiently packing rate limits, failure modes, and ledger recovery. It front-loads the purpose and then specifies constraints. However, it omits core functional details, so while concise, it is not fully informative.

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 7 parameters, low schema coverage, and no output schema, the description is incomplete. It does not explain what the tool returns, how to structure a query, or how the batch process works. The focus on rate limiting and error handling overshadows the actual search functionality, leaving critical 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 only 14%, and the description provides no parameter explanations. It does not clarify the meaning of query, queries, start_time, end_time, max_pages, or account_name. The only parameter hint is in the schema itself for 'days'. The description adds no semantic value for parameters, leaving the agent to guess how to construct a valid call.

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 the tool performs '高强度多轮发现公众号文章' (high-intensity multi-round discovery of WeChat public account articles), which clearly indicates a batch discovery/search function. It distinguishes itself from siblings like search_wechat_articles by emphasizing multi-round and rate-limited operation. However, it does not explicitly state what the tool returns or how it relates to a search query, leaving the core purpose slightly implied rather than fully explicit.

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 explicit guidance on when to use this tool versus alternatives. It mentions rate limits and error handling but does not state scenarios where batch discovery is preferred over single-search tools like search_wechat_articles or search_wechat_articles_tencent. There is no mention of prerequisites, exclusions, or selection criteria.

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 states '结果写入候选账本' (results are written to the candidate ledger), which is a side effect that contradicts the annotation readOnlyHint=true. This is a direct conflict: the annotation declares the tool read-only, but the description indicates a write operation. Additionally, it mentions prerequisites, cost, and incomplete history, but these are secondary to the contradiction, which warrants a score of 1 and an annotation_contradiction flag.

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 purpose and then lists key constraints and caveats. Every clause adds information (scope, recency, prerequisites, cost, side effect, limitation). No redundancy 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?

The description covers critical operational aspects: prerequisites, cost, side effect (writing to ledger), and a limitation (not full history). However, it lacks details on the expected return value, how the candidate ledger is accessed, error handling, or how 'days' behaves when omitted. Without an output schema, the agent has incomplete information to correctly interpret results. It is adequate for a simple search tool but leaves gaps in operational details.

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 is the sole source of parameter meaning. It clarifies that 'days' corresponds to '最近N天' (last N days) and implies 'query' is the search term. However, it does not explain the optional nature of 'days', default behavior, or query format. The description adds useful context but leaves gaps about parameter interplay and expectations.

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 performs an official Tencent Cloud WSA search for WeChat articles, with explicit constraints on domain (WeChat public account) and recency (last N days). The phrase '可选' (optional) signals it is an alternative among sibling search tools, and the mention of 'WSA官方搜索' distinguishes it from generic search tools. The purpose is specific and 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 provides context that this tool is optional and requires the user to pre-enable and configure credentials, and may incur charges. However, it does not explicitly state when to prefer this tool over siblings like search_wechat_articles or search_wechat_articles_batch, nor does it mention exclusions. It gives enough context to infer it's a specialized path, but lacks direct comparison 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description repeats this safety profile with '只读扫描，不修改微信文件或数据库' but adds no behavioral context beyond the annotations, such as scan limits, performance, 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 a single, front-loaded sentence with no filler. It is efficient, though its extreme brevity contributes to gaps in usage and parameter guidance rather than earning its place fully.

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 7-parameter search tool with no output schema and zero schema description coverage, the description is far too thin. It does not explain how to use filters, time ranges, extension scoping, result limits, or what a search returns, making correct invocation largely guesswork.

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 7 parameters, and the description explains none of them beyond implying the required keyword. Parameters like limit, scan_limit, extensions, start_time, end_time, and max_chars_per_file are left 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?

The description states a clear verb ('搜索关键词') and resource scope ('微信已下载的本地文件正文'), which distinguishes it from message-search and article-search siblings. However, it does not explicitly name or contrast with the closest alternative, extract_wechat_attachment_text, so it falls short of full sibling differentiation.

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 no when-to-use guidance, no prerequisites, and no alternatives. It only describes the operation itself, leaving the agent to infer that this is for searching downloaded WeChat file contents rather than messages or articles.

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 says 'update' (a mutation) but annotations declare readOnlyHint=true, an outright contradiction. No other behavioral context (e.g., side effects, permissions) is provided. This directly violates the annotation.

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 extremely brief, with no fluff, and the main purpose is front-loaded. However, its brevity borders on under-specification, though conciseness itself is good.

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 6-parameter mutation tool with a contradiction, the description is severely incomplete. It omits parameter explanations, side effects, and any disambiguation with the read-only annotation. The only useful context is the verified-status condition, which 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It only clarifies when 'verified' is appropriate (a hint about the status enum). It does not explain candidate_id, reason, article_url, account_name, or published_at, leaving most parameters ambiguous.

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 ('update') and resource ('candidate'), and specifies the target column ('status'). It clearly distinguishes from sibling list_article_candidates by conveying a write action. The tool name reinforces the object being updated.

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 an explicit condition: only mark 'verified' after verification via browser or article tool. This is a clear when-to-do instruction. It does not name alternatives, but there is no competing update tool among siblings, so the guidance is adequate.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is structured. The description adds the non-obvious behavioral fact that it works without WeChat open, but says nothing about what it reports or any failure modes beyond that.

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 naming the three things checked, followed by the key runtime condition. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless diagnostic tool with annotations covering safety, the description covers what is checked and the notable 'no WeChat needed' condition. It stops short of describing the shape of the diagnostic result, which would help an agent interpret the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description does not introduce spurious parameter-like options.

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 (检查/diagnose) plus concrete resources: configuration, local service connection, and optional parsers. It is clearly a self-diagnostic tool, distinguishable by nature from the WeChat-reading siblings, though it does not explicitly name any sibling it contrasts with.

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 '即使没有打开微信也可运行' implies a troubleshooting/health-check use case that does not depend on WeChat being active, which is useful context. However, it does not state when to prefer this over alternatives or what conditions warrant running it.

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.