Pinky Gives Claude Control of a Real Phone via MCP — Payments Only With Your Okay

If you have ever written a mobile app, you know the main pain: you have to test it by hand. Tap, swipe, spot a bug, go back to the editor. Coding agents like Claude Code and Cursor have long handled the terminal and the browser, but they could not reach the phone. The Pinky project tries to fix that: it hands the agent a real smartphone through the MCP protocol.

What exactly is claimed

According to a post on X by @xiaoanlab, the setup is as follows. Pinky acts as an MCP server that Claude Code or Cursor connect to. Through it, the agent gets an image of the real device's screen and can tap on it. Support for both iPhone and Android is claimed. This is not an emulator but a physical phone, and that is an important difference: real hardware surfaces bugs that do not exist in a simulator, from camera quirks and push notifications to the behavior of system dialogs.

A simple example. You ask the agent: "Open the app, go through registration and check that onboarding is shown after login." Previously, such a scenario had to be described in UI tests with Appium or XCUITest, and then fixed every time the layout changed. Here the agent looks at the screen like a human and makes decisions as it goes.

The main question: who has a hand on the button

Giving a language model access to a phone means giving it access to banking apps, messengers and email. That is why the most interesting part of the announcement is not the tap on the screen itself, but the security model. According to the author, payments, transfers, and deleting and installing apps require an explicit "allow" from a human. Banks, wallets and password managers are apparently blocked by default, but in the post this sentence cuts off, so the exact wording cannot be verified.

It is separately stressed that the rules are strictly enforced in the Pinky gateway. This is fundamental. If a ban lives only in the system prompt, it can be bypassed with an injection: malicious text on the screen convinces the model that paying is allowed. If the check sits at the level of a proxy between the agent and the device, the model physically cannot send a dangerous command without confirmation, no matter how it is persuaded. It is the same principle by which, in production, an agent is not given direct access to a database, and a layer with permissions is placed between them.

Limitations and what to do about them

First, what we do not know. There is a single source, a short post with 88 views, and the text is cut off mid-sentence. There is no documentation, no price, no latency data, and no information on how iPhone access is implemented. On iOS this is non-trivial because of the closed nature of the system, and the author gives no details. It is unknown whether everything runs locally or the screen goes to third-party servers. For testing apps with user data, this is critical.

There are also general limitations. An agent controlling an interface via screenshots is slower and less deterministic than scripted tests. Confirming each dangerous action manually saves you from disasters, but kills autonomy. And any "hard" policy is only as good as how completely it lists the dangerous actions.

The practical takeaway is short. Mobile developers should keep an eye on this direction and, if the project publishes its code, test it on a separate test phone with no personal accounts, not on their main one. Product managers should keep in mind that the mobile interface will soon be available to agents just like the web, and your app will have to be understandable not only to people. Founders should look at the pattern itself: a gateway with policies between the model and the device is becoming a separate product layer, and a business could well grow around it.