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

Annotations already declare destructive=true and idempotent=false, but the description adds what the annotations cannot: a login requirement, a mandatory preview-then-confirm flow requiring an echo of previewHash with consent=true and preview=false, and precise blast-radius limits (no refunds, no ticket/pass/online-rights cancellation). This is exactly the behavioral context an agent needs before a destructive call.

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-loads the login requirement and the trigger condition, then layers scope, confirmation workflow, and exclusions. Every clause is load-bearing for a destructive operation, but the density of semicolon-joined clauses makes it heavier than the tightest possible phrasing.

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?

Given a destructive mutation with no output schema, 0% schema coverage, and a multi-step confirmation protocol, the description supplies the login prerequisite, the two-phase call sequence, the non-reversible side-effect scope, and the fallback for ineligible cases. Nothing an agent needs to invoke this safely is missing.

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% across 4 params, so the description must carry the load — and it largely does, explaining how preview=true differs from preview=false, that consent must be true, and that previewHash must be echoed with identical parameters. The only gap is activityRef, whose format and source are never described, though its meaning is inferable from context.

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 (withdraw my own offline signup) and immediately narrows scope to '独行录本站线下报名和待激活占位', which distinguishes it from organizer-side siblings like cancel_activity and from invitation responses like respond_activity_invitation. An agent can identify the exact operation and its boundary 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?

Explicit trigger ('本人明确无法参会或要取消报名时用'), explicit exclusions ('不退款、不取消门票年票或线上观看权益；外部表单仍须主办方撤回'), an escalation path ('已签到或已开场须联系主办方'), and a disambiguation warning ('勿把取消提醒当取消报名'). This is a full when/when-not/alternatives statement.

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