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

The annotations already cover idempotency and non-destructiveness, and the description adds genuinely useful behavior: organizer authorization is required, phone numbers are never returned, and system SMS can only be sent and confirmed by the guest in their own App. That said, it says nothing about pagination behavior, result size, or what the SMS progress states look like.

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?

It is short and front-loads the access precondition, with no filler sentences. However, the telegraphic mixed-language, semicolon-chained phrasing ('登录/主办方;查云嘉宾候选…') makes it harder to parse than a plainly structured sentence would be.

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 five-parameter read tool with no output schema and no parameter documentation, the definition covers access rules and the drafting boundary but omits return shape and cursor/pagination semantics. It is enough to know roughly what the tool is for, not enough to call it confidently with the right parameter values.

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 five parameters, so the description must compensate — yet 'q/scope/cursor/selectedIds同App' only names the parameters and defers to the App for meaning, and activityRef is never mentioned at all. An agent learns nothing about what q matches, what the two scope values select, or what selectedIds filters.

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 description names a specific verb (query/查) and concrete resources: cloud guest candidates, authorization status, and real SMS progress. It is clearly separable from draft_activity_guest_sms, but it does not distinguish itself from nearby siblings such as list_guest_invitation_candidates or get_activity_invitation_ledger, which plausibly overlap.

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 states the access precondition (login/organizer) and explicitly routes drafting work to draft_activity_guest_sms, plus warns the Agent must not record an SMS as sent. What is missing is guidance on when to pick this tool over the other candidate/ledger listing tools in the sibling set.

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