sticker_send

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.