boss_batch_greet

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

With no annotations, the description carries the full burden, and it does disclose the batch cap of 10, which is a real behavioral constraint. It does not disclose that greeting sends real outbound messages to real users, whether the operation is idempotent (re-greeting someone already contacted), or any rate limits — significant omissions for an irreversible outbound action.

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?

A single front-loaded clause plus a bracketed availability tag — no filler. The cap is placed prominently rather than buried, though the mixed-language bracketed suffix is slightly dense.

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 batch, side-effecting outbound-messaging tool with four parameters, no annotations, and no output schema, the description is thin. It never explains dry_run (the agent must infer 'preview mode' from the schema), what the response looks like, or how partial failures are handled — all things the agent needs before firing a batch of greetings.

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 does add one piece of meaning beyond the schema by stating the upper bound of 10, which the schema's '最大打招呼数量' field never specifies. It adds nothing about query, city, or dry_run, so it does not rise above the baseline.

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 and scope: batch greeting after a search, with a hard cap of 10. The 'batch' qualifier implicitly distinguishes it from the single-greet sibling boss_greet and the recruiter-side boss_hr_greet, though neither sibling is named explicitly.

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?

The availability tag (roles=candidate; candidate_platforms=zhipin; recruiter_platforms=-) is a genuine gating condition that tells the agent when the tool is usable. However, there is no guidance on when to prefer this over boss_greet for a single target, or on what to do when the search returns fewer than the requested limit.

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