Production tools
The Extentos MCP server's production tools — getProductionChecklist (personalized ship-readiness checklist based on declared capabilities + handler names) and getCredentialGuide (step-by-step credential setup for Anthropic, OpenAI, Google Cloud, DeepL, Azure, AWS Bedrock, HuggingFace, or custom providers). Pre-ship gates.
Two tools the agent invokes at the end of the dev loop, before the developer cuts a release. Both are pure-read, no side effects.
getProductionChecklist
Personalized production-readiness checklist based on what the handler uses. The agent passes the manifest's capabilities array + handlerNames array; the response is a categorized list of "before you ship" items the agent walks through with the developer.
Parameters: capabilities: string[] (required; SDK feature names the handler uses), handlerNames: string[] (optional; the customer's handler class names — drives the API-keys step), platform: "android" | "ios", projectPath (optional).
Response: 9 categories of checks — Meta Developer Account, DAT Registration, Credential Swap, API Keys (skipped if no handlers declared), Permissions Audit, Foreground Service / Background Modes (skipped if no continuous-capture capabilities), Transport Config, Real-Hardware Verification (when the app uses voice / video / audio capture), Store Listing. Each step is personalized to the developer's actual app: a no-camera app skips camera entries, an app with speak but no transcription_incremental skips STT-related steps.
The Real-Hardware Verification step is the load-bearing one — Extentos validates simulator integration cleanly, but final-mile glass-fit (Bluetooth latency on the developer's specific glasses, real-world A2DP/HFP coexistence, camera/mic fidelity in actual wearing conditions) only verifies on hardware. The checklist surfaces it as required before cutting a release.
getCredentialGuide
Step-by-step credential setup for the BYOK AI providers the handler uses, plus Meta DAT registration. The agent passes the list of providers it's about to call from the handler; the response walks the developer through each.
Parameters: services: string[] (required; one or more of anthropic, openai, google_cloud_vision, google_translate, google_gemini, deepl, azure_cognitive, aws_bedrock, huggingface, custom), handlers: string[] (optional; handler class names — used to label which handler each provider is for), platform: "android" | "ios".
Response: per-provider numbered steps (sign-up URL, account-creation cost if any, where to find the API key, what to paste where, how to test). Plus a Meta DAT registration walkthrough — required at first real-hardware test (one-time, free, ~15–30 min): create Meta Developer account, enable Wearables DAT, register package name + signing signature (Android) or bundle ID + Team ID (iOS), copy App ID + Client Token into the manifest (Android) / Info.plist MWDAT dict (iOS).
Android storage guidance: the response recommends a local.properties-first pattern reading the key at Gradle config time and injecting via resValue + R.string at runtime. CI/release builds fall back to environment variables baked into the same snippet via ?: System.getenv(...). This is deliberately NOT env-var-first: Gradle daemons cache the env at startup, so a rotated key in your current shell isn't visible until you ./gradlew --stop and restart the IDE — the failure mode the R2 dogfood F-R2-9 finding surfaced as "I couldn't read the cards." resValue is preferred over buildConfigField because BuildConfig String constants are compile-time-inlined by kotlinc, and stale keys silently survive rotations (the original BuildConfig API-key gotcha that landed in dogfood F22).
BYOK client return shape: the canonical Anthropic client emitted by getCodeExample('byok_anthropic') returns a sealed LlmResult type with Ok / AuthFailure / NetworkError / Empty variants — NOT a bare String. Handler code pattern-matches each variant into a distinct user-facing line so the end user can tell "fix your API key" from "the AI couldn't see well enough" from "try again, network's flaky." Flattening these into one message (the dogfood F-R2-10 finding) makes the failure invisible to non-technical end users.
Related
- Validation tools — what to run before the production checklist
- Security — what Extentos collects vs what stays in the developer's app
- Tools overview — back to the full tool catalog
Simulation tools
The Extentos MCP server's simulation tools — createSimulatorSession (provision a browser-mode session at extentos.com/s with auto-bind to the running app; first call requires a free email-only account), ensureSimulatorBrowser (open + confirm a connected sim browser tab — the precondition for camera/inject flows), completeAuthLink (poll the device-code flow when account-linking is required), getEventLog (structured 6-chip event trace from a session), getSimulatorStatus (live session state). The browser-driven dev loop.
Search tools
The Extentos MCP server's search tool — searchDocs, which serves the bundled conceptual documentation corpus (getting_started, custom_handlers, voice_integration, library_api, toggles, simulator_browser_mode, event_log_schema, manifest_format, file_actions, permissions, connection_ui_placement, multi_platform_projects, and more). The narrative layer that complements the action-oriented tools.