Discovery and SDK reference tools

Three discovery + reference tools answer "what does Extentos offer for this target?" and "how do I actually call it?" before any project mutation. All three are pure-read, no side effects, no state changes, and don't count against the simulator-event meter.

For your installed agent: these tools are invoked directly via the MCP — once the server is registered with your agent, it calls getPlatformInfo / getCapabilityGuide / getCodeExample and gets live, structured responses. This page exists so an agent evaluating Extentos pre-install can see the tool surface, and so human developers and search engines can find the documentation outside an MCP context. The live MCP response is authoritative; the parameter tables and example responses below are illustrative.

getPlatformInfo

Returns the static platform catalog — library version + the list of SDK capabilities the glasses expose (audio.transcriptions, audio.recordDiscrete, audio.speak, camera.capturePhoto, camera.videoFrames, audio.audioChunks, toggles, connection.state, …). The right first call for any new task.

When to use

• At session start, before scaffolding or writing handler code
• When the agent needs to know which capabilities a vendor supports
• When the agent is building a capability declaration for the manifest

When NOT to use

• For how to call a primitive — use getCapabilityGuide(feature) for the per-feature minimal usage + gotchas
• For end-to-end compositional examples — use getCodeExample(pattern)
• For project-installed state — use inspectIntegration

Parameters

Response

The default response is compact (~2 KB) — names, categories, tier markers — sized to fit comfortably in the agent's context. Detail is opt-in via expand:

The compact-by-default design is intentional. Returning the full ~10 KB on every first call burns the agent's context window before any work. The summary field hints at what's available and how to expand.

Example — discovery at session start

{
  "sections": ["version", "capabilities"],
  "glasses": "meta_rayban"
}

Response (compact):

{
  "version": { "latestStable": "1.1.27-pair", "...": "..." },
  "capabilities": {
    "vendor": "meta_rayban",
    "datVersion": { "android": "0.7.0", "ios": "0.6.0" },
    "features": [
      { "name": "capture_photo", "category": "camera", "tier": "dat_native" },
      { "name": "capture_video", "category": "camera", "tier": "phone_side_workaround" },
      { "name": "video_frames", "category": "camera", "tier": "dat_native" },
      { "name": "record_audio", "category": "audio", "tier": "phone_side_workaround" },
      { "name": "audio_chunks", "category": "audio", "tier": "dat_native" },
      { "name": "transcription_incremental", "category": "audio", "tier": "phone_side_workaround" },
      { "name": "speak", "category": "audio", "tier": "phone_side_workaround" },
      "...etc"
    ],
    "toggles": ["listening_mode", "camera_streaming_enabled", "audio_capture_enabled", "transcription_enabled", "battery_save_mode", "voice_confirmations", "audio_video_coexistence_policy", "privacy_mode"],
    "globalConstraints": { "..." : "..." }
  },
  "summary": "Returned library v1.1.27-pair, meta_rayban capabilities (compact: N audio/camera primitives, 8 toggles)."
}

Errors

• invalid_arguments — sections must be a non-empty array — pass at least one of "version", "capabilities"
• invalid_arguments — glasses is required when sections includes "capabilities" — pass glasses: "meta_rayban"

getCapabilityGuide

Per-feature SDK usage guide — minimal Kotlin + Swift snippet, config args, gotchas, and which getCodeExample patterns exercise the feature. Pairs with getPlatformInfo (which lists feature names + categories) by adding the actual idiom for using each.

When to use

• When you know which feature you need (from getPlatformInfo) and want the canonical call shape
• When you're hitting a confusing failure — the gotchas list typically covers it
• When mapping out the manifest's capabilities array — confirm each entry's call shape before declaring

When NOT to use

• For a complete compositional pattern — use getCodeExample
• For capability discovery — use getPlatformInfo

Parameters

Accepted feature names span the capability primitives (capture_photo, capture_video, record_audio, transcription_incremental, speak, video_frames, audio_chunks, voice_command), the cross-cutting SDK surfaces (connection_state, toggles), the Phase 4 assistant runtime (assistant_runtime, assistant_start, assistant_tool, assistant_provider_openai, assistant_vision, assistant_session_runtime), and the deprecated Phase 3 conversation runtime (conversation_runtime, conversation_on_wake, conversation_listen, conversation_speak, conversation_ai_complete). The live input-schema enum is derived from the guide catalog, so the schema is the authoritative list.

