Supported agents

Extentos generates native mobile app code (Swift for iOS, Kotlin for Android), so the agents that work with it are the ones that target native mobile development with Model Context Protocol support. Web-first AI builders like Replit Agent, Lovable, Bolt.new, or v0.dev aren't relevant for Extentos work — not because they lack MCP, but because they ship web apps, not native mobile.

The MCP-capable agents that DO work are surprisingly portable: most of them run anywhere you can run their interface — Claude Code in particular runs in any terminal, which includes the terminal panel inside Android Studio, Xcode, IntelliJ, VS Code, or any IDE you already use. So the question isn't "which IDE supports Extentos?" — it's "which AI agent supports MCP, and where can I run it?" This page covers the per-agent capability differences and the IDE-portability picture.

Quick recommendation

Tier 1 — recommended for Extentos work

These four hosts have native, mature MCP support and have been verified end-to-end with Extentos.

Claude Code (terminal CLI)

Best for: cross-platform Extentos work where the agent edits files across ios-app/, android-app/, and any shared library or backend code in one coherent session.

Recommended setup: install with the CLI command above, run Claude Code from your project root, you're set.

Cursor

Best for: developers who already live in a VS Code-style IDE and want Extentos integrated into their existing editor workflow.

Recommended setup: add Extentos via the JSON config (see install), open both ios-app/ and android-app/ as workspace folders if you're working cross-platform.

Windsurf

Best for: same audience as Cursor — IDE-embedded workflow, VS Code-style.

Capability profile is essentially identical to Cursor:

Recommended setup: see install.

Cline (VS Code extension)

Best for: developers using Cline inside VS Code who want explicit per-tool approval before the agent acts.

Recommended setup: add Extentos via Cline's MCP Servers tab — see install.

One Cline-specific gotcha: the per-tool approval flow can be tedious during the canonical Extentos sequence (generateConnectionModule → initSpec → generateConsumer → validateIntegration). Set Cline to auto-approve Extentos tools after the first run if you want the smoother flow.

Tier 2 — works, less battle-tested with Extentos

These hosts have MCP support but haven't been verified end-to-end with the full Extentos workflow. They should work — Extentos uses standard MCP — but expect rougher edges.

For all of these, use the generic MCP host JSON snippet.

Built-in IDE agents — Gemini, Xcode AI, JetBrains AI

If you're in Android Studio, IntelliJ, or Xcode, these IDEs have their own built-in AI assistants (Gemini in Android Studio, Xcode AI features, JetBrains AI Assistant). MCP adoption across these built-in agents has been moving — the only correct answer to "does it support MCP?" is to check the IDE's current documentation, since this space is shifting month-to-month in 2026.

Two scenarios, both of which keep you in your IDE:

If the built-in agent supports MCP — register Extentos via whatever MCP config mechanism the IDE provides (typically a JSON file path the IDE points at). The agent calls Extentos's 18 tools directly inside your IDE. Same mcpServers JSON pattern as Cursor / Windsurf works in any standards-compliant MCP host.

If the built-in agent doesn't support MCP yet — every one of these IDEs ships with a built-in terminal panel, and Claude Code (or any MCP-capable agent) runs there:

• Android Studio: open the bottom Terminal tab → run claude (or npx @extentos/mcp-server directly) → Claude Code now operates on your project. Cross-platform reach because Claude Code reads the filesystem from cwd.
• Xcode: Xcode's built-in terminal access is more limited. Most developers run a separate terminal app side-by-side with Xcode (e.g., iTerm2) and let Claude Code drive the Extentos work there. Xcode keeps doing what it's good at — code reading, builds, simulator runs, debugging.
• IntelliJ / WebStorm / etc.: same as Android Studio — built-in terminal hosts Claude Code or any other MCP agent.

The pattern: the IDE's built-in agent is one of many possible agents you can use, not the only one. Either the built-in supports MCP and you call Extentos directly, or you bring your own agent in the same IDE's terminal. Your editor, build tools, breakpoint debugger, and simulator keep working unchanged — only the AI assistant choice differs.

Verify current MCP support yourself. The doc above reflects the project's design intent (Extentos is built for any MCP-compatible client including Gemini in Android Studio per the architectural plan). What's currently shipped by IDE vendors changes faster than this page updates. Check Google's Gemini in Android Studio docs, Apple's Xcode AI release notes, or JetBrains' AI Assistant docs for the current MCP support status before assuming.

What's actually different per host for Extentos work

Distilled into the Extentos-specific capabilities that matter most:

1. Cross-platform reach

This is the biggest difference. Extentos generates code in:

• The developer's iOS app source (Swift)
• The developer's Android app source (Kotlin)
• Shared spec files (JSON)

A host that can read and edit both platforms simultaneously is unconstrained. A host locked to one platform forces context-switching between two agent sessions.

2. Browser auto-open behavior

When createSimulatorSession is called (or the device-code auth flow fires), the MCP server attempts to open a browser tab to the URL — open on macOS, xdg-open on Linux, cmd start on Windows. This is best-effort, and the URL is always also returned in the structured tool response regardless of whether the OS browser command succeeded.

So when browser auto-open can't happen — EXTENTOS_NO_AUTO_OPEN=1 is set, the agent runs in a headless / SSH / sandboxed environment, the OS command isn't available, the agent host doesn't have OS-level browser-launch permission — the agent simply surfaces the URL in its response and the developer copies it into their browser manually. Nothing is lost; auto-open is a UX nicety, not a requirement.

How the URL appears varies by host:

• Claude Code (terminal) — printed as plain text in the terminal output, often with surrounding context like "Open this URL in your browser: https://extentos.com/s/..."
• Cursor / Windsurf / Cline — appears inline in the chat panel, typically rendered as a clickable link the developer can click directly
• Headless / cloud-hosted agents — printed in whatever output channel the agent uses; developer copies and pastes into a local browser

