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

Annotations mark this as a non-readonly, idempotent, non-destructive, open-world operation. The description adds genuinely useful context beyond that: no phone numbers are fetched, no send records are created, the draft is not delivery, and organizer auth is required. This resolves the ambiguity of a mutation flag on something that only produces text, though it says nothing about rate limits or draft persistence.

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, opening with the auth/role gate in brackets before scope and exclusions. Every clause carries information; the semicolon-separated style is efficient for a compact definition.

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 draft-generation tool with no output schema, the description covers auth, scope, exclusions, and input sourcing adequately. Its main gap is not clarifying the draft's return form, but the annotation set and the described scope make it callable without further guesswork.

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%, so the description bears the burden. It usefully explains where userIds come from (get_activity_guest_sms) and implies the body via 起草正文, but the tone parameter and the activityRef binding are left undocumented. Partial compensation for a 0%-coverage 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?

States a specific verb+resource+scope: draft an SMS invitation body for activity guests from currently visible userIds, with AI usable. It explicitly scopes what it does NOT do (不取电话、不建发送记录) and distinguishes itself from delivery ('草稿非送达') and from get_activity_guest_sms, which it names as the source sibling.

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 clear prerequisites and context: 【需要登录·主办方】 (login required, organizer role), and states the human edits and sends in the App. It routes the agent to get_activity_guest_sms for the userIds input. It implies but does not explicitly name the send tool (e.g., send_guest_invite_now) as the alternative, so it stops short of full when-not guidance.

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