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

With no annotations provided, the description carries the full behavioral burden, and it does disclose two non-obvious traits: data comes from a buffer and the result count is capped by buffer capacity. It omits ordering, whether the buffer is live/truncated in normal operation, and any auth requirements, so the disclosure is partial rather than complete.

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 clauses, front-loaded with the core action, and no filler. It is efficient, though the buffer caveat could be tied more tightly to the limit parameter rather than standing as a trailing 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 formatting is not required in the description. For a simple two-parameter read tool this is nearly adequate, but the missing differentiation from get_recent_messages and unexplained limit parameter leave gaps an agent must guess at.

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 clarifies that chat_name is mandatory (the schema only marks requiredness without semantics) and hints that returned volume is bounded, which loosely relates to limit, but it never explains what the limit parameter does or its default.

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 (read the most recent messages of a designated chat), so the agent knows exactly what the tool returns. However, it never distinguishes itself from the sibling get_recent_messages, which appears to cover overlapping ground, leaving the selection ambiguous.

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 states a prerequisite — the chat name must be explicitly supplied — which is useful before calling. But there is no guidance on when to prefer this over get_recent_messages or how it relates to get_chat_info, so the usage context is only implied.

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

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

With no annotations provided, the description carries full behavioral burden. It describes the returned data fields but says nothing about permissions, rate limits, error behavior (e.g., unknown chat_name), or whether the operation is read-only. The phrase '已确认可获取的信息' hints at availability but does not disclose operational traits.

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 efficiently enumerates the returned information with zero wasted words. It is appropriately sized for a simple getter.

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 are already covered, making the description's field list somewhat redundant. The description does not address the required parameter chat_name or any behavioral aspects, leaving the agent without enough context to invoke the tool correctly beyond what the schema provides.

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 the single parameter chat_name. The description mentions '指定会话' (specified chat) but adds no meaning about what chat_name should be (e.g., exact name, ID, case sensitivity) or how to supply it. It 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?

The description states a specific verb+resource: returns info for a specified chat, and lists the exact fields returned (name, type, observed message count, last time, watch-list status). It does not explicitly distinguish itself from siblings like get_chat_list or get_chat_history, but the purpose is clear enough.

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 guidance is given about when to use this tool versus alternatives. The description only states what it returns, leaving the agent to infer that it should be used when specific chat details are needed, with no exclusions or sibling comparisons.

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 does disclose one meaningful trait: the list reflects only passively received messages and is not the complete WeChat conversation list. However, it says nothing about permissions, whether 'readable' implies access scope, or how monitoring affects results over time.

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 tight sentences with the core purpose front-loaded and the important scope caveat immediately after. No filler; only minor room to add parameter hints before it would bloat.

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 key data-provenance limitation is stated. Still, with no annotations and undocumented parameters, the definition leaves actionable gaps for a list endpoint.

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 never mentions limit or keyword. Both parameters are undocumented in both the schema and the description, leaving the agent to guess at their semantics.

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 ('返回当前可读取的会话列表') and defines its boundary by clarifying it is not the complete WeChat chat list. It is clearly distinguishable from the full-list concept, though it does not explicitly contrast with siblings like get_chat_history or 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?

No explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The provenance note ('based on passively monitored messages') implicitly tells the agent the list may be incomplete, which is useful context but not 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?

With no annotations, the description carries the full burden. It discloses the incremental/buffer polling model and the next_seq feedback loop, which is valuable, but says nothing about permissions, whether the buffer is destructive to read (it seems non-destructive), or rate/limit 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 dense sentences, front-loaded with the incremental-read purpose, then the after_seq workflow, then the optional filter. No filler, though it stops short of a crisp one-line summary.

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 documented, and the description still usefully references next_seq. For a 3-param read tool this is largely complete, missing only limit semantics and any safety/permission context.

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 after_seq (feed back the last next_seq) and chat_name (limit to one conversation) well, but the limit parameter is never mentioned. Two of three parameters are covered, leaving a real gap under 0% schema coverage.

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: incrementally reading newly added messages from the monitoring buffer. The '增量/新增消息' framing distinguishes it from get_chat_history, 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?

It explains the intended call pattern clearly: pass the previously returned next_seq as after_seq to fetch only new messages, and optionally constrain to one conversation with chat_name. This is a clear use context, but it never contrasts with get_chat_history or states when not to use this tool.

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 disclosure burden. It does make clear this is a non-mutating status probe by enumerating what is inspected, but it says nothing about cost, latency, or whether probing can affect the client or automation backend.

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, listing the three checks in a compact parallel structure. Nothing is wasted.

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 probe with an output schema already describing the return payload, the description covers the necessary scope. The only real omission is guidance on how to react to a negative result.

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 document; the baseline for a no-arg tool is 4.

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 enumerates the three concrete aspects checked: connection status, window visibility, and automation backend availability. This is immediately distinguishable from every sibling, all of which operate on chats, messages, or 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 diagnostic nature implies a preflight use (verify WeChat is reachable before calling send_message or get_chat_list), but the description never states when to call it, when not to, or what to do if a check fails. Usage must be inferred from the content of the checks.

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 does disclose meaningful behavior beyond the schema: results are a candidate list, duplicates are returned unmodified, and the tool will not guess a single match. It omits any statement about read-only safety, result limits/pagination, or the data source being searched.

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 tight sentences with zero filler. The core action is front-loaded and the ambiguity-handling rule follows immediately; every clause carries information.

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

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

