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

With no annotations, the description carries the full burden and does well: it discloses the restriction to others' images, that the plugin downloads images safely instead of the gateway fetching arbitrary URLs, and that remarks may be truncated. It omits failure modes (e.g., message has no image), permission requirements, and what happens on duplicates.

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 front-loaded with the core action and scope, followed by messageId guidance, the 'others only' restriction, and the security note. Every sentence contributes relevant information with no waste.

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

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

For a 3-parameter write tool with no annotations and no output schema, the description covers purpose, restrictions, security behavior, and remark truncation. It could be more complete by explaining the return value shape and error cases (e.g., no image in the referenced message).

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 meaningful nuance: messageId must come from a received message, and the remark example shows the intended brevity and tone. These additions are useful, though modest beyond the already detailed 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: collecting someone else's sticker from a chat into QQ favorites. Scope is explicit (only others' images, not your own). It does not explicitly differentiate from the sibling 'sticker_note', which also involves annotating stickers, so it falls short of a 5.

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

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

It gives clear usage conditions: collect a sticker another person sent, and explicitly excludes collecting your own. It does not mention alternatives like sticker_note or sticker_send, leaving some ambiguity about when to use this versus annotating an existing sticker.

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 well: it discloses the internal search order across three sources, the maximum candidate count, the existence of a cooldown state, and a privacy constraint on input. It stops short of describing what a '文字候选' actually contains or whether candidates must be passed to sticker_preview/sticker_send to be used.

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 and search order, and every clause carries information (length limit, fallback chain, result cap, privacy, retry policy). The semicolon-chained Chinese phrasing is dense and slightly run-on, but nothing 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?

For a 2-parameter tool with no output schema and no annotations, the description covers behavior, source priority, result volume, and error handling. The only missing piece an agent would want is the handoff to sticker_preview/sticker_send for the returned candidates.

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, and the description adds a real constraint beyond the schema: query must contain only public emotion/action words and must not carry chat text, names, or QQ numbers. It says nothing about the optional 'target' parameter, relying entirely on the schema for that.

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 ('找表情' by a 1–16 character public emotion/action word) and adds the resolution chain (QQ favorites → meme cache → fixed sites) plus a result cap of 3. It is clearly distinguishable from sticker_collect/list/send, but it never explicitly contrasts itself with those siblings.

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

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

Gives explicit when-to-use input rules (public emotion/action words only), explicit prohibitions (no chat transcripts, person names, or QQ numbers), and an explicit failure path ('没有结果或冷却时本轮用文字，不要连续重试'). The agent knows what to do both on success and on empty/cooldown outcomes.

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 well: it discloses that the output is a text list, that it does not consume image quota (a genuine behavioral trait an agent would otherwise guess wrong), and that refresh=true triggers an immediate forced resync. It stops short of warning about the cost/latency of a forced resync or how large result sets are paged.

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?

Dense but front-loaded: capability, then filters, then the quota-saving return property, then the preview/note workflow. Every clause carries information, though the final workflow tip runs a little long relative to the rest.

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

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

There is no output schema, and the description does the necessary work by stating the return is a text list containing meanings, tags and usage counts. It does not cover pagination behavior beyond the limit parameter, which is the only remaining unknown for an agent calling this correctly.

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

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

Schema description coverage is 100%, so the schema already defines limit, query and refresh. The description restates query's filter dimensions and refresh's resync semantics, adding emphasis but no new meaning, and it never mentions limit or its default of 12. Baseline 3 is appropriate 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 ('查看这个 QQ 账号收藏的表情包') and adds the payload detail an agent cares about (含义/标签/使用次数), which distinguishes it from a plain listing. It also names the follow-up siblings sticker_preview and sticker_note for un-annotated stickers, so the agent knows where this tool sits in the workflow.

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

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

