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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered; the description adds genuinely new context by stating that completed results are preserved and that social accounts are not modified. It still omits what happens to in-flight/partial results and how errors (unknown or already-finished task_id) are handled.

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 two semicolon-separated clauses, front-loading the action before the side-effect guarantees. Nothing is wasted, though it is terse enough that some required detail is simply absent rather than trimmed.

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 one-parameter tool with no output schema, the description covers what is stopped and what is untouched, which is adequate. It falls short on parameter meaning and on edge-case behavior (task already complete, invalid task_id, status of a second cancel), which nothing else in the definition supplies.

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 required parameter, so the description must compensate and does not: task_id is never mentioned, nor is how to obtain it or whether it refers to the same task identifier returned by get_task.

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

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

The description uses a specific verb (停止/stop) on a specific resource (本地读取任务/local reading task), which is far more informative than the bare name cancel_task. It does not, however, contrast itself with siblings such as get_task, so the agent must infer the division of labor.

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 explicit when-to-use or when-not-to-use guidance and no named alternative (e.g. get_task for checking status). The clause about retaining completed results implies a use context but never states the condition under which an agent should call this instead of another 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?

The description discloses the key non-obvious behavior that annotations do not convey: this is an asynchronous task-creator, not a synchronous status read, and results must be fetched via get_task. The read-only claim is consistent with readOnlyHint=true and destructiveHint=false. Note the mild tension that idempotentHint=false plus task creation implies repeated calls spawn new tasks, which the description does not address.

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 states the purpose and then the follow-up step, with zero filler. Every clause earns its place despite the brevity.

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, annotation-rich, async task tool with no output schema, the description supplies what an agent most needs: what the task does and where its results live. It omits any explanation of the check's scope or output shape, but result structure is delegated to get_task, so the gap is minor.

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 the baseline is 4. There is nothing for the description to disambiguate, and the schema is fully described (100% coverage) with additionalProperties=false.

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 and resource — creating a read-only browser/account check task — which is more accurate than the name 'connection_status', which misleadingly reads like a synchronous status getter. It also distinguishes itself from the get_task sibling by routing result retrieval there. It does not differentiate itself from the remaining siblings (list_platforms, search), 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?

It gives explicit workflow guidance ('use get_task to view results'), which is genuinely useful for an async tool. However, it never states when to invoke this check versus other siblings, nor any preconditions or exclusions, so usage is only partially specified.

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, idempotentHint, and non-destructive. The description adds that the call can wait up to 30 seconds, returns partial results, source, and clear failure reasons. This is useful behavioral context beyond the annotations, though it doesn't cover auth or 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?

Two compact sentences, front-loaded with purpose then wait behavior. Every clause adds information (what is returned, wait option). 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?

With rich annotations and no output schema, the description covers return contents and wait behavior. It leaves task_id semantics implicit, but the required parameter is self-explanatory and the tool is simple.

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 descriptions are absent (0% coverage). The description explains the wait_seconds behavior (max 30 seconds, reduce repeated queries) but does not describe task_id beyond implying it identifies a task. Partial compensation only.

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?

get_task clearly states a specific verb (取得/get) and resource (task status, partial results, source, failure reason), making its function distinct from siblings like cancel_task. However, it does not explicitly name an alternative or sibling for contrast, so it falls short of the top benchmark for 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?

The description only offers an implicit usage tip: wait up to 30 seconds to reduce repeated queries. It does not say when to choose this tool over cancel_task or search, nor does it provide exclusions. Hence implied usage only.

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 this as a read-only, idempotent, non-destructive, closed-world lookup, so the safety profile is covered. The description adds a useful caveat that the listed capabilities are declarative and not real account verification, but it gives no detail on return shape, pagination, or 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?

