Your agent can use your iPhone.

Find it, tap it, read the result back.

iphone_status {}
→ state: "ready"
  phone.device_match: { quality: "matched" }

iphone_find { "text": "Calculator" }
→ matches[0].device_center: { x: 52, y: 604 }

iphone_tap { "x": 52, "y": 566 }   // the icon, above the label
→ confirmation_required
  token bound to this exact call (profile: standard)

iphone_tap { "x": 52, "y": 566, "confirm_token": "…" }
→ verification: { method: "frame_change",
                  verified: true, outcome: "changed" }

iphone_find { "text": "7" }
→ device_center: { x: 53, y: 676 }

iphone_tap { "x": 53, "y": 676, "confirm_token": "…" }
→ verification: { method: "frame_change", verified: true,
                  outcome: "changed",
                  changed_fraction: 0.0256 }

iphone_screenshot { "max_dimension": 1024 }
→ PNG cropped to the phone — the display reads 7

Device points, because screen pixels rot.

A screen pixel is an accident of this Mac, this display scale and where the Mirroring window happened to be when you looked; drag the window an inch and every coordinate in your transcript is wrong. macos-mcp never hands one out. iphone_find returns a device point — a coordinate in the phone's own logical space — and iphone_tap and iphone_swipe take the same, so a target found now survives a resize, a different Mac, and the same transcript replayed tomorrow.

Underneath are three coordinate spaces — window pixels, global screen points, device points — with the letterbox detected rather than guessed and one geometry shared by every tool, so a point read off iphone_screenshot cannot disagree with the point iphone_tap presses. The device profile behind the mapping is reported with its quality — matched, nearest or pinned — so a nearest guess never comes back looking like a fit.

Finding text is OCR here — and that is a measurement, not a shortcut.

macos-mcp is accessibility-first everywhere else on the Mac: the tree first, pixels as the fallback. For a mirrored iPhone that ordering is not available, and it was measured rather than assumed — the mirrored content is an opaque video surface with no accessibility tree behind it. Nothing to snapshot, no element ids, no roles. So iphone_find (ScreenCaptureKit, Vision OCR, fuzzy matching) is the primary locator, and the tool descriptions say so rather than implying a snapshot they cannot deliver.

That inversion is half the story. The other half is what makes it trustworthy: the Mirroring app's own chrome does have a full accessibility tree, and that is what separates the states pixels cannot see. An alert over the phone still renders something phone-shaped; a screenshot would call it ready.

A phone locked and far away, an unfinished setup screen, a phone in someone's hand and a region where Mirroring is unavailable look identical from outside the app: one state, no_phone_content, whose fix names all four. The projects that do separate them patch eligibilityd, which is a line this one holds.

The phone has to change, or it did not happen.

Every mutating iphone_* call captures the phone before, acts, captures after, and reports whether the frame moved. A tap that changed nothing is a typed action_unverified error, never a green check. Proving iphone_key back on real glass looked like this: the edge swipe ran, 81% of the screen changed after 120 ms, and the screenshot showed Today View — what iOS itself opens for that gesture. Verified, not claimed.

The detector underneath got the same treatment. It used to separate phone from window by brightness, which works until a dark app on a dark window leaves nothing to separate. It now reads the window's alpha shape: the window is cut to the phone's outline, and alpha does not care what the phone is showing. Verified on a Settings page that is almost entirely black — ready, aspect 2.1557, quality: matched, identical to what the same window reports on a bright Home screen.

iphone_type is the honest exception and says so on the wire: iOS hides the keyboard while Mirroring is active and the content has no tree, so nothing on this Mac can read the field back. It carries verification.method: "none" and points at iphone_screenshot. Branch on that, not on ok.

What this cannot do, stated up front.

And one wart: iphone_key home on the Home screen's first page is a genuine no-op and returns action_unverified, because nothing on the phone changed — indistinguishable from a failed press, by design.

Three lines and a mirrored phone.

1. Install, then macos-mcp install --client claude-code (or claude-desktop, cursor, vscode, codex). One signed binary, no runtime.
2. Ask the agent to call enable_toolset ios, or start with --toolsets ui,screen,system,ios. Grant Screen Recording and Accessibility; macos-mcp doctor prints the System Settings deep-link for anything missing, and the client needs a restart after a grant.
3. Open iPhone Mirroring so the phone is on screen, and ask: “Open Calculator on my iPhone and work out 7 × 8.”

Questions people ask before enabling it.

The iPhone is one toolset. The rest of the Mac is the other 36.

UI automation that reads back every action, screenshots and OCR, apps, files, Apple's own Safari MCP. Signed, notarized, audited. Give your AI agent a Mac →