Capture the current iPhone screen with point-scaled pixels ready for taps and swipes. Pass a screen region to crop and magnify small icons or text for inspection.
截取当前屏幕。图像已缩放到点尺寸,像素坐标可直接用于点击和滑动。
看不清小图标、小字时,传 x/y/width/height(点)放大这块区域:从原始高清截图裁剪, 小区域再额外放大。返回文字里有放大倍数,图中坐标换算回屏幕点:x + 像素/倍数。
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | 区域左上角 x(点) | |
| y | No | 区域左上角 y(点) | |
| 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 well: it discloses that the image is scaled to point size, that pixel coordinates map directly to tap/swipe, that zoom crops from the original high-res capture, and that the magnification factor is returned in text. It omits any note on latency or capture side effects, but for a read-only screenshot the disclosure is substantial.
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, then the zoom guidance, then the coordinate-conversion formula. Dense but every sentence carries operational value; the coordinate math could be slightly tighter but nothing is wasted.
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 correctly explains the return value (magnification factor in the text) and how to interpret it. Combined with the coordinate-mapping rule, an agent has enough to call and use the tool correctly; only edge cases like capture failure are unaddressed.
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 100%, so the baseline is 3, but the description adds real meaning: the four params are in points, they define a zoom region, and the returned magnification must be used to convert image coordinates back to screen points (x + pixel/magnification). That conversion rule is not in the schema and is essential for correct use.
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+resource ("截取当前屏幕" / capture the current screen) and immediately clarifies the coordinate semantics. It is the only screenshot tool among the siblings, so no explicit disambiguation is needed, and an agent can tell exactly what it produces.
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 for the optional region parameters: use x/y/width/height when small icons or text are hard to see. It does not discuss when to prefer this over iphone_list_elements or other inspection siblings, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.