Skip to main content
Glama
extentos

extentos

createSimulatorSession

Provision a persistent browser simulator session for your smart glasses app, resuming an existing one if present, to test device capabilities without physical hardware.

Instructions

Get-or-create: provision a browser-based simulator session for this project, OR return the existing saved one. The simulator hosts your customer-built app running against a Meta-DAT-shaped transport stub — glasses.audio.transcriptions(), glasses.camera.capturePhoto(), glasses.audio.speak() and every other capability primitive flow through it exactly as they would on real hardware, so the agent can dogfood a handler in a browser before a Meta DAT is paired. Persistent-simulations model: each project + platform has at most one saved sim tied to the user's account. Calling this returns that sim's existing URL if it exists (status:'resumed') instead of creating a new one. Rotating to a new sim identity is a deliberate two-step act: deleteSimulatorSession({ sessionId }) first, THEN mint again. There is no force-fresh flag, on purpose — a discarded sim leaves device registrations behind that outlive it, so a silent replace can auto-bind the next mint to an app that is already gone. First-time per project: creates the sim (status:'active'); subsequent calls in any future session return the same sim. Auto-bind (response carries autoBind:'attached'): when the dev's running app is reachable via the MCP local bridge, attaches it to the session — no rebuild needed. Otherwise URL-bake fallback (Android: buildConfigField patch; iOS: plist write). For 'resumed' responses, the URL is unchanged from last time so no rebuild/patch is needed regardless. Iteration model — DO NOT call this per change: app-code edits rebuild + reinstall and reattach automatically; the simulator URL is stable. Calling this again on the same project just returns the same sim — cheap, idempotent. First-link auto-poll: when account-linking is required, by default polls completeAuthLink internally for autoLinkSeconds (default 30) and re-mints on success. autoLink: false for CI / non-interactive contexts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
glassesYesTarget glasses vendor. Canonical: 'meta'. 'meta_rayban' is a legacy alias (same vendor) kept for compatibility. 'android_xr' is EXPERIMENTAL/PREVIEW (Android XR projected glasses — no shipping hardware) and 'brilliant' is PREVIEW (Brilliant Labs Halo and Frame — the Extentos BLE transport is built on BOTH platforms and Halo is orderable, but the vendor says first units ship early August 2026, so nothing has run on a device and there is no emulator either). For both, simulator sessions CAN be minted, so an app's behaviour under that device identity is testable today; code scaffolding remains Meta-only. ⚠️ PLATFORM CONSTRAINT: 'android_xr' is Android-ONLY and minting it with platform:'ios' is REFUSED — Google's model is a projected activity, which is an Android activity, so no iOS transport can exist and simulating one would teach your app a combination no device can be. 'meta' and 'brilliant' mint on either platform.
autoLinkNoWhen true (default), if the backend returns auth_required, this handler polls completeAuthLink internally for `autoLinkSeconds` and re-mints on success. Set false in CI / non-interactive contexts.
platformNo
projectPathNoAbsolute path to the app project — the SAME value you pass to generateConnectionModule and validateIntegration. This is how a sim gets BOUND to a project: the manifest there supplies the key that makes this call get-or-create rather than mint. **Omitting it silently falls back to the process working directory**, so a call made from a directory with no extentos.manifest.json returns an UNBOUND sim that is shared across every unscaffolded directory for this account — which is how a workspace ends up with a row of unnamed, indistinguishable simulators. Pass it explicitly once the project exists.
recordBinaryNo
autoLinkSecondsNoMax seconds to wait for the user to approve the verification URL when autoLink is true. Default 30. Clamped to [10, 300].
autoOpenBrowserNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so thoroughly. It discloses get-or-create semantics, the one-sim-per-project model, autoBind attached vs URL-bake fallback, auto-polling of completeAuthLink with re-mint on success, and the platform constraint that android_xr is Android-only. It even warns about the unbound-sim pitfall when projectPath is omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with bolded section headers and each paragraph addresses a distinct concern. It is front-loaded with the core get-or-create purpose, then dives into lifecycle, identity, auto-bind, and auth. While lengthy, every sentence contributes meaningful information for a complex tool with no annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description comprehensively covers purpose, lifecycle, idempotency, auth flow, platform constraints, and pitfalls like the projectPath omission. It omits semantics for three parameters (platform, recordBinary, autoOpenBrowser) and does not describe the full return shape beyond status and autoBind, but overall it is unusually complete for an un-annotated tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 57%, and the description adds significant meaning for four of seven parameters: glasses (vendor/experimental status, platform constraint), autoLink (internal polling behavior, default), projectPath (binding semantics, fallback to cwd), and autoLinkSeconds (clamping). However, platform, recordBinary, and autoOpenBrowser are left undocumented in both schema and description, preventing a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Get-or-create' and clearly states it provisions a browser-based simulator session or returns the existing saved one. It also distinguishes itself from sibling tools like deleteSimulatorSession by explicitly explaining the two-step rotation process, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'DO NOT call this per change' and explains that app-code edits rebuild automatically, so repeated calls are unnecessary. It also instructs users to call deleteSimulatorSession before re-minting and recommends autoLink:false for CI contexts, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/extentos/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server