Setup and Generation tools

Post pure-SDK pivot, the Setup and Generation category is five tools: generateConnectionModule (the one-shot project scaffold, below) plus four connection-page-config tools that manage the per-project theming / section-visibility config the dashboard holds. Handler code is the customer's authoring surface — there is no initSpec / updateSpec / generateConsumer because there's no spec to populate, no callback dispatch table to generate. The agent peels from getCodeExample(pattern) to write the handler in Kotlin/Swift directly.

For your installed agent: call generateConnectionModule once per fresh project, then write handler classes. Subsequent code iterations don't need any more generation tool calls — rebuild + reinstall the app and the simulator auto-reattaches. This page is the reference for the one tool that does emit files.

generateConnectionModule

One-shot project scaffold. Emits the bootstrap module that wires Extentos.create(...) into the host app, build-script changes (Gradle / SPM), dependencies, permissions, and extentos.manifest.json. Two-call flow: the first call returns a placement question; the second call (after the developer picks where ExtentosConnectionPage should live) returns the full file set.

When to use

• Exactly once per platform per project — Android scaffolding on first Android target, iOS scaffolding on first iOS target
• After Extentos is removed (e.g., the dev wiped the /extentos directory) and you need to re-scaffold

When NOT to use

• When Extentos is already installed (use inspectIntegration to read current state)
• For per-handler code generation — there is no per-handler tool; write the handler against the SDK primitives by hand

Parameters

Two-call flow

Call 1 — without placement:

{ "platform": "android", "glasses": "meta_rayban", "appPackage": "com.example.myapp" }

Returns status: "needs_placement" plus the placement question and the 5 valid IDs. The agent reads the question to the developer, gets their pick, and calls again.

Call 2 — with placement:

{ "platform": "android", "glasses": "meta_rayban", "appPackage": "com.example.myapp", "placement": "dedicated_route" }

Returns the full file set: files[] (the bootstrap module to write), manifest (the extentos.manifest.json content), dependencies[], repositories[], buildConfigFields[], permissions[], suggestedRendering (the Compose / SwiftUI snippet for the chosen placement), plus developerInstructions walking the agent through applying everything.

What gets emitted

• files[] — ExtentosBootstrap.kt (Android) or ExtentosBootstrap.swift (iOS), with action: "create" (fully tool-managed; safe to overwrite on re-run). On iOS, also an action: "manual_patch" entry for the developer's App.swift with onOpenURL + scenePhase wiring instructions.
• manifest — extentos.manifest.json v2 content: library version, installedAt, platform / glasses / appPackage metadata, gradle or spm build-config record, empty permissions[] + capabilities[] + handlerNames[] arrays for the agent to populate as the handler grows.
• dependencies[] — com.extentos:glasses + com.extentos:glasses-ui (Android), plus com.extentos:glasses-meta when the declared capabilities include camera or display — that module is what carries the vendor SDK; a voice-only footprint omits it
• repositories[] — the Meta DAT GitHub Packages repo (Android only), for the mwdat-* artifacts that arrive through com.extentos:glasses-meta. Emitted ONLY for a camera/display footprint — a voice-only scaffold returns an empty repositories[] and needs no token.
• buildConfigFields[] — EXTENTOS_SESSION_URL = null placeholder (Android). Default null routes to auto-bind; only a URL-bake fallback (from createSimulatorSession) replaces it.
• permissions[] — base Bluetooth + INTERNET permissions. Capability-specific permissions get added later when the agent calls getPermissions(capabilities, platform) after declaring capabilities in the manifest.
• suggestedRendering — the Compose (Android) or SwiftUI (iOS) snippet for the chosen placement. Same shape searchDocs(topic: "connection_ui_placement") returns.
• developerInstructions — numbered steps for the agent to apply the scaffold + know what to do next (write handler code, update manifest.capabilities, validateIntegration, …).

What does NOT get emitted

• Handler classes. Those are the customer's authoring surface. The agent peels from getCodeExample(pattern) and writes them directly to the customer's repo.
• An extentos.spec.json. There is no spec runtime post-pivot.
• Callback dispatch stubs. There is no app_callback dispatch.

Errors

• invalid_arguments — platform must be "android" or "ios"
• invalid_arguments — glasses must be "meta" — or the legacy alias "meta_rayban" — android_xr gets its own message explaining that code scaffolding is Meta-only
• invalid_arguments — appPackage is required and must be a non-empty string
• invalid_arguments — placement must be one of dedicated_route, settings_subscreen, bottom_tab, modal_sheet, headless — only those 5 are valid
• account_required (HTTP 402) — the scaffold step (with placement) mints an account-bound project key; anonymous installs get the device-code login flow, same as createSimulatorSession. The informational first call (no placement) works anonymously

Connection-page config tools

The connection page (the screen the end user sees to pair their glasses) can be themed and have its sections toggled per project. These four tools manage that config: the dashboard/server is the single source of truth when a project is managed, and a committed extentos.connection-page.json mirrors it into the repo so the app themes correctly offline. The writes are account-scoped (run extentos-mcp login once).

The file-sync pair (regenerate / adopt) is Android-only today (iOS file-sync is Phase 4). The web dashboard's Connection section is the human-facing equivalent of set.

Retired generation tools

Pre-pivot the MCP server also exposed initSpec, updateSpec, and generateConsumer. All three are retired with the pure-SDK pivot:

• initSpec populated the first extentos.spec.json from agent-composed primitives → no spec to populate post-pivot.
• updateSpec mutated an existing spec and live-pushed the change to the simulator → no spec, no live-push.
• generateConsumer stubbed app_callback / stream-consumer handler classes from spec declarations → handler code is now hand-authored against the SDK directly.

Calls to these tool names against the post-pivot MCP server return unknown_tool. Use getCodeExample(pattern) for canonical compositions and write handler code directly.

Related

• Discovery tools — getPlatformInfo / getCapabilityGuide / getCodeExample (what the agent calls before this)
• Validation tools — inspectIntegration / validateIntegration (what the agent calls after this + after writing handler code)
• file_actions topic — how to apply each action value (create / manual_patch)

Related