The flow is always: tool returns URL in response → agent surfaces URL → developer opens it (whether by auto-open, click, or copy-paste). No failure mode here — the URL is always available.

3. Auto-bind reach (the localhost:31337 bridge)

Auto-bind requires the MCP server and the developer's app to be reachable on the same 127.0.0.1 interface. In the standard "developer on a laptop, emulator or USB-tethered phone connected to the same laptop" setup, this just works for any of the hosts above.

It does not work when:

• The developer's phone is on a cellular network without USB tethering and adb reverse tcp:31337 tcp:31337 hasn't been run
• The agent host is cloud-hosted (e.g., Claude.ai/code's web sandbox) with the MCP server running in the cloud while the developer's app runs on their local machine
• Port 31337 is already in use by another MCP instance

When auto-bind isn't reachable, the agent uses the URL-bake path: createSimulatorSession returns a BuildConfig.EXTENTOS_SESSION_URL snippet (Android) or extentos.session.plist payload (iOS) that the agent writes into the developer's app, and the developer rebuilds once. One rebuild step versus the zero-rebuild auto-bind happy path.

4. Long-running tool handling

completeAuthLink polls for up to 600 seconds. createSimulatorSession can take a few seconds to provision. Hosts vary in how they surface this wait:

• Claude Code: prints "Polling for up to 600s..." in the terminal; clear and unambiguous
• Cursor / Windsurf: show a spinner or progress indicator in the chat panel
• Cline: shows the long-running tool prominently with a cancel button

All four handle the wait correctly — none of them time out tool calls during normal Extentos operation.

5. Tool approval UX

How permissive the host is about letting the agent invoke tools without explicit approval:

For Extentos, the canonical agent flow uses ~7 tools in sequence on a fresh project. Cline's per-tool approval can be 7 clicks; Claude Code's after-first auto-approve is closer to zero. Both work; the choice is workflow preference.

Frequently asked questions

Can I use Extentos with Android Studio?

Yes. Open Android Studio's built-in Terminal panel (bottom dock) and run Claude Code there — Claude Code is just a CLI, and it works in any terminal including Android Studio's. The MCP server attaches to your Claude Code session, and you can edit cross-platform code with simultaneous reach to both ios-app/ and android-app/. Android Studio's own Gemini integration doesn't support MCP yet, but you don't have to use Gemini — any MCP-capable agent works in the same terminal panel.

Can I use Extentos with Xcode?

Yes — same idea. Run Claude Code (or another MCP-capable agent) in a terminal window alongside Xcode. Xcode keeps doing what it's good at (code reading, building, running the iOS Simulator); the MCP-capable agent handles the Extentos work in the terminal. They coexist cleanly because they don't compete for the same surface.

What if my host doesn't support MCP at all?

Then it can't run Extentos. The MCP protocol is the integration boundary; without it, there's no way for the agent to call Extentos's tools. Options: switch to an MCP-supporting host (Claude Code is the smoothest install), or use a Tier-1 host alongside your existing tool.

Can I use multiple agent hosts at the same time?

Yes — Extentos's MCP server doesn't care which host calls it. Each host runs its own MCP server instance via npx; the per-machine installId is shared (so they hit the same anonymous-meter / linked account), but otherwise the sessions are independent. Useful pattern: Cursor for primary development, Claude Code in a side terminal for one-off Extentos operations.

Does the auto-bind dev loop work with cloud-hosted agents?

No, by design — auto-bind requires the MCP server's 127.0.0.1:31337 listener to be reachable from the developer's app. A cloud-hosted agent's MCP server runs on a remote machine; the developer's emulator or phone runs locally. The two are in different network namespaces. Use the URL-bake path instead — the agent generates the EXTENTOS_SESSION_URL snippet and the developer pastes it locally.

Does Gemini in Android Studio support Extentos directly?

The project's design scope includes Gemini in Android Studio as a target host (per the internal architecture plan that explicitly lists "Gemini in Android Studio" alongside Claude Code, Cursor, and Codex). Whether it currently has MCP host support depends on Google's most recent Android Studio release — Google's AI integration has been evolving fast in 2026, so check the current Gemini in Android Studio docs for MCP support status. If MCP is supported, Extentos works directly. If it's not yet, run Claude Code (or any MCP-capable agent) in Android Studio's Terminal panel — same workflow either way.

What about Replit, Lovable, v0.dev, Bolt.new?

These are AI builders for web apps (React, Next.js, etc.), not native mobile. Extentos generates native iOS Swift and Android Kotlin code — wrong target for these tools. Not an MCP support issue; just a different category of product. If you're building a web app, Extentos isn't the right fit at all (your wearer experience would have to be a mobile-web app, which Meta DAT and the public smart-glasses toolkits don't support today).

What about GitHub Copilot, Cody?

These will likely add MCP support over 2026, given MCP's adoption trajectory. Track the changelog for updates as new hosts get verified.

Does Extentos work with web app builders like v0.dev or Lovable?

No. Extentos targets native iOS and Android apps that connect to smart glasses over Bluetooth via Meta DAT. Web app builders ship to a different runtime (browser-based React apps, etc.) where the smart-glasses connection isn't possible through public toolkits. The mismatch is at the artifact level, not the integration level — even if Lovable shipped MCP support tomorrow, the apps it generates couldn't talk to Ray-Ban Meta glasses.

Related

• Install the MCP server — per-host install commands and JSON snippets
• MCP server overview — the 18-tool catalog and canonical agent flow
• Quickstart with an AI agent — install + first prompt + verify
• Architecture — how the MCP, library, backend, and your app fit together