Gives explicit conditions: use query to filter by 备注/标签/用途, use refresh=true to force a gateway resync, and for stickers lacking notes, preview first then record with sticker_note. The only gap is that it never positions this against the closest sibling, sticker_find, leaving that choice 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 load and discloses key traits: it is local memory, reused across sessions, and does NOT modify the official QQ note — a meaningful side-effect clarification. It omits any mention of response format or failure behavior, 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?

The purpose is front-loaded, followed by constraints and the preview prerequisite in a compact two-sentence block. Efficient, with only minor redundancy in restating schema limits.

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 no-output-schema, no-annotation local-memory write tool, the description covers the essentials: what is recorded, that it is local and non-destructive to official data, the preview prerequisite, and field limits. Only the post-write response behavior is 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 coverage is 100%, so the schema already documents all five parameters with examples and constraints. The description's character/count limits (note/usage ≤60, tags ≤6 each ≤12) merely repeat constraints already in the schema, adding little beyond 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?

The description states a specific verb+resource: it records a sticker's meaning (note), emotion tags, and usage scenarios into local memory. This is clear and distinguishable, though it never explicitly contrasts with sibling sticker_collect, so an agent might wonder about overlap with the collection 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 gives an explicit prerequisite/alternative: brand-new online stickers must first be viewed via sticker_preview before recording. This is a concrete when-to-use rule, but it does not say when to prefer this over other siblings like sticker_find or sticker_list.

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 exist, so the description carries the full burden, and it does disclose the key non-obvious behavior: animated images are reduced to a 3-frame JPEG composite, and stickers already annotated need not be re-viewed. It omits cost/quota implications (the schema mentions '看图额度' but the description does not warn about it) and does not say how the image is returned.

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

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

The core action and the mandatory-preview rule are front-loaded, and each clause adds real information (GIF handling, interpretation guidance, next step, id source). It is dense with parenthetical asides, which slightly reduces readability but no sentence 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 2-parameter read tool with no annotations and no output schema, the description covers the essential behavior (composite frame output, interpretation guidance, dedupe rule) and the id source. It could have mentioned the preview quota tied to 'target', which remains undisclosed in prose.

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. The description restates the stickerId provenance (sticker_list / sticker_find) but adds no format or constraint detail beyond the schema, 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 concrete verb and object ('看一张表情/梗图') and immediately specifies the output form for animated stickers (first/mid/last frames combined into one JPEG). An agent can tell this apart from sticker_note (which records meaning) and sticker_send (which sends) 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?

Gives explicit when-to-use ('联网新图必须先看'), explicit when-not-to-use ('已标注过含义的图不必重复看'), and the follow-up step ('再用 sticker_note 记录含义'). Alternatives are named by their purpose, leaving little 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 safety burden well: it discloses pre-send validation of the allow whitelist, minimum interval, and hourly quota, plus that violations are rejected. It does not describe what a successful or rejected call returns, which leaves a minor gap.

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

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

The description is front-loaded with the core action, then constraints, then the target format and validation rules. It is dense but every clause carries a constraint the agent needs; it stops just short of ideal tightness.

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 4-parameter mutation tool with no annotations and no output schema, it covers the key call-time risks (whitelist, rate limits, one-sticker-per-message, stickerId source). Return shape and error payload remain unspecified, which is the remaining gap.

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

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

Schema coverage is 100%, so baseline is 3; the description adds meaning beyond the schema by stating target must match group:123456/private:7890 form AND be in the allow whitelist. The optional atUserId and replyToMessageId parameters are left to the schema, which is acceptable given full 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 opening clause states a concrete verb and resource (send one sticker into a specified conversation) and immediately adds the payload constraint. This makes it obviously distinct from the sibling read/inspect tools (sticker_list, sticker_find, sticker_preview, sticker_note).

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 explicitly rules out combining a sticker with text in the same message and tells the agent to send text separately, and it points to sticker_list/sticker_find as the source of stickerId. What is missing is routing guidance against alternatives (e.g. when to use sticker_note vs this), but for a send tool the usage condition is clear.

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