Capture the iPhone screen as an image scaled to point size, so pixel coordinates map directly to taps and swipes. Pass x/y/width/height to crop and magnify a small region.
截取当前屏幕。图像已缩放到点尺寸,像素坐标可直接用于点击和滑动。
看不清小图标、小字时,传 x/y/width/height(点)放大这块区域:从原始高清截图裁剪, 小区域再额外放大。返回文字里有放大倍数,图中坐标换算回屏幕点:x + 像素/倍数。
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ||
| y | No | ||
| width | No | ||
| height | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses that the image is scaled to point dimensions so pixel coordinates map directly to tap/swipe, that cropping comes from a higher-resolution original, and that the returned text carries a magnification factor with a conversion formula. What's missing is any statement of the return shape (image vs text payload) or limits on capture frequency.
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?
Front-loaded with the core action and tightly structured into base behavior then zoom behavior. The second paragraph is dense with coordinate math but each clause carries necessary information; only minor tightening is possible.
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?
No output schema and no annotations exist, but the description supplies the key behavioral contract: point-space coordinates, zoom-crop behavior, and how to convert returned-image coordinates back to screen points. It stops short of describing the actual return payload (screenshot image plus text) which an agent would benefit from knowing up front.
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%, so the description must compensate, and it does define the meaning of x/y/width/height as a point-space crop region with extra magnification for small areas. However, it never clarifies the four parameters' interaction — whether all four must be supplied together, or what happens if only some are given — leaving optionality semantics ambiguous.
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 opens with a specific verb and resource ("截取当前屏幕" – capture current screen) and explicitly links the output to the coordinate-consuming siblings (tap/swipe). An agent can distinguish it from iphone_list_elements, iphone_status, and iphone_tap without opening the schema.
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 conditional rule for the region parameters: "看不清小图标、小字时" pass x/y/width/height to zoom. That covers when to invoke the optional path, but it never states an explicit alternative tool (e.g. list_elements for reading UI structure) or when not to screenshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.