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

Annotations only declare destructiveHint=false, so the description carries most of the load and delivers: a 2.5-minute compute bound, a rate constraint on consecutive rounds, and a rejection path for insufficient attendance. It stops short of saying what state is created or how to recover from a rejection, which keeps it from a 5.

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 auth/permission requirement, then packs workflow, constraints, and parameter defaults into three compact clauses with zero filler. The arrow notation is dense but readable; nothing is redundant with the schema beyond a brief restatement of groupCount.

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?

No output schema exists and none is needed, since the description points to the polling tool as the way to observe results. For a workflow-initiating mutation, it covers auth, timing, rate limits, defaults, and rejection conditions - the only minor gap is post-call recovery guidance.

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 the baseline is 3; the description earns more by adding defaulting logic the schema lacks - checkedin is used when check-ins exist, all otherwise. That runtime default is genuinely useful for deciding whether to pass scope at all, while groupCount semantics are already fully covered by the schema.

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?

'发起现场重分' names a specific action on a specific resource, and the arrow chain makes clear that this tool only kicks off the round rather than computing or publishing it. It does not explicitly contrast with publish_activity_match_round in so many words, but the sequence removes ambiguity.

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 prerequisites (login/host), an explicit ordering constraint (poll get_activity_match_time until READY, then publish_activity_match_round), an explicit exclusion (禁连续开轮 - no back-to-back rounds), and an explicit failure precondition (too few attendees, sign up/check in first). The agent knows exactly when this applies and what must precede it.

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