Response

{
  "feature": "<name>",
  "summary": "<one-line shape>",
  "kotlin": "<minimal Kotlin call shape>",
  "swift": "<minimal Swift call shape>",
  "gotchas": ["<gotcha 1>", "<gotcha 2>", "..."],
  "relatedExamples": ["voice_qa_assistant", "barge_in_speak", "..."]
}

getCodeExample

Full canonical SDK compositions in Kotlin + Swift for the common voice-glasses patterns. Each pattern is a complete handler implementation the agent can peel from when writing real customer code.

When to use

• When you're about to write handler code and want the canonical shape
• When a customer asks for a feature that maps cleanly to one of the patterns
• When you need a paste-ready BYOK client (currently: Anthropic via byok_anthropic) — the LLM-client wrapper that the voice-Q&A and vision patterns reference as AnthropicClient

When NOT to use

• For capability discovery — use getPlatformInfo
• For per-feature minimal usage — use getCapabilityGuide

Parameters

The patterns:

Response

{
  "pattern": "<id>",
  "title": "<one-line title>",
  "description": "<2-3 sentence framing>",
  "code": {
    "kotlin": "<full Kotlin handler class, ~80-120 lines>",
    "swift": "<full Swift handler class, ~80-120 lines>"
  },
  "explanation": "<paragraph walking through what the code does>",
  "gotchas": ["<gotcha 1>", "<gotcha 2>", "..."],
  "relatedFeatures": ["transcription_incremental", "record_audio", "speak", "..."],
  "requiredDependencies": {
    "android": [{ "configuration": "implementation", "notation": "<maven-coord>", "appliedIn": "app/build.gradle.kts" }],
    "iosSwiftPackages": [{ "url": "<spm-url>", "from": "<version>", "products": ["<product>"] }]
  },
  "requiredPlugins": {
    "android": [{ "id": "<plugin-id>", "version": "<kotlin-version>", "appliedIn": "root build.gradle.kts", "applyFalse": true }]
  }
}

requiredDependencies and requiredPlugins are optional fields populated when a pattern needs Gradle / SPM deps beyond the SDK + stdlib (currently only byok_anthropic, which needs OkHttp + kotlinx-serialization-json on Android plus the Kotlin serialization plugin in BOTH the root and app build.gradle.kts). Agents iterating multiple patterns merge the union of all requiredDependencies / requiredPlugins into the host app's build files.

Example — peel the voice-Q&A composition

{ "pattern": "voice_qa_assistant" }

The response returns a full Kotlin CoachHandler class (and matching Swift) that subscribes to glasses.audio.transcriptions(), matches the wake phrase, calls glasses.audio.speak("What would you like to know?"), then glasses.audio.recordDiscrete(...) with silence-VAD, calls an LLM, and speaks the answer.

Errors

• invalid_arguments — pattern must be one of the ids in the pattern table above. The live input-schema enum is derived from the served catalog, so the schema (not this page) is the authoritative list.

Why these are the first calls

getPlatformInfo answers "what's possible on this vendor?" — without that catalog, the agent is composing blind. getCapabilityGuide answers "how do I call this specific feature?" — the agent calls it once per primitive it plans to use. getCodeExample answers "what does a complete real flow look like end-to-end?" — useful for the catalogued shapes; for ad-hoc business logic, the agent composes from primitives directly.

A typical first-time flow:

1. getPlatformInfo({ sections: ["version", "capabilities"], glasses: "meta_rayban" })
2. getCodeExample({ pattern: <matches what the user asked for> })
3. getCapabilityGuide({ feature: <each primitive the handler will use> })
4. generateConnectionModule(...)
5. <agent writes handler code, peeling from the code example>
6. validateIntegration()

Related

• Setup and Generation tools — what the agent calls after discovery
• Search tools — searchDocs for conceptual topics
• Capabilities — the conceptual layer behind what getPlatformInfo returns
• Tools overview — back to the full tool catalog