An output schema exists, so return structure needn't be explained, and the duplicate-handling rule is a genuinely useful addition. Still missing for a search tool: scope of the search corpus, limit/truncation behavior, and how the caller is expected to refine an ambiguous result set.

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 clarifies that the required keyword matches by name (contacts and group chats), but adds nothing about the limit parameter, its default of 20, or whether results are truncated — leaving half the parameters undocumented in both places.

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: search contacts/group chats by name and return a candidate list. That is clearly distinct from siblings like get_chat_list, get_chat_info or get_chat_history, though it never names an 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?

The description implies usage (look up an entity when you only know its name) and gives one concrete handling rule for ambiguous results — return duplicates as-is and let the caller disambiguate. However, it never states when to prefer this over get_chat_list or get_chat_info, so routing guidance is left 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?

With no annotations, the description carries the full burden and does disclose real behavior: directory-scoped access control, refusal on misconfiguration, failure return when the outcome cannot be confirmed, and an explicit no-auto-retry policy. It does not explain the confirm/dry_run switches, which materially change what the call actually does (dry_run presumably prevents the send).

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 sentences, each earning its place: purpose first, then preconditions, then failure/retry semantics. No filler and the most important constraint (send scope) is front-loaded.

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 detail is not required, and the description covers the critical constraints plus failure semantics. The remaining gap is the semantics of confirm/dry_run and what counts as an 'explicit' recipient match, which an agent would otherwise have to guess.

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 all four parameters. It clarifies recipient ('explicitly specified' contact or group) and the file_path constraints (must exist, must be in an allowed directory), but confirm and dry_run receive no explanation at all, leaving half the parameters opaque.

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: send a local file to an explicitly named contact or group chat. The word 'file' (文件) plus the required file_path/recipient pairing distinguishes it from the sibling send_message, which handles text messages, without needing the schema. No ambiguity about what the tool does.

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?

Preconditions are stated explicitly: the file must exist, must live inside an allowed directory, and sending is refused when no sendable directory is configured. What is missing is routing guidance against alternatives (e.g., when to prefer send_message vs send_file, or behavior for ambiguous recipient names).

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 and does disclose meaningful traits: refusal on ambiguous recipients, a returned candidate list, a failure status when delivery cannot be confirmed, and an explicit no-auto-retry policy. It omits permissions and the meaning of the confirm/dry_run switches, keeping it short of a 5.

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, and the primary action is front-loaded before the guardrail clauses. It is efficient, though the second sentence compresses two distinct behaviors into one line.

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. However, for a four-parameter write tool with zero schema coverage and no annotations, the description leaves the dry_run/confirm semantics entirely undocumented, which is a real gap 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 0%, so the description must compensate for all four parameters and it does not. The recipient concept is hinted at ('explicitly specified contact or group'), but message, confirm, and especially dry_run are never mentioned, leaving the agent unable to discover preview or confirmation behavior.

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 (send a text message) and narrows the scope to an explicitly specified contact or group chat, which implicitly separates it from send_file. It does not name any sibling outright, so it falls just short of full differentiation, but the action 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?

It gives a conditional rule (if the target is not unique, refuse and return candidates), which tells the agent it must resolve ambiguity first, but it never says when to prefer this tool over alternatives like send_file or how to obtain a unique recipient. Usage is implied rather than spelled out.

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 and does add meaningful context: it discloses that the list only filters read results returned by this service and does not alter underlying monitoring behavior, plus that block outranks allow. However, it omits persistence, permission/auth requirements, and 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?

It is a compact, front-loaded statement with the purpose up front and supporting detail in trailing parentheses. The nested colon/parenthesis structure makes it dense but nothing is wasted.

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. For a 3-param config tool, the description covers the operation, the mode behavior, and the scope of effect well; the main omission is any note on persistence or permissions.

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 largely does: add/remove are explained as adding/removing chat names, and mode is given the allow/block values with their meanings (including the empty=all case for allow). This meaningfully exceeds the bare schema.

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

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

The description states a specific verb+resource ('设置会话关注列表' / set the chat focus list) and breaks it into concrete operations (add/remove chat names, mode selection). The purpose is clear and distinct from the read/send siblings, though it never explicitly names an alternative 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?

It explains mode semantics (allow = whitelist with empty meaning all; block = blacklist with higher priority), which hints at usage, but it never states when to reach for this tool versus just reading with the sibling getters. Usage is implied rather than instructed.

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