Discovery and Planning tools

The two discovery tools answer "what does Extentos offer for this target?" before any project mutation. Both 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 or getExampleSpec 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, vendor capabilities, and (on demand) the AppSpec JSON Schema. The right first call for any new task.

When to use

• At session start, before any spec work
• When the agent needs to know which capabilities a vendor supports
• When the agent is building a compatibility table or capability check

When NOT to use

• For how to use a primitive — use searchDocs catalog topics (trigger_types, action_types, block_types, stream_types) instead — they carry inline minimal examples
• For checking what's installed in the project — use inspectIntegration

Parameters

Response

The default response is compact (~2 KB) — names, tier markers, global constraints — 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 ~36 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:

"For per-primitive params/payload/constraints, prefer searchDocs(topic: 'trigger_types' | 'action_types' | 'block_types' | 'stream_types'); or call again with expand: ['capabilities.full']."

Example — discovery at session start

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

Response (compact):

{
  "version": { "latestStable": "0.0.16", "...": "..." },
  "capabilities": {
    "vendor": "meta_rayban",
    "datVersion": "...",
    "blocks": [
      { "type": "capture_photo", "tier": "stable" },
      { "type": "capture_video", "tier": "stable" },
      { "type": "record_audio", "tier": "stable" },
      { "type": "speak_text", "tier": "stable" }
    ],
    "triggers": [
      { "type": "manual_launch", "tier": "stable" },
      { "type": "voice_command", "tier": "stable" },
      { "type": "capture_button", "tier": "stable" },
      { "type": "tap", "tier": "preview" },
      { "type": "double_tap", "tier": "preview" }
    ],
    "streams": ["..."],
    "actions": ["block_call", "ai_call", "branch", "set_variable"],
    "toggles": ["..."],
    "globalConstraints": { "..." : "..." }
  },
  "summary": "Returned library v0.0.16, meta_rayban capabilities (compact: 4 blocks, 2 streams, 5 triggers, 4 actions, N 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"
• invalid_arguments — "schema" is no longer a valid section — "schema" was promoted out of sections and into expand. Drop it from sections; pass expand: ["schema"] separately if the raw schema is genuinely needed.

getExampleSpec

Returns one of 8 canonical reference specs — fully-worked compositions for studying how complex flows compose. Reference library, not a starting template.

When to use

• On demand, when studying how a complex composition works
• When the agent needs an example of a multi-block, multi-trigger, multi-handler flow
• Pattern matching: "how does a translation app compose voice trigger → audio capture → AI call → speak?"

When NOT to use

• For simple cases — read searchDocs catalog topics first; they carry inline minimal examples sufficient for most specs
• As a starting template for initSpec — write the spec from primitives the developer's actual goal needs, not from a copy of an example

Parameters

The 8 patterns:

Response

{
  "pattern": "<id>",
  "description": "<one-sentence summary>",
  "spec": { "...": "...full AppSpec JSON..." },
  "usedPrimitives": {
    "blocks": ["capture_photo", "speak_text"],
    "streams": [],
    "triggers": ["voice_command"]
  },
  "handlerNames": ["vision", "..."],
  "codeSnippets": { "...": "..." },
  "summary": "Reference spec 'voice_assistant': 2 blocks, 0 streams, 1 trigger, 2 handlers. Study, don't copy whole — peel pieces relevant to your goal."
}

The summary is the agent-facing reminder: study, don't copy. Different developers' apps need different compositions, and a copy-paste of voice_assistant will rarely match a specific developer's goal.

Example — study the live translation pattern

{
  "pattern": "live_translation"
}

Response includes the full spec, the primitives used, and example handler code so the agent can compose its own translation app rather than recreate the example wholesale.

Errors

• invalid_arguments — pattern must be one of: voice_assistant, live_translation, scene_description, notification_reader, navigation_guide, video_call, object_detection, voice_notes — only the 8 canonical IDs are accepted

Why these are the first calls

getPlatformInfo answers "what's possible on this vendor?" — without that catalog, the agent is composing blind. getExampleSpec answers "how do other apps look that combine the primitives I'm considering?" — useful when the spec the developer is asking for is genuinely complex (multi-flow, multi-stream, multi-handler).

Most simple cases skip getExampleSpec entirely and go getPlatformInfo → searchDocs (for topic-specific catalogs with inline examples) → straight into generateConnectionModule. The example library is for the moments where studying a worked composition is faster than composing from scratch.

Related

• Setup and Generation tools — what the agent calls after discovery (the mutation tools)
• Search tools — searchDocs catalog topics with inline examples
• Capabilities — the conceptual layer behind what getPlatformInfo returns
• Tools overview — back to the full 18-tool catalog