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

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.

Why screenshots are expensive for agents

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. The AI Fundamentals course teaches you to spot this kind of waste in your own sessions in module 8, and the token cleanup prompt is the one that surfaced the screenshots in this example.

How Xcode 27’s MCP navigates the Simulator

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.

Comparing it with RocketSim’s CLI

RocketSim 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 is built for agents, and a bundled Agent Skill teaches your agent how to use it. I introduced it in 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:

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.

Other options

Two other tools are worth knowing:

• 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 returns the accessibility hierarchy from snapshot_ui and turns it into numbered references. It uses 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. I’m constantly monitoring and doing that work for my users.

Keep your agent on the efficient path

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 shows you what your agent sees.

Checking your own sessions is the only way to know what happens in practice. The token cleanup prompt asks your agent to analyze last week’s sessions, and it’s how that developer found the screenshots.

Conclusion

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 covers validation loops and token usage step by step.

Feel free to contact me or tweet me on Twitter if you have any additional tips or feedback. Which Simulator tool does your agent use today?

Thanks!