boss_agent_review_reject

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

With no annotations, the description usefully discloses that the call changes a review item's state and records a skip event, while also supplying role and platform constraints. It does not explain whether rejection is reversible, how it affects the associated automation workflow, or what happens on failure.

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 single front-loaded statement communicates the purpose, logged side effect, and availability without filler. The bracketed availability block is dense but compact and useful.

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 simple two-parameter operation, the action, target, side effect, availability, and schema provide minimum viable invocation context. With no annotations or output schema, the missing lifecycle consequences, ID-discovery workflow, and result behavior remain meaningful gaps.

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%, and both id and reason are already documented there, so the baseline score applies. The description adds no source for the review-item ID or guidance on when the optional reason should be supplied.

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 gives a specific action and target—rejecting legacy review items—and adds that a skip event is recorded. It does not explicitly relate the operation to siblings such as boss_agent_review_approve or boss_agent_pending, so sibling differentiation remains incomplete.

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 compatibility/legacy wording and explicit candidate, recruiter, and zhipin availability constraints establish a narrow usage context. However, there is no workflow guidance on when rejection is appropriate, how to obtain a review item, or when to use boss_agent_review_approve instead.

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