Approve a specific candidate's resume attachment request. Use yes=true only after explicit operator approval; no automatic download or retry.
招聘者模式：同意指定候选人的附件简历请求；仅在操作者明确批准后传 yes=true，不自动下载或重试 [可用性: 可用性: roles=recruiter; candidate_platforms=-; recruiter_platforms=zhipin-recruiter]
| Name | Required | Description | Default |
|---|---|---|---|
| yes | No | 操作者已明确批准同意这条请求 | |
| dry_run | No | 只预览，不请求平台 | |
| friend_id | Yes | 候选人会话 friend_id | |
| message_id | Yes | 附件简历请求消息 mid |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses important constraints: it requires explicit operator approval before passing yes=true and states '不自动下载或重试'. However, it does not explain the side effects of accepting, reversibility, or what the tool returns on success or 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 description is compact and front-loaded with the purpose and the critical operational caveat. It loses a point due to the duplicated token '可用性: 可用性:' and inline availability metadata that adds minor clutter.
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?
Given the absence of annotations and output schema, the description covers the main target and safety gate but omits what happens after approval, how results/errors are surfaced, and how it relates to sibling resume actions. The schema fully documents parameters, so invocation is possible, but operational expectations are underspecified.
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 100%, so the baseline is 3. The description mainly reinforces the yes parameter semantics already present in the schema ('操作者已明确批准同意这条请求') and adds no meaningful detail about friend_id, message_id, or dry_run beyond what the schema provides.
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 clearly states a specific verb and resource: '同意指定候选人的附件简历请求' (approve a candidate's attachment-resume request) in recruiter mode. It is distinguishable from siblings by the accept/approve action, though it does not explicitly name or differentiate itself from related tools like boss_hr_download_resume or boss_hr_request_resume.
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 provides clear invocation context: recruiter mode and a candidate's attachment-resume request. It also gives an explicit condition for setting yes: '仅在操作者明确批准后传 yes=true'. It does not list alternatives or explicit when-not-to-use cases, but the context and consent condition are adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.