操作移动端设备

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the 'send operations' framing is not contradictory. The description adds only 'validated' and 'selected platform adapter' context, but it does not disclose side effects, execution timing, or what happens if the operation fails.

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 a single compact sentence with no redundant phrases. It front-loads the operation types and background context, making it easy for an agent to parse quickly.

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?

The schema is rich and self-documenting, and the sibling names give useful context, but the description lacks important operational details such as how to obtain a valid targetId and what the expected result or error behavior is. With no output schema, the return semantics are left entirely unspecified.

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 description does not compensate for that gap. It only restates the operation kinds already present in the 'action' oneOf schema, and it does not explain targetId, coordinate semantics, durationMs, or how the operation object should be constructed beyond what the schema already shows.

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 the tool's function with a specific verb ('发送') and resource (mobile device via platform adapter), and enumerates the concrete operation types: click, swipe, text input, and key operations. This makes it immediately distinguishable from sibling tools like mobile_capture, mobile_get_logs, or mobile_list_targets.

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 description implies when to use this tool: whenever the agent needs to send tap, swipe, text, or key actions to a mobile target. However, it does not explicitly provide when-not-to-use guidance, name alternatives, or state that targetId should come from mobile_list_targets.

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