MCP server for manipulating HarmonyOS devices (allows tool-based control of HarmonyOS phones via the Model Context Protocol).
https://github.com/XixianLiang/HarmonyOS-mcp-serverStop manually tapping through your HarmonyOS device during development. This MCP server gives your AI agents direct control over HarmonyOS phones and tablets - they can launch apps, navigate interfaces, and execute device commands just like you would.
You know the routine: make a code change, rebuild, deploy to device, manually navigate to the right screen, test the interaction, repeat 50 times. What if your AI agent could handle the device interaction part?
With this MCP server, your Claude or OpenAI agent becomes your device automation partner. Tell it "Launch the settings app and navigate to the network section" and it executes the actual device commands. No more context switching between your IDE and physical device manipulation.
This isn't another emulator integration - it controls actual HarmonyOS hardware. Your agent can:
Perfect for integration testing, demo automation, or when you need to verify behavior on actual hardware without the manual overhead.
The server integrates seamlessly with your current MCP setup:
# Your agent can now control devices with natural language
message = "Launch the app `settings` on the phone"
result = await Runner.run(starting_agent=agent, input=message)
Works with Claude Desktop out of the box, or integrate it into your existing OpenAI agents workflow. The MCP protocol means your agent gets tool-based access to device control without you writing custom automation scripts.
Clone the repo, run uv sync, and you're connected to any HarmonyOS device on your network or via USB. The server discovers devices automatically and exposes them as MCP tools your agent can use immediately.
No complex SDK integrations or device-specific scripting - just point your agent at the MCP server and start giving it device control commands.
This is particularly valuable if you're building HarmonyOS apps and need rapid iteration cycles with real device testing, or if you're creating demos that need to show actual device interactions without manual coordination.