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. It does usefully disclose the shape of each returned record (uin / name / relationship / tone / notes), which compensates for the missing output schema, but says nothing about result size, pagination, ordering, or auth requirements for a zero-arg 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?

Two tight sentences: the purpose and its scope qualifier come first, then the return payload. Nothing is redundant and 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?

For a zero-parameter read tool with no output schema, the description covers what the tool does and what comes back, which is most of what an agent needs. It stops short of stating whether the whole roster is always returned or whether the caller must handle large lists.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the enumerated return fields are a bonus rather than a parameter explanation.

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 a distinguishing scope detail — whether each friend has written a definition or not. That separates it from a pure friend-note writer like friend_note, though the description never names 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 read-only listing intent is implied by '查看' and by the fact it returns a roster, but there is no explicit statement of when to call this instead of friend_note or the qzone_* tools. The agent must infer that this is the lookup step before writing notes.

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 supplied, the description carries the full load and does disclose two meaningful behaviors: it is a partial update (only supplied fields change, others presumably preserved) and the note field is append-only rather than overwritten. It does not say what happens to unset fields explicitly, whether existing values can be cleared, or what the call returns.

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

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

Two sentences, front-loaded with the purpose then the update semantics; no filler. Minor deduction for the plural 'notes' reference that does not match the schema's 'note' parameter name.

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 five-parameter mutation tool with no annotations and no output schema, the definition covers the core contract (partial update, append semantics) but leaves open whether the friend must pre-exist, whether fields can be reset, and what the response contains. Adequate, not complete.

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

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

Schema coverage is 100%, so each of the five parameters already has a Chinese description in the schema; the description largely restates those field names. The one piece of added meaning is the append behavior of the note field, but it refers to it as 'notes' while the schema parameter is singular 'note', a small mismatch that could confuse mapping.

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: writing your own definition/profile for a friend, with the four field groups enumerated (name/relation/tone/note). It is distinguishable from siblings like friend_list (listing) and the qzone_* tools (posting/liking), though it never explicitly contrasts itself with them.

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 the update semantics ('传了哪项就更新哪项') which implies this is the tool to call whenever you want to set or amend any part of a friend's profile. There is no explicit when-not guidance, no mention of prerequisites (e.g. the friend must already exist / be in the friend list), and no pointer to an alternative 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?

With no annotations, the description carries the full burden and does so well: it discloses hard rate limits (once per post per 24h, 3/hour, 10/day) and content constraints (≤120 characters, CQ codes forbidden). These are non-obvious operational rules that would otherwise cause silent failures; only auth requirements and return behavior are unstated.

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?

Front-loaded with the core action, then mode requirements, then hard constraints — a sensible ordering with no filler sentences. It is telegraphic and slightly terse (e.g. '需要 target_uin + tid + content' compresses a conditional into an apparent requirement), but 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?

For a 7-parameter mutation tool with no annotations and no output schema, the description covers the two things an agent most needs: which parameters pair with which mode and the quotas that will reject calls. It does not describe the success response or how quota violations surface as errors, which leaves a small 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 100%, so baseline is 3, but the description adds real meaning: it groups parameters by mode (target_uin + tid + content vs. the extra comment_id + comment_uin) and tells the agent where to source the comment ids. Minor issue: it lists target_uin as required while the schema marks it optional for one's own posts.

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 immediately distinguishes the two modes: commenting on a post vs. replying to a comment (楼中楼). An agent can tell it apart from qzone_like/qzone_publish 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?

Explicitly states the conditional path: pass only tid + content normally, and add comment_id + comment_uin when replying to a comment. It even names the sibling tool that produces those ids (从 qzone_comments 拿), which is exactly the routing guidance an agent needs.

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 helpfully declares read-only behavior and describes the return structure (author/time/content plus nested 楼中楼 replies), but says nothing about failure modes, pagination termination, or whether target_uin is needed for other users' posts — that caveat lives only in the schema.

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 block of clauses with zero wasted wording. The read-only marker, the tid dependency, and the pagination capability are all front-loaded before the return-value note.

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 fills in the return shape (per-comment author/time/content and nested replies) and explains pagination. It stops short of the error behavior documented only in the schema, but is otherwise adequate for this four-parameter read 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 every parameter including tid, pos, num, and target_uin is already documented. The description only restates the tid source and pagination idea, adding essentially no new parameter meaning beyond 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?

