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

Annotations only supply idempotentHint and destructiveHint=false; the description adds the operative context an agent actually needs — login plus organizer permission requirement, that applicants see the result immediately, that ids from other activities are silently ignored, that reviewNote cannot be emptied because cleared messages are unrecoverable, and the requested/updated/ignoredIds report shape. None of this contradicts the annotations; the note about not clearing notes is a usage restriction, not a claim of destructiveness.

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?

Permission scope is front-loaded in brackets, then the workflow, then limits, then the return contract — a sensible ordering with zero filler. The arrow/telegraphic style and compressed terms (投递态, 余者) make it dense, which costs a point on readability but not on substance.

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 5-parameter mutation with no output schema, the description covers the missing pieces: prerequisites, the confirmation gate, the batch cap, the ignored-id behavior, the report fields a caller should surface, and the one destructive-adjacent pitfall (irreversibly clearing notes). Very little an agent needs in order to invoke this safely is left unstated.

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 documents all five parameters and the baseline would be 3. The description still adds meaning beyond the schema: preview is framed as the mandatory dry-run gate in the confirm workflow, and ids are characterized as activity-scoped with out-of-scope ids ignored rather than erroring.

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+scope: batch-changing the admission result (录取结果) for signup submissions, while explicitly NOT changing the delivery state (不改投递态). This distinguishes it from both the singular sibling review_signup_submission and the delivery-related report_signup_delivery, so an agent can route correctly without opening any 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 an explicit end-to-end procedure: fetch ids via list_signup_submissions → run with preview=true (no persistence) to show id/nickname/current status → only after the user explicitly confirms the roster run with preview=false. It also states a hard exclusion (不能跳过确认) and tells the agent that other cases should change reviewStatus and be handled separately.

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