How the Xcode 27 MCP can lead to higher token costs when navigating the Simulator

Xcode 27's built-in MCP returns a roughly 10 KB accessibility hierarchy file after every Simulator action, about seven times more text than RocketSim's CLI in developer Antoine van der Lee's benchmark, driving up token costs for agents navigating iOS apps. Van der Lee, who owns RocketSim and disclosed the conflict, measured Xcode's DeviceInteractionSynthesize tool, which returns a hierarchy file, full-size screenshot, thumbnail and app logs, and noted Xcode lists 54 tools whose definitions total roughly 20,000 tokens if loaded upfront. A separate developer's one-week token analysis found 1,153 tool results contained images, about 500 from an iOS Simulator MCP, each persisting in context for the rest of the session.

The Xcode 27 MCP can lead to higher token costs when your agent navigates the iOS Simulator, because it reads about seven times more text after every action than RocketSim’s CLI did in my benchmark. Efficient navigation comes down to what your agent reads after every tap. A screenshot shows what the screen looks like, while an accessibility tree tells the agent what is on it and what it can tap. The format of that tree decides how many tokens you spend. A developer recently shared their token analysis with me. Over one week, 1,153 tool results contained images, and about 500 of them came from an iOS Simulator MCP. Each of those images stayed in the context for the rest of the session, even though their instructions preferred a dedicated tool. This means if you’re constantly running in the same agent task, you’ll lose a lot of input tokens to just summaries of images. I assumed Xcode 27’s own MCP would be a similar offender, so I measured it against RocketSim’s CLI on the same scenarios. An image in a tool result doesn’t disappear after the agent has looked at it. It stays in the context, and every next turn reads the whole context again. A full-size iPhone screenshot 1206×2622 pixels is roughly 1,500 tokens for e.g. Claude or Codex after it’s scaled down, and an agent often takes a new one after every action. Screenshots are also a poor way to find out where to tap. The agent has to estimate coordinates from pixels, and a wrong estimate means a wrong tap and another try. I covered the context side of this in How to reduce token usage in Claude Code, Codex, and Cursor https://www.avanderlee.com/ai-development/reduce-token-usage-claude-code-codex-cursor/ . The AI Fundamentals course https://aifundamentals.dev?utm source=swiftlee&utm medium=article&utm campaign=simulator-navigation teaches you to spot this kind of waste in your own sessions in module 8, and the token cleanup prompt https://aifundamentals.dev/token-cleanup-prompt/ is the one that surfaced the screenshots in this example. Xcode 27 added device interaction tools to its built-in MCP: DeviceInteractionStartWorkspaceSession , DeviceInteractionInstallAndRun , DeviceInteractionSynthesize , and DeviceInteractionEndSession . The flow looks like this: 1. Open your project in Xcode and approve the agent. 2. Start a session for a Simulator, then build, install, and launch your app. 3. Send commands like t 201 234.3 w 0.8 tap, then wait with DeviceInteractionSynthesize . I expected screenshots flooding the context, but that isn’t how it works. DeviceInteractionSynthesize returns paths: a hierarchy file, a full-size screenshot, a thumbnail, and the app logs. The tool description tells the agent to take coordinates from the hierarchy and never to guess from a screenshot. The hierarchy is a text file with one line per element: Button, {{16.0, 208.3}, {370.0, 52.0}}, label: 'Team Docs', hitPoint: {201.0, 234.3} It’s good data, but it’s also complete. A simple screen with a list and a tab bar is 121 lines, mostly nested Other containers, and about 10 KB. The agent has to read that file after every action to find the next hit point. There are a few more things to know: - Xcode asks you to approve the agent, and it only does so when a project is opened. - Xcode’s reply tells the main agent that all interactions must run in a subagent that loads the device-interaction skill. - Xcode lists 54 tools on my machine. The definitions of all of them are about 20,000 tokens by my rough estimate, if your client loads them upfront. Altogether, there are quite some parts that can easily fill your context for no reason. RocketSim https://www.rocketsim.app is my own app, so take my conclusions with that in mind. That’s why I’m sharing the setup and the limits of the results. RocketSim’s CLI https://www.rocketsim.app/docs/features/agentic-development/rocketsim-cli/ is built for agents, and a bundled Agent Skill https://www.rocketsim.app/docs/features/agentic-development/agent-skill/ teaches your agent how to use it. I introduced it in AI-Powered Xcode Simulator Automation token-efficient https://www.avanderlee.com/ai-development/ai-powered-xcode-simulator-automation-token-efficient/ . We already have a benchmark for this, built around a small fixture app with scenarios like nested navigation, duplicate labels, a hidden accessibility element, swipes, long presses, typing, orientation, and the Home button. I added Xcode 27.1’s MCP to it and ran ten scenarios in three rounds on a dedicated iPhone 17 Pro simulator: - The Xcode flows take every coordinate from the hierarchy file, chain a tap and a wait in one command, and don’t capture again just to verify. That’s close to the best case for this tool. - I counted what the agent has to read: for RocketSim the command output, and for Xcode the returned paths plus the hierarchy file. - An independent check verifies the result inside the app after each run, so a tool can’t pass by reading its own output. This is what came out: | | RocketSim CLI | Xcode 27.1 MCP | |---|---|---| | Output the agent reads | 56 KB | 400 KB | | Estimated text tokens | about 14,000 | about 100,000 | | Tool calls | 88 | 41 | | Elapsed time | 94 seconds | 114 seconds | | Scenarios completed | 30 of 30 | 27 of 30 | On the same screen, the Files list of the fixture app, RocketSim returns 1.18 KB where Xcode’s hierarchy file is about 10 KB. That’s the pattern across all scenarios: Xcode’s MCP reads about seven times more. That can easily add up overtime. Xcode needs fewer calls, because every DeviceInteractionSynthesize returns the state after the action and commands can be chained. That’s a real advantage. The time is close, and Xcode also builds and launches your app, which RocketSim doesn’t do. That’s another reason I’m running these benchmarks: it allows me to further improve RocketSim’s CLI. The three misses were all the same scenario. The target is a hidden accessibility element in a pass-through overlay window. RocketSim can activate an element through accessibility, while Xcode’s MCP can only tap a coordinate, and that tap didn’t open the menu, even after a retry. Face ID, two-finger touches, and accessibility audits are RocketSim-only in my benchmark, since Xcode’s command syntax does not support them. It’s a scripted benchmark, not a live model run, so there are no real token counts. It’s one machine and one fixture app. The tokens are bytes divided by four, and the thumbnails Xcode’s skill asks the agent to read add only about 120 tokens each. The full-size screenshot is about 1,500 tokens, but I never opened it. In other words, I did my best to measure this as closely as possible. Two other tools are worth knowing: - iOS Simulator MCP https://github.com/joshuayoes/ios-simulator-mcp offers ui describe all for the accessibility tree, but also ui view , which returns a JPEG straight into your context. I can’t tell which Simulator MCP the developer that contacted me used, but it only takes one call to put an image in the session. - XcodeBuildMCP https://github.com/getsentry/XcodeBuildMCP returns the accessibility hierarchy from snapshot ui and turns it into numbered references. It uses AXe https://github.com/cameroncooke/AXe , an open-source CLI you can also use directly with axe describe-ui and axe tap --label "General" . AXe shows how much the format matters. On the Settings screen, AXe 1.8.0 prints 309 KB 134 nodes, 79 of them unlabeled layout groups . RocketSim’s agent output for the same screen is 721 bytes. A raw accessibility tree can cost more than a screenshot, but it’s better to use something like XcodeBuildMCP on top of AXe either way. In general, I hope you’ll take away from this article that it’s important to consider the impact of these tools on your context. If you don’t want to care, just trust me and use RocketSim https://www.rocketsim.app . I’m constantly monitoring and doing that work for my users. Choosing a tool isn’t enough. Your agent has to use it: - Remove the tool that competes with your preferred one. If your instructions prefer a dedicated tool, a second Simulator MCP with an image tool will still get picked sometimes. - Filter tools instead of removing the MCP. ios-simulator-mcp supports IOS SIMULATOR MCP FILTERED TOOLS , a comma-separated list of tools to leave out, such as ui view,screenshot . - Write the preference in your instructions. I use this line: “Always use RocketSim for any simulator interactions and follow its agent skill for instructions.” - Keep screenshots for visual checks. Layout, colors, and spacing need eyes. Navigation doesn’t. - Use good accessibility labels. Every tool in this article gets better when your elements have clear labels. RocketSim’s VoiceOver Navigator https://www.avanderlee.com/xcode/rocketsim-15-voiceover-navigator-pro-simulator-recordings/ shows you what your agent sees. Checking your own sessions is the only way to know what happens in practice. The token cleanup prompt https://aifundamentals.dev/token-cleanup-prompt/ asks your agent to analyze last week’s sessions, and it’s how that developer found the screenshots. Xcode 27’s MCP isn’t the screenshot offender I expected: it returns file paths and points the agent to a text hierarchy. It does read about seven times more per action than RocketSim’s compact output, and it can’t activate hidden accessibility elements, but it needs fewer calls and builds your app for you. If you’re already in Xcode’s MCP, it works. If you want to spend fewer tokens on navigation, a compact accessibility format wins. If you want to learn how to give your agents eyes without filling up their context, the AI Fundamentals course https://aifundamentals.dev?utm source=swiftlee&utm medium=article&utm campaign=simulator-navigation-conclusion covers validation loops and token usage step by step. Feel free to contact me or tweet me on Twitter https://twitter.com/twannl if you have any additional tips or feedback. Which Simulator tool does your agent use today? Thanks