Setup and Generation tools

Post pure-SDK pivot, the generation surface is intentionally small: one scaffolding tool. 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), or https://github.com/extentos/swift-glasses with products GlassesCore / GlassesUI / GlassesDebug (iOS).
• repositories[] — mavenLocal() plus the Meta DAT GitHub Packages repo (Android only).
• 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_rayban"
• 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

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)