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

No annotations are provided, so the description carries the full behavioral burden. It hints at read-only polling by describing a 'check' that returns unread sessions, but it never states whether calling it clears/marks messages as read, what the time window is, or how it interacts with server-side state — a critical ambiguity for a message-checking tool.

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

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

A single front-loaded sentence stating the action and the return payload, with no filler. It is efficient, though slightly terse given the side-effect questions it leaves open.

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?

An output schema exists, so return values need not be described, and the zero-parameter schema is trivial. What remains missing is the side-effect/refresh semantics (does checking consume unread state, and over what window), which matters for a message-polling tool with no annotations.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. No parameter meaning is missing or misstated.

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 gives a specific verb+resource (check new messages in the session list) and states what is returned (unread sessions with their latest content). It does not explicitly differentiate itself from the close sibling wechat_get_recent_sessions, 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 purpose implies a polling/refresh use case, but there is no explicit guidance on when to call this instead of wechat_get_recent_sessions or wechat_get_chat_history. Usage is inferable from the wording rather than stated.

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 no annotations, the description carries the full behavioral burden. It usefully discloses one failure mode (expired/undownloaded files cannot be exported), which is real value beyond the schema, but it says nothing about local write behavior, permissions, or whether an export is idempotent. Output schema exists, so return values need not be covered.

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 core action front-loaded and the caveat placed in a parenthetical at the end. Nothing is wasted, though the brevity leaves room for a routing hint at no real cost.

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 three-parameter file-export tool with full schema coverage and an output schema, the description covers the essential action and one important constraint. It omits sibling differentiation and any note on the side effect of writing files to disk, which leaves gaps an agent must resolve elsewhere.

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

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

Schema description coverage is 100% and all three parameters (number, to_user, target_folder) are documented inline with defaults and exact-match semantics for to_user. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (导出/export) and resource (聊天文件/chat files) plus the destination (本地目录/local directory), which clearly separates it from sibling readers like wechat_get_chat_history. It does not explicitly name a sibling, but the verb+resource combination 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?

Usage is implied by the verb and the friend-scoped framing, and the parenthetical adds a failure condition (expired/undownloaded files cannot be exported). However, it never states when to prefer this over wechat_get_chat_history or wechat_send_files, so the agent must 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?

