Some jobs look tiny on their own and turn unbearable once you repeat them fifteen times a day. Say you are managing a few dozen iPhones. You are mid-script in your editor, or you are in the middle of a conversation with an AI assistant about which batch to run today, and a question pops up: how many machines in the content group are online right now?
The normal answer is window-switching. Open the iEasyRun workstation, click the Devices page on the left, scroll the list, find the group, count, switch back. The local MCP server in iEasyRun exists to delete that move.
1. Why Hand Devices to an AI Assistant at All
The workstation can expose a local MCP server. Point a client that speaks MCP at it — Cursor or WorkBuddy, for instance — and the assistant can read your device list and your workflow list. You ask a question, it goes to the workstation, pulls the data back, and you skip the window-switching.
The entry point is on the workstation capabilities page. Scroll down to the local MCP section and you will find a local address, usually something like http://127.0.0.1:9866/mcp. Copy that into the client MCP config and you are done. Because the address is local, only tools running on the same computer can reach it; from another machine it will not connect at all. The config details live at https://www.ieasyrun.com/docs/mcp, and there is a product overview at https://www.ieasyrun.com/mcp.
Honestly, this is not the kind of feature that opens a new world the moment you install it. Think of it as giving the assistant a pair of eyes: it now knows which devices and which workflows you have in hand. That is the whole of it.
2. What MCP Can Actually Query
Every tool exposed today is a read. There are four of them: list_devices lists devices, list_device_groups lists device groups, list_devices_by_groups lists devices within a group, and list_workflows lists workflows.
Unimpressive on its own, but the combinations cover decent ground. Want to confirm one specific device is present? Use the first. Want to look at a batch by purpose? Pull the groups, then query by group. Want to know how many workflows you have accumulated and what they are called? Use the fourth.
For people who write scripts, the value sits in the status check. Halfway through a script you want to confirm the target device is still attached; before editing a workflow you want to see what already exists so you do not build the same thing twice. Those become a few seconds of work.
Grouping is what multiplies the value. If a few dozen machines all sit in the default group under the raw names they were scanned in with, the assistant can still query them — you just get back a pile of near-identical entries and have to work out which is which. Once the fleet is past a few dozen devices, how you organize it becomes a real question of its own, and what device capacity actually looks like in practice covers how the picture changes as the fleet grows.
One thing trips people up here. The capabilities page has two MCP settings sitting next to each other. Local MCP pushes the workstation devices and workflows out to Cursor and WorkBuddy. The other direction lets the AI inside the workstation pull in an external MCP server. They look alike and do the opposite, so mind which one you click.
3. What It Cannot Do, and Why That Matters Most
No clicking. No swiping. No running workflows. None of those three are inside MCP.
Put more bluntly: the assistant can tell you which device is online, but it cannot reach out and tap that device. To make a phone actually move, you go back to the workstation.
To run a job, open the chat page, pick an online device, and describe the work in plain language. Or go into the workflow library, choose your devices and parameters, and run it directly. Those two paths are where the work happens. MCP does not cover that stretch.
Why draw the line there? My reading is that it is about boundaries. A query changes nothing on the device; the worst case is that the information is a few seconds stale. Execution is different. If it goes sideways, whatever is on screen can end up tapped into a mess. Splitting the two keeps the assistant on “knowing” and the workstation on “doing”.
So if someone tells you they chatted with their AI assistant and the phone started moving on its own, there is a step in between: the words have to become a chat task or a workflow inside the workstation. MCP itself does not carry that step. It offers query access, not execution. Underneath it all the arrangement is simple: EasyClick central control is the hands and eyes, iEasyRun is the brain — a different layer, not a different job.
4. Which Teams Get Real Value From This
Start with who it suits.
Teams with a few dozen devices and clean grouping get the smoothest ride. When devices are grouped by purpose and given aliases, the results the assistant reads back are immediately usable — no guessing what D023 is supposed to be.
Then there are the people writing scripts inside Cursor or WorkBuddy. Their workspace and device status already live on one screen, so a quick device check is genuinely convenient. If you want to see how that chain runs from a conversation all the way down to a physical action, this walkthrough of an AI agent driving real devices is the companion piece.
Now the other side. Two kinds of people will probably be disappointed.
One is the team whose device grouping is a mess. The problem is not MCP; it is that the devices were never organized. Fix the aliases and groups first — that beats configuring MCP by a wide margin.
The other expects “talk and the phone obeys”. That expectation is not unreasonable, but it lands on chat and workflows, not on MCP. Chasing it through MCP points you the wrong way from the start.
A third group can wait: teams with three or five devices who can see everything at a glance. Your window-switching cost is basically zero right now, and the time MCP saves is less than the time it takes to wire up a client.
5. Boundaries to Watch When You Try It
The workstation has to be running. The MCP service travels with it — close the workstation and every tool on the client side goes dead. Whether you can query anything comes down to whether the workstation is up.
The computer has to be the same one. It is a local address, and another machine cannot reach it. If your team works remotely, decide up front which machine hosts the workstation and whether that machine staying switched on fits your routine.
Devices have to be connected through the central control first and visible on the Devices page. If a device never shows up in the workstation, MCP cannot find it either. That chain is a prerequisite regardless of whether you ever run a task.
Reload the client after changing the config. Half of all “it is configured but returns nothing” cases end right here.
Underneath all of it, MCP gives the assistant a pair of eyes, not a pair of hands. Once that is clear the decision gets easy: if what you lack is knowing device status at any moment, wire it up; if what you lack is a phone that gets work done on its own, that is a job for chat and workflows.
Install links and further reading:
- iEasyRun site and install guide: https://www.ieasyrun.com/docs/install
- MCP product page: https://www.ieasyrun.com/mcp
- MCP documentation: https://www.ieasyrun.com/docs/mcp
- iEasyRun documentation: https://www.ieasyrun.com/docs
- Further reading: Apple cluster control without jailbreak, what a practical no-jailbreak setup looks like
About EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak (proxy / Bluetooth HID / OTG HID) and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products
Ready to build it for real?
Every approach in this article can be built on the EasyClick phone automation platform — full documentation, developer tools and cluster/cloud-control products, free to try.