Search tools

searchDocs is the conceptual / narrative layer of the MCP tool surface. The other tools answer "what / how / where" with structured data; searchDocs carries the prose that explains the why and the idiom.

searchDocs

Search the Extentos documentation corpus by topic or keyword. Topic IDs are stable; the corpus is regenerated when the library or backend changes shape.

When to use

• To learn how the SDK is meant to be composed (custom_handlers, voice_integration)
• To read the conceptual model for a specific area (toggles, connection_state_model, permissions)
• To look up the simulator dev-loop semantics (simulator_browser_mode, auto_bind_session_lifecycle, local_bridge_discovery)
• To understand the manifest schema (manifest_format), file-action contract (file_actions), event-log chips (event_log_schema)

When NOT to use

• For the live capability list — use getPlatformInfo
• For per-feature call shape — use getCapabilityGuide
• For complete compositional patterns — use getCodeExample
• For project-installed state — use inspectIntegration

Parameters

At least one of topic or query is required — calling with neither returns invalid_arguments.

Aligned post-pivot topics

Read these to learn the current model:

• getting_started — the full topic index. Read first to see what's available.
• custom_handlers — the canonical SDK-composition doc. How to write a Handler class that subscribes to capability primitives. The post-pivot replacement for the retired app_callback_guide.
• voice_integration — STT + TTS architecture, what the simulator routes through vs what production routes through.
• connection_ui_placement — five placement options (dedicated_route / settings_subscreen / bottom_tab / modal_sheet / headless) with Compose + SwiftUI snippets.
• host_app_scaffold — copy-pasteable empty-app template for devs who don't have an existing app yet.
• auto_bind_session_lifecycle — how the running app reattaches to a persistent simulator session via the MCP local bridge.
• local_bridge_discovery — the 127.0.0.1:31337/whoami probe protocol.
• device_code_flow — account-linking lifecycle when createSimulatorSession returns auth_required.
• connection_state_model — the 6 GlassesState buckets + transitions.
• permissions — full Android manifest + iOS Info.plist + Meta DAT scope derivation.
• production_checklist — categories, what's personalized vs static.
• concurrency_modes — running multiple handler subscriptions concurrently, restart semantics, scope lifetime.
• multi_platform_projects — how project identity comes from appPackage (config.appId, decoupled from the store bundle id) and how the same app id shares one project across platforms.
• library_api — the post-pivot SDK reference: ExtentosGlasses and its typed sub-clients (connection / camera / audio / display / runtime / toggles / voice / assistant / telemetry / observability / device / …), the ExtentosResult + error types, and the Photo / Videos URI helpers.
• toggles — all 8 runtime toggles, their enforcement status, the canonical read / write patterns.
• audio_video_coexistence — A2DP / HFP profile conflict policy.
• simulator_browser_mode — the persistent-sim model, get-or-create semantics, iteration model.
• simulator_session_lifecycle — mint once, reuse, delete deliberately: why a project has exactly one sim per platform, why sims never expire, and the two-step rotation.
• event_log_schema — every event chip (errors / voice / camera / display / ai / lifecycle / custom) and event type the structured log carries.
• manifest_format — extentos.manifest.json v2 shape (post-pivot — no spec field, no integration.{blocks,streams,triggers,handlerNames,togglesOverridden} sub-object).
• file_actions — the two post-pivot file-action values (create / manual_patch) and how to apply each.
• connection_ui — ExtentosConnectionPage customization layers (drop-in / themed / @ExtentosEscapeHatch).
• connection_page_schema — the extentos.connection-page.json theming + section-visibility schema the connection-page-config tools read and write.
• credentials — the credential model: the dashboard vault, write-without-knowing entry, BYOK vs. Meta DAT identity, and what's stored where.
• simulator_local_mode — the LocalSimTransport dev loop: Extentos's own in-memory deterministic transport (no DAT SDK, no network), the fastest inner loop.
• voice_ux_guide — wake-phrase UX: there's no DSL matcher, the canonical case/punctuation normalizer, and the phrase-collision pitfalls getVoiceCommandGuidance catches.
• constraints_and_limitations — the Meta DAT constraints (A2DP/HFP exclusivity, no custom gestures, "Hey Meta" reserved, background limits).

This list is illustrative, not exhaustive — fetch getting_started for the live topic index.

Phase 4 / assistant + gateway

The current voice-assistant and managed-AI surface. Read assistant_runtime first for any voice-assistant work:

• assistant_runtime — the Phase-4 assistant runtime. glasses.assistant.start(provider) { tool(...) }: the model owns wake / turn-taking / intent / confirmation; the customer writes tool bodies against app state. Read this first for voice assistants.
• conversation_runtime — deprecated Phase-3 conversation runtime (glasses.conversation.onWake { listen() / speak() / ai.complete() }). Migration reference only; new code uses assistant_runtime.
• agent_e2e_testing — the agent-driven end-to-end test loop for assistants: inject a transcript / utterance, drive the real provider, assert tool calls, and verify across the event log + adb + screencap + library state with no human in the loop.
• managed_gateway — the Extentos managed AI gateway: the default zero-config path (no provider key in your app), no bring-your-own-key option, metering, and attribution via the project key.
• conversation_memory — the assistant memory model: within-session working memory plus the persistent per-wearer profile.
• display — the glasses-display capability (Ray-Ban Display): runtime-detected, additive show(...) trees, Neural-Band navigation, and the never-throw degrade on devices without a display.

Retired topics

trigger_types, action_types, block_types, stream_types, spec_format, template_syntax, app_callback_guide, spec_validation_rules — all retired with the pure-SDK pivot. Calling searchDocs with these IDs returns an unknown_topic error (Topic "<id>" is not one of the N indexed topics). The conceptual ground each covered is now in custom_handlers (for the composition layer) and library_api (for the SDK surface). Pre-pivot users searching for them should be steered to those two.

Response

{
  "results": [
    {
      "topic": "<id>",
      "title": "<topic title>",
      "content": "<full topic body, ~2-30 KB depending on topic>",
      "relatedTools": ["getPlatformInfo", "getCapabilityGuide", "..."]
    }
  ],
  "totalResults": 1,
  "mode": "full",
  "summary": "Returned full content for topic \"<id>\"."
}

relatedTools steers the agent to the structured tools that complement the prose.

Related

• Discovery tools — the structured tools that pair with searchDocs
• Tools overview — back to the full tool catalog

Related