The description states a specific verb and resource (读取某条说说下面的评论), marks it read-only (只读), and points to qzone_see_posts as the source of tid. This lets it be distinguished from the write-side sibling qzone_comment, though it never names that 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?

It gives clear operating context: tid comes from qzone_see_posts, and pos/num enable pagination. It does not state when to use this instead of qzone_comment when the user wants to post, so the guidance covers only the read path and lacks explicit exclusions.

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 it does disclose two real behavioral traits that are not in any structured field: a 24h per-post idempotency limit and a frequency cap. It omits auth/login requirements, what error surfaces when the 24h window is hit, and what a successful call returns, which matters for a mutation 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?

Three short clauses, front-loaded with the action, then the required inputs, then the limits. No filler and no repetition of what the schema already states.

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

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

For a two-parameter mutation with no annotations and no output schema, the essentials (what it does, where to get the IDs, rate and dedupe limits) are present. Auth requirements and failure/return semantics are absent, which leaves it adequate rather than complete.

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

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

Schema description coverage is 50%: tid is documented but target_uin has no schema description at all. The description partially compensates by naming both parameters and pointing to qzone_see_posts as their source, but it never explains what target_uin identifies (the post owner's UIN vs. the viewer), leaving the undocumented parameter only half-clarified.

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 opens with a specific verb+resource (给某条说说点赞 - like a specific Qzone post), which is unambiguous and distinct from the sibling write tools (qzone_comment, qzone_publish). It also names qzone_see_posts as the source of the required identifiers, so an agent can place it in the workflow without opening the schema.

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

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

It gives an explicit prerequisite call (先 qzone_see_posts 拿) and a hard constraint that effectively defines a when-not case: the same post cannot be liked again within 24 hours. No guidance on what to do if the like fails or on permission requirements, but the practical usage path is clear.

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 zero annotations, the description carries the full burden. It does disclose a meaningful operational prerequisite — it is disabled by default and requires a config flag plus a service restart — which is genuinely useful context not found in the schema. It says nothing about side effects, permissions, rate limits, or what a successful publish returns.

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 with the most decision-relevant fact ([当前禁用]) front-loaded, followed by the exact remediation step. Nothing is padded, though the space saved comes at the cost of omitting any actual purpose or parameter detail.

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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the definition is thin: it explains why the tool cannot be used but not what it does when enabled. The disabled state is the most important fact and is covered, which keeps this above a 1.

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 was expected to explain the two parameters, yet neither 'content' nor 'images' (up to 9 items) is mentioned. The only implicit hint is that '说说' involves text. An agent learns nothing about content length limits, image URL format, or whether images are required.

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 labels the resource ('发表说说', i.e. publish a Qzone status) but never states the operation in a self-contained way; its dominant content is a disabled notice. An agent can guess this tool publishes a post, but it cannot distinguish its exact scope from siblings such as qzone_comment or qzone_see_posts from this text alone.

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 strong negative guidance: the tool is 当前禁用, and enabling it requires an admin to set publishEnabled: true and restart the service, which effectively tells the agent not to call it. However, it offers no alternative for the same goal (no routing to a sibling tool) and no description of when the enabled tool should be chosen.

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 supplied, the description carries the full burden and does well: it discloses read-only behavior, the whitelist authorization requirement on target_uin, and the returned fields (tid, 正文摘要, 图片数, 评论数, 总条数). It omits failure behavior when the account is outside the whitelist and any rate/ordering caveats, 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?

Three tight sentences: purpose first, then return values, then the hard constraint. No filler and nothing repeated from the schema.

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

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

For a two-parameter read-only tool with no output schema, the description usefully enumerates what comes back and flags the whitelist gate, so an agent can call it without guessing. Only the behavior on a non-whitelisted target_uin and any ordering/paging nuance are unstated.

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 100% so the baseline is 3, but the description adds a genuine operational constraint not present in the schema: target_uin must be in the whitelist. The num parameter's semantics (default 3, max 5) are left entirely to 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 verb and resource ("查看某个 QQ 号的最新说说") plus the read-only nature, which is clearly distinct from siblings like qzone_publish or qzone_like. It does not explicitly name a sibling alternative, so sibling differentiation is inferred rather than stated.

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 parenthetical "（只读）" and the note that the returned tid is what 评论/点赞 need imply this is the discovery step before qzone_comment/qzone_like. However, no explicit when-to-use or when-not-to-use rule is given, and the whitelist prerequisite is stated as a constraint rather than as guidance on what to do if it fails.

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