Two short sentences with no wasted words, which is appropriately sized for a simple lookup. However, the lead sentence is so vague that it does not front-load a usable purpose, and the second sentence reads as a cryptic disclaimer.

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 tool with no output schema and rich annotations, the description still leaves the core meaning of 'candidate read capabilities' unexplained. It does not say what platforms or capabilities are returned, what the limitations are, or how this relates to connection_status.

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 the baseline of 4 applies per the rubric. The description does not add parameter meaning, but none is needed 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 says it shows 'candidate read capabilities and limitations,' which is vague and never states that this lists available platforms. It neither names the resource clearly nor distinguishes the tool from siblings such as connection_status, so an agent cannot confidently tell what it returns.

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 guidance, no preconditions, and no mention of alternatives like connection_status or search. The agent is left to infer when this tool should be selected over its siblings.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true, idempotentHint=false). Going beyond them, the description discloses that results are inherently incomplete, a platform-level gap (weixin 留言 unsupported), and a cursor-based pagination contract – genuinely useful behavioral context not present in structured fields.

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, front-loaded sentences with no padding; the most important caveat (results are not exhaustive) comes first. Slightly terse for the number of undocumented parameters, 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?

For a six-parameter read tool with 0% schema coverage and no output schema, the description only addresses pagination and partiality. An agent still cannot tell what url vs content_ref means, how platform selects behavior, or what the limits govern, so it is not complete enough to call 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 six parameters, so the description must carry the burden, but it explains none of url, limit, platform, content_ref, or replies_limit. It also refers to 'next_cursor' while the input schema names the parameter 'cursor', leaving the pagination parameter loosely mapped.

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+resource (查看评论/回复) and immediately scopes it ('有限评论与可见回复，不代表全部评论'), which tells an agent this is a partial-read tool distinct from read_content. It does not explicitly name a sibling, 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?

It gives one clear operational rule – continue with the next batch when next_cursor is returned – and one platform exclusion (公众号留言暂不支持). However, it never says when to choose read_comments over read_content or search, nor what prerequisites the url/content_ref imply, so guidance is implied rather than explicit.

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=true, and destructiveHint=false, so the safety profile is partly covered; idempotentHint=false is not explained. The description adds real value beyond the annotations with the security caveat that fetched content is untrusted material and must not be treated as executable instructions, a meaningful prompt-injection warning for an open-world reader.

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, front-loaded sentences with no filler; the primary usage path is stated first. The terseness verges on under-specification, but nothing in the text is redundant.

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 two input paths and the trust caveat, but with no output schema it does not say what the read returns, how refresh affects retrieval, or how the platform enum constrains url handling. Adequate but with clear gaps for a 4-parameter open-world reader.

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

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

Schema description coverage is 0% across 4 parameters, so the description must carry the semantics. It clarifies content_ref (comes from search results) and that url must be a full url paired with platform, but it says nothing about the refresh flag, nor whether url is usable without platform or content_ref.

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 concrete verb ('阅读'/read) and the exact resource it consumes: the content_ref carried by search results, or a platform + full url pair. That is enough to separate it from siblings like search and read_comments, though it never names those siblings explicitly to sharpen the boundary.

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

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

The description implies the workflow: after a search, pass the content_ref; alternatively supply platform plus a complete url. It does not state when to prefer content_ref over url, whether both may be combined, or when to use read_comments instead.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower, yet the description adds genuinely useful behavior: the call is asynchronous, returning a task identifier that must later be resolved, and WeChat results come from the Sogou index rather than a native API. That async/task-id detail is the kind of thing an agent would otherwise get wrong.

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, then the platform caveat, then the follow-up step. Nothing is padded and no sentence is redundant.

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 async contract is covered, which is the most important missing piece given there is no output schema. However, for a tool with 0% parameter documentation and an opaque "content_ref" that is neither defined nor matched to the sibling read_content, the description leaves an agent guessing about inputs and the follow-up call's exact name.

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 3 parameters, so the description carries the burden and largely fails: it hints that platforms is a required selection but never explains the four enum values, the query length bound, or what limit does (default 5, max 10). No syntax or format guidance is added beyond the schema itself.

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 clear verb+resource ("在所选平台搜索" – search on the selected platform) and scopes it to the platforms parameter. It also discloses the async shape (returns a task identifier) which distinguishes it from the sibling read_content/get_task tools, though it never names those siblings 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 implied rather than stated: "在所选平台搜索" suggests platforms must be chosen (presumably via list_platforms), and the follow-up instruction to read with content_ref implies the search-then-read workflow. There is no explicit when-not or named alternative, so an 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.