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

Annotations already declare the write/idempotency/destructiveness profile, so the bar is lower, and the description still adds substantive context: DRAFT-only target, the two-phase preview/save protocol, and a hard constraint that CDKeys must not be handed to the model but configured in the App. It stops short of explaining failure modes or what preview 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?

Dense but front-loaded: auth/scope lead, then the workflow, then the handling caveat — every clause carries operational value. The semicolon-packed style is terse to the point of being hard to parse on first read.

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 tool with five params, a nested config object, 0% schema coverage and no output schema, the description covers the workflow and safety constraints well but leaves the agent without guidance on constructing the required config (titles, rules, requirements). It is adequate for sequencing the calls but thin for the actual payload.

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% on a deeply nested config object, so the description carries the burden and only partially compensates: it clarifies consent, preview, previewHash, and hints at prize handling (可保留原库存 = reuseFrom, 实物奖 = PHYSICAL). activityRef and the whole config surface (title, rules, requireAppCheckin, requirements) remain undocumented in both places.

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+resource in the title/name pairing and adds real scope: '仅DRAFT' (DRAFT only) and a preview-then-save flow, which cleanly separates it from read siblings like get_activity_raffle. It does not name a sibling explicitly, so it falls just short of the top band.

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 protocol: preview first to verify the configuration, then save with the same params plus previewHash, consent=true, preview=false. It also states the precondition (【登录·主办方】 logged-in organizer) and the CDKey restriction, leaving nothing about when/how to call to inference.

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