---
title: Production tools
description: 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.
type: reference
platform: mcp
related:
  - /docs/mcp-server/tools
  - /docs/mcp-server/tools/validation
  - /docs/resources/security
---

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), `handlers: string[]` (optional; the customer's handler class names — labels the API-keys step's affected handlers), `services: string[]` (optional; the BYOK provider names the app actually integrates, e.g. `["anthropic", "openai"]` — **this is what triggers the API Keys step**, not `handlers`), `platform: "android" | "ios"`, `projectPath` (optional).

**Response:** a personalized checklist spanning categories such as Meta Developer Account, DAT Registration, Credential Swap, API Keys (only when `services` are declared — a DAT-native or managed-gateway app declares none and skips it), 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), and 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[]` (**optional** — omit or pass `[]` for the Meta-DAT-only guide; otherwise 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"` (required).

**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` / `KeyMissing` / `KeyRejected` / `Connectivity` / `Transient` / `ClientBug` / `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](/docs/mcp-server/tools/validation)** — what to run before the production checklist
- **[Security](/docs/resources/security)** — what Extentos collects vs what stays in the developer's app
- **[Tools overview](/docs/mcp-server/tools)** — back to the full tool catalog