Preview a sticker's image before use. Animated files are sampled into a three-frame JPEG so you can read the expression, text, and meme meaning first.
看一张表情/梗图（联网新图必须先看）：动图会取首中尾三帧拼成一张 JPEG。结合画面、表情、文字和反讽理解梗意，再用 sticker_note 记录含义。已标注过含义的图不必重复看。stickerId 用 sticker_list / sticker_find 返回的 id。
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | 可选：会话标识，用于看图额度的归属 | |
| stickerId | Yes | 表情标识，来自 sticker_list / sticker_find |
Changes observed during successful MCP inspections.
v0.1.3Does 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.