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

Adds substantial behavior beyond annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true): immediate push to organizers and poster page (③), content_rejected on machine review failure (④), modifying others' statements (⑤), and the critical profileSync default true that replaces the entire highlight set, merges into personaTags, and recalculates vectors (⑥). No contradiction with annotations — the destructiveHint and readOnlyHint=false align with the description's disclosed overwrite behavior.

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?

The description is long but justified: it is structured with 【何时用】【组合链】【口径】 sections and numbered points that make it scannable. Every point covers a distinct behavioral aspect of a complex tool with destructive defaults. It is front-loaded with the primary action. Minor deduction for density — the profileSync explanation is information-heavy, though unavoidable given the tool's complexity.

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?

Thorough for a complex mutation tool: covers when-to-use, orchestration chain, photo rules, contact-info rules, push behavior, review failure, guestId ownership, and the destructive profileSync default. The one gap is return values — there is no output schema and the description only mentions the content_rejected failure, not the success response shape. Still, the critical behavioral aspects are fully covered.

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 0%, so the description carries full burden, and it delivers: identities (≤3), highlights (≤5), gains (≤5), topic, photoUrl (OSS-only constraint), wechat/contactMode (contact-disclosure rule), guestId (ownership caveat), and profileSync (default true + side effects). Nearly every one of the 10 parameters gains business meaning beyond the bare schema constraints.

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: helping the user write the guest profile in one pass, enumerating the exact fields (identity tags ≤3, highlights ≤5, topic, audience takeaways ≤5, photo). The title '一次写完我的嘉宾资料' reinforces the verb+resource. It clearly distinguishes from siblings like get_my_guest_profile (read counterpart) and update_my_profile (different resource).

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?

Explicitly says when to use ('这是本域最该代办的一处') and provides a full combination chain naming the sibling tools to invoke beforehand (get_my_guest_profile to see missing, get_my_profile/get_my_products to draft, then this tool). It also states exclusions: don't pass wechat/contactMode unless user explicitly says, don't touch others' guestId unless requested. Nothing is left to inference.

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