Skip to main content
Glama
Derrors

iPhone Control MCP Server

iphone_swipe

Swipes from one screen coordinate to another on a USB-connected iPhone to scroll content or perform gesture-based automation.

Instructions

从一点滑到另一点(点坐标)。向上滑看下面的内容:from_y 大、to_y 小。

Input Schema

NameRequiredDescriptionDefault
to_xYes
to_yYes
from_xYes
from_yYes
secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries the full disclosure burden. It doesn't state that the swipe mutates UI state (scrolling, drag-and-drop, dismissing sheets), nor mention the 'seconds' duration parameter's effect on gesture speed or flick vs. drag behavior. The only behavioral hint is the direction example.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and followed by the most practically useful example. No filler, though the parenthetical "(点坐标)" is slightly redundant given the parameter names.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a gesture tool with no annotations, no output schema, and 0% parameter documentation, the description leaves critical gaps: coordinate units/resolution assumptions, what 'seconds' controls, and whether swipes can trigger destructive side effects. An agent could easily call this with wrong-scale coordinates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 for 5 bare parameters. It does add real meaning for from_y/to_y by explaining the directional convention (large from_y, small to_y = swipe up), which is not in the schema. But it says nothing about the coordinate system (pixels vs. normalized), from_x/to_x semantics, or the 'seconds' parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource pair ("从一点滑到另一点", swipe between two points) that clearly separates it from siblings like iphone_tap and iphone_long_press. It doesn't name those siblings explicitly, but the gesture semantics are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides one concrete usage scenario (swipe up to reveal content below, with the from_y/to_y relationship spelled out), which is genuinely helpful. However, it never says when to prefer swipe over other gestures, nor any preconditions such as requiring an app in the foreground.

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