Point an AI Agent at Twenty Real Phones: MCP, the SDK, and When to Use Which
There are two honest ways to drive a rack of phones. One is a script that says exactly what to do, in order, forever. The other is an agent that looks at the screen and decides what to do next. A deck ships with both, and the useful question is not which is better but which belongs on which job.
The control path
Start with where the pieces physically live, because that is what makes the agent story work at all.
The important detail is that nothing here needs a computer of yours to stay awake. The deck carries the controller and serves the control software itself, so the MCP server is reachable for as long as the rack has power and Wi-Fi. Your MCP client, and whatever model is behind it, runs wherever you like.
What the agent gets is not a conversation about phones. It gets the devices as tools: it can see what is on a screen and it can act on it, on one device or across the rack.
What the loop looks like
Agent automation is not a script with better grammar. It is a loop: look, decide, act, look again.
That last point is why the hardware matters here specifically. An agent driving an emulator is reading an approximation, and it will happily make confident decisions about a rendering path, a camera preview or a permission dialog that does not behave the way it does on a phone. If you are going to let something act on its own judgement, give it the real screen. We went through where emulators diverge in detail.
When a script is better
Most of the time, honestly. Anything you can specify exactly should be specified exactly: it runs faster, costs nothing per run, does the same thing every time, and can be read by a person six months later. Open the app, wait for the screen, send this sequence of taps, read this value back. That is a script, and the JavaScript SDK is there to write it.
There is also a zero-code version of the same idea, and it is the one most people end up living in.
On replay the touch paths are drawn over the screen as they are sent, so when a flow misfires you can watch what the phone was actually told to do instead of inferring it from the result. Replay speed runs from a quarter to four times, and you can step one event at a time, which is most of the work when an app moves a button.
When an agent is better
When the job is describable but not specifiable. Some concrete cases:
- The same goal across different devices. "Turn off autoplay" is one sentence and six different Settings trees across six phone models. A recorded flow does not survive that. An agent reading each screen does.
- The app moved. A layout change breaks a coordinate-based replay instantly. An agent can find the new button, and you can record what it did as the new flow.
- Exploration. You do not know the steps yet. Let the agent find them once, then freeze the result into a recording.
- Triage. Twenty live screens and the question "which of these are stuck?" is a reading problem, not a scripting problem.
A split that actually works
Use the agent to discover the flow. Record what it did. Replay the recording for as long as it keeps working, scheduled and staggered across the rack. When the replay starts failing, put the agent back on that one device to find out what changed, and re-record. You get the reliability and the cost profile of a script for the ninety-something percent of runs that are routine, and judgement exactly where the routine breaks.
What you need to run this
AiPhoneFarm is a 2U 19 inch rackmount deck with twenty cradle slots for real Android phones. Power and cooling are inside, the controller is onboard, and it joins your Wi-Fi and runs the control software itself. That software gives you the live device grid, broadcast input, record and replay, scheduling, per-device profiles and health monitoring, plus the JavaScript SDK and the MCP server described above.
399 € once, VAT and shipping included, shipped within three weeks. The control software runs on a 100 €/year plan whose first year is included in that price, and which carries access to the source on GitHub for as long as it runs. If it lapses the deck keeps running; updates stop. Phones are yours to bring, and Android devices with a SIM slot and 5G data are the ones worth buying.
Frequently asked questions
Which clients can connect?
MCP is an open protocol, so Claude and any other MCP client can connect to the server on the deck and operate the phones as tools. If you would rather not use an agent at all, the JavaScript SDK and the browser UI reach the same devices.
Does the model run on the deck?
No. The deck hosts the MCP server, which is the tools: the devices, their screens and their input. The client and the model behind it run wherever you run them.
Do I have to write code?
Not to use it. The browser UI plus record and replay covers a lot of ground with no code at all. The SDK is there when you want a flow expressed as a program rather than as a recording.
Can I read the code that is driving my devices?
Yes. The control software plan includes access to the source on GitHub for as long as it runs, so you can audit it before trusting it with anything and extend it for your own rack.
Is this allowed on the platforms I care about?
The deck and its software are general-purpose device automation tools. Operating within the terms of service of every platform you touch is your responsibility, as is the content and the accounts you run through it.
Keep reading
New to the format? How to build a phone farm covers the hardware from the ground up, and emulators versus real devices covers why any of it is worth the space in your rack.
Skip the build. Rack a finished one.
AiPhoneFarm is a 2U deck for twenty real Android phones, with the controller and the control software already inside. 399 € once, VAT and shipping included, shipped within three weeks. Phones not included.