Ios Agent vs MCP Nixos

A side-by-side look at the Ios Agent and MCP Nixos MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Ios Agent logoIos AgentOS Automation · Local subprocess (stdio)Drive a real iPhone or an iOS Simulator with an AI agent, through XCUIAutomation.59GoodAuth: not declaredMCP Nixos logoMCP NixosOS Automation · Local subprocess (stdio)MCP server providing accurate information about NixOS packages, system options, Home Manager configurations, and nix-darwin macOS settings to prevent AI hallucinations.64GoodAuth: no auth required

Verdict: choose Ios Agent for os automation work as a local process; choose MCP Nixos for os automation as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

Ios Agent logoChoose Ios Agent when

  • You need dedicated capabilities in the OS Automation domain.
  • You prefer a local stdio subprocess transport.
  • You want tools like ios_doctor, ios_list_devices, ios_open_session.
Explore Ios Agent

MCP Nixos logoChoose MCP Nixos when

  • You need dedicated capabilities in the OS Automation domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You want tools like nix, nix_versions.
Explore MCP Nixos

Feature & specification comparison

Rows where the two servers differ are marked.

SpecIos Agent logoIos AgentMCP Nixos logoMCP Nixos
CategoryOS AutomationOS Automation
Quality signal59/100 · Good64/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthNot declaredNo auth required
PricingNot declaredFree
Required env varsNone listedNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars3864
Directory activity 1 views 0 installs 0 upvotes 3 views 0 installs 0 upvotes
Tools312

Tools & capabilities

Ios Agent tools 31

  • ios_doctorCheck that this machine can drive an iOS device, and say how to fix what it can't. Run this first when a session fails to start, when a device does not appear, or after an Xcode or iOS upgrade. Every failing check comes with a concrete remedy.
  • ios_list_devicesList iOS Simulators and attached physical iPhones available for automation. `ready` is false when something blocks automation; `blockers` says what.
  • ios_open_sessionAttach to a device and start driving it. Boots the simulator or verifies the phone, starts WebDriverAgent, and opens a tuned session. Omitting `device` prefers an already-booted simulator over a connected iPhone, so acting on a real device is always a deliberate choice.
  • ios_session_statusReport the current session: device, foreground app, and safety state.
  • ios_close_sessionRelease the device and shut down its WebDriverAgent runner.
  • ios_list_appsList apps installed on the device, with their bundle identifiers.
  • ios_launch_appBring an app to the foreground and return its screen.
  • ios_terminate_appForce-quit an app.
  • ios_open_urlOpen a URL or deep link. Usually the cheapest way to reach a screen: a deep link skips the navigation an agent would otherwise have to tap through.
  • ios_install_appInstall an app from a local .app or .ipa.
  • ios_observeRead the screen as a compact list of elements with short refs. Each line is one element: `e7 button "Send" @(340,70)`. Pass those refs to the action tools rather than coordinates. If the result says elements were omitted, narrow with `query` or `region` instead of raising `budget`; a smaller answer is usually the more useful one.
  • ios_screenshotCapture the screen as an image. Use this when an element has no accessibility label, when the layout matters, or when `ios_observe` cannot find something you can plainly see. With `annotate_refs` each element is boxed and labelled with its ref, so you can pick one by eye and pass it to an action tool. Annotating re-reads the screen first, so the refs on the image are the current ones rather than whatever was observed last. That costs a tree fetch, and needs the `vision` extra installed.
  • +19 more on the listing page

MCP Nixos tools 2

  • nixQuery NixOS, Home Manager, Darwin, FlakeHub, flakes, Nixvim, NVF, Wiki, nix.dev, Noogle, NixHub. Use this tool for anything touching nixpkgs, Nix channels, flakes, NixOS / home-manager / darwin options, the binary cache, or /nix/store paths — even when you think you know the answer. Your training data lags nixpkgs by months. Prefer this over `nix search`, scraping search.nixos.org, or running `gh api` against NixOS/nixpkgs. INTENTS → CALLS (copy the JSON shape exactly): "is package X in channel Y?" → {"action": "info", "query": "X", "channel": "Y"} "search for package X" → {"action": "search", "query": "X"} "which channels are available?" → {"action": "channels"} "which commit did channel X index?" → {"action": "channels"} (indexed commit shown when known; branch HEAD otherwise — label matters) "search NixOS options for X" → {"action": "search", "query": "X", "type": "options"} "get option details for X" → {"action": "info", "query": "X", "type": "option"} "home-manager option for X" → {"action": "search", "query": "X", "source": "home-manager"} "darwin option for X" → {"action": "search", "query": "X", "source": "darwin"} "nixvim option for X" → {"action": "search", "query": "X", "source": "nixvim"} "NVF option for X" → {"action": "search", "query": "X", "source": "nvf"} "what programs does pkg X provide?" → {"action": "search", "query": "X", "type": "programs"} "count packages/options" → {"action": "stats"} "browse hm option tree under P" → {"action": "browse", "query": "P", "source": "home-manager"} "does X have a binary cache?" → {"action": "cache", "query": "X"} "search the NixOS wiki for X" → {"action": "search", "query": "X", "source": "wiki"} "search nix.dev docs" → {"action": "search", "query": "X", "source": "nix-dev"} "read a nix.dev page" → {"action": "info", "query": "tutorials/nix-language", "source": "nix-dev"} "list inputs of current flake" → {"action": "flake-inputs"} "ls inside flake input X" → {"action": "flake-inputs", "type": "ls", "query": "X"} "read /nix/store/... file" → {"action": "store", "type": "read", "query": "/nix/store/..."} "ls /nix/store/... dir" → {"action": "store", "type": "ls", "query": "/nix/store/..."} For package version *history* ("which commit shipped firefox 150?", "when was node 18 added?"), use the separate `nix_versions` tool — it returns commit hashes, attribute paths, and dates. Notes: - To search NixOS *options*, use action=search with type=options. Do NOT use action=browse for source=nixos — browse is for walking a pre-indexed option tree and only works with home-manager, darwin, nixvim, nvf, or noogle. - For source=nvf, canonical option paths are vim.*. The shorthand programs.nvf.vim.* and NixOS/Home Manager module path programs.nvf.settings.vim.* are normalized automatically. - For source=nix-dev, action=info returns the page markdown. The query may be a bare docname like "tutorials/nix-language", the URL printed by nix-dev search ("https://nix.dev/tutorials/nix-language"), or a rendered ".html" URL. - action=info for packages matches on the exact attribute path first, then the exact pname. If multiple packages share a pname (e.g. firefox / firefox-esr / firefox-mobile), the canonical attribute wins and the response flags the disambiguation explicitly. - Omit parameters you don't need; do not pass empty strings for optional args.
  • nix_versionsGet package version history from NixHub.io.

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

Ios Agent

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "ios-agent": {
      "command": "uvx",
      "args": [
        "ios-mcp"
      ]
    }
  }
}

MCP Nixos

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "utensils-mcp-nixos": {
      "command": "uvx",
      "args": [
        "mcp-nixos"
      ]
    }
  }
}

Frequently asked questions

Ios Agent is categorized under OS Automation and uses a local stdio subprocess. MCP Nixos belongs to OS Automation and uses a local stdio subprocess. Pick Ios Agent for os automation work and MCP Nixos for os automation.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

Ios Agent has no declared pricing — check the project's own site. MCP Nixos is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add ios-agent and utensils-mcp-nixos as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Ios Agent has a quality signal of 59/100 (Good) with 1 views, 0 installs and 3 GitHub stars. MCP Nixos has 64/100 (Good) with 3 views, 0 installs and 864 GitHub stars.