With no annotations, the description carries the full burden and largely meets it: it discloses the internal strategy (scroll back until the target date is covered, then filter by date) and the return ordering (ascending by time). It omits preconditions that matter for a UI-driven WeChat tool, such as the client being logged in/running, expected latency, or whether it mutates anything.

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: purpose first, mechanism second, tuning tip last. Nothing is wasted and the most important information is front-loaded, which is exactly the right shape for a frequently-scanned tool description.

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 a full output schema and 100% schema coverage, the description supplies the missing behavioral layer (retrieval algorithm, ordering) that structured fields cannot express. The remaining gap is sibling disambiguation against wechat_search_chat_history, which is the one thing an agent could still get wrong.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including max_messages, search_pages and group_members. The description's only parameter note (raise max_messages for older dates) duplicates what the max_messages schema field already says, so it adds no new semantics – baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: retrieve chat records for a named friend or group on a specific day, with scope bounded to a single date. That is clear enough to act on, but it never distinguishes itself from the close sibling wechat_search_chat_history, so the agent must guess which retrieval tool applies.

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 artifact ('get a day's history for X'), with no explicit when-to-use framing and no mention of alternatives such as wechat_search_chat_history or wechat_get_recent_sessions. The one piece of practical guidance offered – increase max_messages for older dates – is tuning advice rather than usage 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?

With no annotations, the description carries the full behavioral burden, yet it discloses nothing about pagination, rate limits, auth requirements, or ordering. It adds the category list, but that information is already in the schema, so no genuine behavioral context is contributed.

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 no filler or redundancy. It is appropriately sized, though it stops short of earning a 5 because the sentence spends its words re-listing categories already present in the schema rather than adding new guidance.

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?

An output schema exists, so return values need not be described, and the schema covers all three parameters. However, with no annotations and no usage guidance, the definition leaves the read-only nature, pagination behavior of limit, and the group-contacts overlap with siblings unaddressed.

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

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

Schema description coverage is 100%, so the schema already documents kind, limit, and detail thoroughly. The description's category enumeration merely restates the kind values (friends/groups/公众号/服务号/企业微信) without adding format, default, or interaction semantics. Baseline 3 applies when the schema does the heavy lifting.

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 (通讯录) and enumerates the contact categories, so the agent knows exactly what data comes back. It is clear enough to distinguish from send_* siblings, but it never addresses the overlapping wechat_get_group_members sibling, leaving boundary ambiguity for the group-contact case.

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 indication of when to use this tool versus alternatives. Given that wechat_get_group_members also returns group-related contacts and wechat_get_recent_sessions covers chats, the definition should have stated the routing condition but does not.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation through '获取' but does not describe authentication requirements, error behavior, rate limits, or pagination/scrolling behavior. Since an output schema exists, return values need not be explained, but the behavioral profile remains largely undisclosed.

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

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

The description is a single, front-loaded sentence that states the tool's purpose without unnecessary words. For a simple retrieval tool, this is appropriately sized and structurally efficient.

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

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

The tool is simple, parameters are fully documented in the schema, and an output schema exists, so the description need not explain return values. However, with no annotations and no usage or behavioral context, the description is only minimally sufficient for correct invocation.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description does not add syntax, format, or meaning beyond what the schema provides, making the baseline score of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: retrieving the member nickname list for a specified group chat. This clearly distinguishes the tool from general contact or chat-history siblings by focusing on group members, but it does not explicitly name or contrast itself with any sibling tool. Thus it is clear but lacks explicit 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 only states what the tool does; it gives no guidance about when to use it versus alternatives such as wechat_get_contacts or wechat_get_chat_history. There is a weak implied use case when group member nicknames are needed, but no context, prerequisites, or exclusions are 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?

With no annotations provided, the description carries the full behavioral burden. It implies a read operation but discloses nothing about auth requirements, rate limits, failure modes, or whether the fetch is paginated. Notably, it omits the 'recent' default scoping that the schema uses, leaving behavior under-specified.

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

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

A single short sentence with no waste, but it is arguably under-specified rather than genuinely concise. Minimal front-loading is present since there is only one sentence.

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?

An output schema exists, so return values need not be explained, and the schema handles all three optional parameters well. However, the description omits usage context and behavioral notes that would round out a read tool with no annotations.

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

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

Schema description coverage is 100%, so all three parameters (number, recent, with_name) are already documented in the schema, including the default value and '较慢' performance note for with_name. The description adds no parameter-level detail beyond the baseline.

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 combination (获取/朋友圈), making it immediately distinguishable from wechat_post_moments. However, it doesn't explicitly name siblings or clarify how it differs from related reads like wechat_get_chat_history.

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 wechat_get_recent_sessions or wechat_get_chat_history. No prerequisites (e.g., login state) or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the shape of returned items (name, last message, time), but says nothing about ordering, pagination, or scope limits, and gives no explicit read-only/side-effect confirmation for an agent that might otherwise assume it touches messages.

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 return contents tucked into a parenthetical. Nothing is redundant and nothing needs to be moved earlier.

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 an output schema covering return values and full schema coverage on both parameters, the core call information is present. What is missing is usage context relative to the many read siblings (check_new_messages, get_chat_history), which leaves the agent to guess at routing.

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

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

Schema description coverage is 100%: both 'recent' (with its English/Chinese time-range values) and 'chat_only' are fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (获取) and resource (会话列表中的最近会话) and even names the returned fields (名称、最后一条消息与时间). It is clearly distinguishable from write-oriented siblings, though it does not explicitly separate itself from the closest read siblings like wechat_check_new_messages or wechat_get_chat_history.

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 when-to-use statement, no prerequisites, and no mention of alternatives. The agent must infer that this is the tool for browsing the recent session list rather than for fetching message content.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only 'get' operation with no side effects, but never states this explicitly, nor does it note sensitivity of the disclosed server config/wxid or any rate limits.

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 that names the tool's output fields first and the usage context last. No redundant or filler content.

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?

An output schema exists, so return-value documentation is not required, yet the description still summarizes the payload (version, wxid, data dir, server config). For a zero-param diagnostic tool this is essentially complete; only the read-only/no-side-effect guarantee is 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies for a parameterless 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 names a concrete verb (获取) and enumerates the specific resources returned: WeChat version, wxid, data directory, and server configuration. This clearly separates it from the sibling messaging/contact/moments tools, though it doesn't name a sibling 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 trailing phrase '用于排障' (for troubleshooting) gives an implied use context, so the agent knows this is a diagnostic call rather than a routine data fetch. However, no alternatives or when-not-to-use conditions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing beyond the bare action. It does not say the post is publicly visible to contacts, whether it is reversible/deletable, whether login/permission is required, or how media paths are validated.

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

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

A single short sentence that front-loads the action and stays tight with no filler. It is efficient, though so terse that conciseness shades into under-specification.

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 publish/mutation tool with zero annotation coverage, the description is too thin. The output schema removes the need to explain return values, but the absence of any behavioral, permission, or reversibility context leaves meaningful gaps.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, and the description merely echoes them as (文案 + 图片/视频). Baseline 3 applies since the schema does the heavy lifting and the description adds no format or constraint detail.

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 (发布/publish) and resource (朋友圈/Moments), and the parenthetical clarifies the payload is text plus media. An agent can distinguish it from the read counterpart wechat_get_moments by the verb alone, though it never names that sibling 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. The posting intent is only implied by the verb; nothing tells the agent when this is preferable to another tool or what prerequisites exist.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the search semantics implied by the name. It does not state that the operation is read-only, that results are limited/sorted, or what permissions are needed. The only behavioral hint (global scope) is minimal for a tool with zero annotation coverage.

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. It is efficient, though arguably undersized for a tool with no annotations and multiple 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?

An output schema exists, so return values need not be described, and parameters are covered by the schema. However, with no annotations the description should still convey more (read-only nature, result behavior, relationship to wechat_get_chat_history) than it does.

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

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

Schema description coverage is 100%, so keyword, number, and with_content are already fully documented in the schema. The description adds no format, syntax, or matching-rule detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (搜索/search), resource (聊天记录/chat history), and scope (全局/global, 用关键字/by keyword). The 'global' qualifier implicitly distinguishes it from wechat_get_chat_history, but the sibling is never 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 word '全局' hints at when this is appropriate (cross-conversation lookup) versus a single-chat fetch, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is only inferable from the scope adverb.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only the 1GB per-file limit — which is already repeated in the schema's files parameter — and says nothing about prerequisites (WeChat must be running/logged in), failure behavior, rate limits around the delay parameter, or whether sending is retried. For a write/action tool with zero annotation coverage this is a significant 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?

A single front-loaded sentence stating the verb, scope, and constraint with no filler. It is not under-padded to the point of being cryptic, but it also omits any routing or prerequisite information that would have earned space.

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?

An output schema exists, so return values need not be described, and the schema fully documents all 5 parameters. However, for an unannotated mutation tool, the description omits prerequisites, failure modes, and any hint about file-type or path validity, leaving gaps an agent would want before invoking 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 description coverage is 100%, so every parameter (files, to_user, messages, messages_first, delay) is already documented in the schema, setting the baseline at 3. The description adds no format or syntax detail beyond what the schema provides; the 1GB note duplicates the files parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (发送) and resource (本地文件) plus the recipient scope (单个好友或群聊) and a key constraint（单个文件需小于 1GB）。An agent can distinguish it from wechat_send_message and wechat_send_multiple_messages, 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 recipient scope (single friend or group chat, as opposed to multiple friends) implicitly signals when this tool applies, but there is no explicit when-to-use, when-not, or named alternative such as wechat_send_message for text-only sending.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about the fact that this sends an irreversible real message to a real contact, what happens if the name matches multiple contacts, whether a WeChat login is required, or rate limiting. Only the schema's incidental note about >2000-character messages becoming txt files adds 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?

A single front-loaded sentence with zero filler; the scope qualifiers appear before any call to action.

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?

An output schema exists so return values need no explanation and parameters are fully documented, but for a side-effecting outbound-message tool with no annotations the description omits preconditions, ambiguity handling for name matching, and failure behavior — gaps an agent needs before calling 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 description coverage is 100% — to_user, message, delay and search_pages all carry their own descriptions including the 2000-character behavior and the meaning of search_pages=0. The description adds no parameter semantics beyond that, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (发送一条消息) plus scope qualifiers (单个好友或群聊、一条) that directly contrast with siblings like wechat_send_multiple_messages and wechat_send_to_multiple_friends. An agent can pick this tool over those siblings without opening any schema.

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

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

The words 单个 and 一条 imply the single-recipient, single-message case and thus hint that bulk sends belong to the sibling tools, but no alternative is named and no prerequisites (e.g. must be logged in) are given. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only says messages are sent consecutively, without covering delivery timing, ordering guarantees, rate limits, authentication needs, or failure behavior, though the schema does document a delay parameter.

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

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

The description is a single, front-loaded sentence with zero wasted words. It clearly and efficiently conveys the core purpose without 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 tool with four parameters and no annotations, the description is too sparse. While an output schema exists so return values need not be explained, behavioral details such as what 'consecutive' means operationally, how the delay works, and how search_pages affects the send are left entirely to the schema or omitted.

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

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

Schema description coverage is 100%, so all four parameters are already fully documented in the input schema. The description adds no additional parameter meaning beyond what the schema provides, matching the baseline score for high-coverage schemas.

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 (多条消息) with a clear scope constraint (单个好友或群聊). It implicitly distinguishes itself from the sibling wechat_send_to_multiple_friends (multiple recipients) and wechat_send_message (single message), but does not name either alternative 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?

Usage is only implied: use this tool when sending multiple messages to one chat. The description offers no explicit when-to-use guidance, no prerequisites, and no direct comparison to the single-message sibling wechat_send_message.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that both unified and separate sending modes are supported, but it omits critical side-effect context such as required login state, rate limits, error handling for individual recipients, or that messages are actually sent and cannot be undone.

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 redundant or filler content. Every part of the sentence contributes to stating what the tool does and its two sending modes.

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 schema is rich and an output schema exists, the absence of annotations places a heavier contextual burden on the description for a side-effecting send operation. The one-sentence description does not cover authentication needs, failure modes, rate limiting, or safety caveats, leaving important context missing for an agent calling a messaging tool.

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

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

Schema description coverage is 100%, so the parameters to_user, message, and delay are fully documented in the schema. The description adds no additional parameter meaning or syntax beyond what the schema already provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: sending messages to multiple WeChat friends or group chats, and further specifies support for unified mass sending or separate sending. This distinguishes it from the single-recipient sibling wechat_send_message, but it does not explicitly name or contrast with other similar siblings like wechat_send_multiple_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 the use case (multiple recipients, either unified or separate messages) but provides no explicit when-to-use or when-not-to-use guidance, prerequisites, or named alternatives. An agent must infer from the sibling list that this tool is for multi-recipient sends rather than single sends.

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