Capture the Android phone screen and inspect zoomed regions with a coordinate ruler, UIA/OCR targets, and an observation ID so UI actions can be verified against the current display.
查看手机截图、坐标尺、UIA/OCR文字目标及observationId。全图不传参数；局部放大同时传上一observationId和region，region为上一返回图0~1000范围。width/height与targets用原图像素，view.region由程序映射。非文字目标须裁切到不超过原图一半面积，再aim。新观察使旧观察失效；输入后重看。
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | ||
| observationId | No |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and open-world, so safety is covered. The description adds real behavioral context beyond that: the new-observation-invalidates-the-old rule, program-side mapping of view.region, and coordinate-range semantics of the returned image — useful traits not in the annotations.
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?
Dense but front-loaded, leading with what is returned and then the two invocation modes and constraints. No filler sentences, though the run-on packing of rules slightly raises parsing effort.
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 nested-parameter, no-output-schema tool, the description covers return contents, both invocation modes, coordinate conventions, cropping constraints and the invalidation/re-view lifecycle. It is nearly complete; only reasoning about error cases or the exact target list format is absent.
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 nested region object is undocumented in schema. The description compensates well: region is the 0~1000 range of the previously returned image, full-image vs zoom determines which params to send, and width/height/targets use original-image pixels while view.region is mapped by the program.
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+resource: viewing phone screenshots with coordinate ruler, UIA/OCR targets and an observationId, which tells an agent exactly what it returns. It does not explicitly name or differentiate the siblings (phone_status, phone_action, etc.), so a 4 rather than 5.
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?
Explicitly states the two modes: pass no parameters for the full image, or pass both the previous observationId and region for partial zoom. It also gives preconditions (non-text targets must be cropped to ≤half the original area before aiming) and a critical ordering rule (re-view after input since a new observation invalidates the old one).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.