getPlatformInfo
Retrieves smart glasses platform metadata: library version and available SDK capabilities to guide integration.
Instructions
Return static platform metadata: library version + the list of SDK capabilities the glasses expose. TWO INTEGRATION PATHS — decide which one BEFORE scaffolding. Voice apps (assistant, transcriptions, recordDiscrete, speak, audio streams) reach the glasses through the phone's own Bluetooth audio routing: NO vendor SDK, NO vendor credentials, NO connection page, NO pairing flow — and the complete agent runtime (turn-taking, barge-in, tool calling, local + cloud models) works there. Only CAMERA and DISPLAY require a vendor integration. If the developer hasn't said they need camera or display, they are on the voice path — do NOT send them through Meta account setup, a Developer Center registration, or a GitHub PAT they don't need. Phase 4 assistant runtime (glasses.assistant.start(provider) { tool(name, description) { body -> ToolResult } }) is the canonical voice-assistant API — the model owns wake/turn-taking/intent/confirmation, the customer writes tool bodies that act on app state. Lower-level primitives are still surfaced for fine-grained control (audio.transcriptions, audio.recordDiscrete, audio.speak, audio.audioChunks, camera.capturePhoto, camera.videoFrames, toggles, connection.state, …). The right first call for any new task — primes the agent on what primitives are available before writing handler code. Default response is COMPACT — capability names and categories only — keeping the typical first-call cost ~2KB. Per-feature call shape + idiom + gotchas comes from getCapabilityGuide(feature); full compositional patterns (assistant_agent_loop for the canonical glasses.assistant.start loop; voice_qa_assistant for the manual composition) from getCodeExample(pattern); conceptual docs from searchDocs(topic: 'assistant_runtime') for the assistant surface, or searchDocs(topic: 'voice_integration') for the lower-level primitives. Pass expand: ['capabilities.full'] for the machine-readable catalog with params/payload/requires/constraints. glasses is optional — defaults to meta; android_xr is also supported (preview) and meta_rayban is accepted as a legacy alias. Note the vendorless baseline needs no value here at all — voice apps run without a vendor; pass it explicitly for forward compatibility once additional vendors land. Already built on raw Meta DAT? Call getMigrationGuide — it maps your existing DAT symbols to Extentos primitives and gives an ordered cutover plan, rather than starting from scratch. USE at session start before scaffolding or writing handler code. DON'T USE for what's installed in the project (use inspectIntegration).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Optional opt-in expansions on top of the compact default. 'schema' = full JSON Schema document. 'capabilities.full' = per-primitive params/payload/requires/constraints. 'capabilities.advanced' = droppedPrimitives + futurePrimitives (informational only). | |
| glasses | No | Target 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. | |
| sections | No |