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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's real contribution is the caveat that the status is local and does not mean the recipient downloaded — a genuinely useful scope limitation — but it says nothing about rate limits, staleness, or what the status transitions are.

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 compact clause with the purpose and the two disambiguating caveats front-loaded; no filler sentences at all.

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?

There is no output schema, so the description carries the burden of explaining what the returned status actually is, and it does not — the possible status values and their meaning are absent. The anti-confusion caveat is good, but an agent still cannot interpret the response.

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% and the schema gives only a UUID format/pattern, so the description must carry semantic weight. '同一 deliveryId' usefully implies the id was previously obtained from a related tool rather than being an arbitrary UUID, which is meaningful added context, but nothing is said about id validity or error behavior for unknown ids.

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?

Combines a specific verb (查询) with a specific resource (同一 deliveryId 的本地状态) and explicitly excludes file sending, which separates it from the send_file sibling. It does not, however, distinguish itself from prepare_file or file_secretary_help.

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?

'不发文件' implicitly routes the agent away from send_file toward a polling/inspection use case, but there is no explicit statement of when to call this instead of the other siblings, nor any prerequisite such as needing a deliveryId previously issued by send_file/prepare_file.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds that this is a prerequisite step in the file-sending workflow, but it does not describe what the tool actually returns or what the agent should do after reading it.

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 two short sentences with no wasted text. It is efficient, though the opening phrase '本机文件秘书流程' is somewhat compressed and could be clearer for an agent unfamiliar with the workflow.

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 zero-parameter help/prerequisite tool with annotations and no output schema, the description is minimally adequate: it says when to read it. However, it omits what the tool provides and what the agent should expect after invoking it, leaving some ambiguity about the resulting workflow.

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?

The tool has zero parameters, so there is no parameter semantics needed. The schema is correspondingly empty, and the description does not need to compensate for missing parameter documentation.

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 identifies a 'local file secretary workflow' and tells the agent to read this tool before sending a file to the user, but it does not explicitly state what the tool returns (presumably workflow guidance/instructions). The purpose is inferable, but it is less clear than a direct verb+resource statement.

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 gives a clear trigger: when the user asks to send a file to themselves, read this tool first. It does not mention when not to use it or explicitly name sibling alternatives, so it falls short of full routing guidance.

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

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

Annotations already declare a non-read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds two useful facts beyond the annotations: no dispatch occurs and a deliveryId is returned, plus that recipients are fixed by local config. It does not say whether prepared copies expire or how long a deliveryId stays valid.

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?

Two short clauses: purpose first, then return value and the recipient-config caveat. Nothing is wasted, though the phrasing is terse enough that the filename format question is left silently unanswered.

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 one-parameter tool with no output schema, the description usefully discloses the return value (deliveryId) and the implicit-recipient behavior. It falls short on the file argument's expected form and on what happens to a prepared but unsent copy.

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% for the single required 'file' parameter, which has only min/max length constraints. The description restates it as a 'user-specified file' but gives no indication of whether the value is a path, an ID, or a URL — the one piece of information missing from the schema.

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 resource: prepare a copy of a user-specified file, explicitly noting it does not send. The negative clause ('不发送') distinguishes it functionally from the sibling send_file, though it never names that sibling outright.

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?

Implies the prepare-then-send flow by contrasting with sending, and notes the recipient comes from local configuration rather than a parameter. It never states explicitly when to use this versus calling send_file directly, nor what to do with the returned deliveryId.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the real-world irreversibility profile is covered. The description adds genuinely non-obvious context beyond that: the single deliveryId payload contract and the idempotency guard forbidding auto-resend while status is unknown/sending/busy. It falls short of explaining success/failure outcomes or what to do when blocked.

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?

Two tight clauses with zero waste, and the blocking rule is front-loaded right after the core action. Nothing to trim.

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 destructive, open-world send with no output schema, the description should say where deliveryId comes from and what to do when the state check blocks the send. It covers the resend prohibition but leaves output/result behavior entirely undocumented.

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% and the type/format (uuid, pattern) is the only machine-readable hint. '只传 deliveryId' merely restates the single-param contract; it never says what a deliveryId is or that it originates from prepare_file, which is the key semantic an agent needs.

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 states a specific verb and resource ('发送已准备文件' – send already-prepared file) and constrains the payload to deliveryId. It implicitly excludes prepare_file (this sends files that are '已准备'), but it doesn't name delivery_status or the other siblings 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?

'按用户指令发送' hints at when this is used (user-directed sends), and the 'unknown/sending/busy 禁止自动重发' rule gives a concrete when-not-to-act condition. However, it never names the visible alternative – checking delivery_status first – so an agent has to infer where those states come from.

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