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

Annotations already flag this as destructive and not read-only, and the description adds substantial context: login required, active-host role required, default preview mode, hash-confirmed execution, reopen behavior, inability to restore declined/withdrawn applications, and that no one is contacted. This is rich behavioral disclosure beyond the structured hints.

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 dense and front-loaded: authentication and role first, then the default-preview workflow and key constraints. Every clause adds actionable information with no filler.

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 six-parameter mutation with no parameter descriptions and no output schema, the description covers the critical preview/hash workflow, auth requirements, and key destructive limitation. It is not fully complete because some parameters remain unexplained, but it is sufficient to invoke the tool safely in normal cases.

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 must carry the burden. It explains preview, previewHash, and reopen semantics well, but omits meaning for note, conversationId, and organizationId, leaving several parameters undocumented.

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 title and description together make clear this marks a host follow-up as done or reopens it, and it distinguishes itself from contact-oriented siblings with '只记状态，不联系对方'. However, the description itself does not plainly state 'mark as done' without relying on the title.

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 explains the preview-then-confirm workflow, the reopen=true case, and the limitation that declined or withdrawn applications cannot be restored. It does not explicitly say when to choose this tool over siblings like log_host_followup or remind_host_followup, so usage is only implied.

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