input_text

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

With no annotations given, the description carries the full load, and it does well: it discloses the multi-step side effects (focus, clear, inject, optional Enter), says the system IME is preserved and not modified, states that the UIAutomator2 channel supports Chinese and Emoji and fails explicitly when it is unavailable, and warns that refetching the full tree costs about 200ms and much context. It does not mention required permissions, what is lost when clear_first deletes existing content, or partial-failure behavior, so it falls short of a 5.

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 compact lines that lead with the core capability and then list the pipeline in execution order. The wording is essentially all substantive, though '极速' is marketing filler with no operational meaning.

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 7-parameter tool with an output schema, the description covers the execution flow, the IME-safety guarantee, the Unicode/Emoji support boundary, and the context cost of the optional UI tree return. The remaining gap is routing guidance versus fill_form and element_action, which keeps it from being complete.

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 every parameter is already documented in the schema, including defaults and the resource_id/hint_or_text/index focusing alternatives. The description adds only the ordering of the composite pipeline, which largely restates what the individual parameters already say. Baseline 3 applies.

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 names a specific verb and resource ('文本输入工具') and spells out the composite action: focus the field, clear it, inject the string, optionally press Enter, return the UI tree. This clearly differs from generic gesture tools. However, it does not say how it differs from siblings such as fill_form or element_action, which also enter text.

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?

There is no explicit statement of when to use this tool, when not to use it, or which sibling to use instead. The only choice guidance is indirect and appears in the return_ui_after parameter: use ui_snapshot(since_snapshot_id=...) rather than refetching the full tree. The default-value cues (clear_first=true, press_enter=false) imply typical usage, but that is inference, not guidance.

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