---
title: Tools reference
description: The Extentos MCP server exposes a tight set of deterministic tools across deterministic categories — discovery + SDK reference, generation, guidance, validation, simulation, production, agent configuration, and search. Per-tool reference covering input parameters, response shapes, when to call each tool, and worked examples. Verified from the actual tool definitions and handler implementations in @extentos/mcp-server.
type: reference
platform: mcp
related:
  - /docs/mcp-server
  - /docs/mcp-server/tools/discovery
  - /docs/mcp-server/tools/generation
  - /docs/mcp-server/tools/guidance
  - /docs/mcp-server/tools/validation
  - /docs/mcp-server/tools/simulation
  - /docs/mcp-server/tools/production
  - /docs/mcp-server/tools/search
---

The MCP server exposes a deterministic tool surface an AI agent calls to operate Extentos. Each tool is a typed primitive — clear input schema, predictable response shape, no hidden state. The agent composes them itself; there's no planning tool.

Tools are organized by purpose:

| Category | Tools | What they're for |
|---|---|---|
| **[Discovery and SDK reference](/docs/mcp-server/tools/discovery)** | `getPlatformInfo`, `getCapabilityGuide`, `getCodeExample`, `getMigrationGuide` | First calls in any new task — read the capability catalog, look up per-feature call shape, peel from canonical patterns, map raw Meta DAT symbols to Extentos primitives |
| **[Setup and Generation](/docs/mcp-server/tools/generation)** | `generateConnectionModule`, `getConnectionPageConfig`, `setConnectionPageConfig`, `regenerateConnectionPageFile`, `adoptConnectionPageFile` | Scaffold the project + manage the managed connection-page config. After scaffolding, the agent writes handler classes against the SDK primitives. |
| **[Agent configuration & usage](/docs/reference/mcp-tools)** | `getAssistantConfig`, `setAssistantConfig`, `listProjectSounds`, `addProjectSound`, `getGatewayUsage` | Read or change a project's dashboard-managed assistant settings (model/voice/memory), manage its named-sound library, and read managed-gateway usage & cost. Gated per-project by the MCP access grant (default Read+Write). |
| **[Credentials](/docs/reference/mcp-tools)** | `getCredentialStatus`, `setCredential` | Check whether a project's API keys are set (masked hint only) + start write-without-knowing entry — a dashboard handoff where the owner pastes the secret, which never passes through the agent. Gated per-project by the MCP access grant. |
| **[Analytics](/docs/reference/mcp-tools)** | `getProjectAnalytics` | Read a project's production analytics — aggregate shipped-app telemetry (events, active installs, by event/day/vendor/platform). Metadata only; ownership-checked; gated per-project by the MCP access grant. |
| **[Implementation Guidance](/docs/mcp-server/tools/guidance)** | `getVoiceCommandGuidance`, `getPermissions` | Side-quest helpers during composition |
| **[Validation](/docs/mcp-server/tools/validation)** | `inspectIntegration`, `validateIntegration` | Correctness gates — run after structural changes |
| **[Simulation](/docs/mcp-server/tools/simulation)** | `createSimulatorSession`, `ensureSimulatorBrowser`, `completeAuthLink`, `getEventLog`, `getSimulatorStatus`, `injectTranscript`, `injectAssistantUtterance`, `assertToolCalled`, `injectHardwareButton`, `setSimVideo`, `setSimDevice`, `getDisplayState`, `injectInput` | Provision and operate browser-mode simulator sessions, plus the agent-driven testing tools that close the end-to-end loop without a human — including `injectHardwareButton` (tap pauses/resumes a live camera stream, hold stops it, so `CaptureError.StreamPaused` is testable) |
| **[Production](/docs/mcp-server/tools/production)** | `getProductionChecklist`, `getCredentialGuide` | Pre-ship checks |
| **[Search](/docs/mcp-server/tools/search)** | `searchDocs` | Search the Extentos conceptual documentation |

The full, always-current tool list with input schemas is generated at [/docs/reference/mcp-tools](/docs/reference/mcp-tools).

Five **Agent-configuration** tools manage a project's voice agent over MCP: `getAssistantConfig` reads the dashboard-managed assistant settings (Realtime model, voice, memory model + mode), `setAssistantConfig` changes them, `listProjectSounds` / `addProjectSound` manage the project's named-sound library (MP3/M4A/AAC/WAV under 1 MB; app code plays them with `glasses.audio.playSound(name)` — iOS today, Android landing; gated by the `assistant_config.sounds` grant), and `getGatewayUsage` reads managed-gateway usage + exact cost. All are account-scoped (they require a linked account). Writes are **Read+Write by default** so they work out of the box; the project owner can restrict any capability per-project in the dashboard's MCP access controls, and `setAssistantConfig` echoes the cost impact of a model change.

Two **Credentials** tools manage a project's API keys without the agent ever seeing a secret: `getCredentialStatus` reports whether the Meta DAT identity is set — a masked hint only, never the value — and `setCredential` starts **write-without-knowing** entry: it returns a link to the project's dashboard credentials page where the signed-in owner pastes the secret, which goes straight into the encrypted vault. The agent can't read a stored secret back. Both are account-scoped and gated by the per-project Credentials grant.

One **Analytics** tool, `getProjectAnalytics`, reads a project's **production** telemetry — aggregate metrics (events, active installs, by event/day/vendor/platform) from the app's shipped (App Store / Play Store) installs, metadata only. It reads the prod-attested warehouse (the same data the dashboard Analytics page shows), so it stays empty until the app ships and sends prod-attested events; for the live dev/sim event stream use `getEventLog` instead. It's account-scoped, **ownership-checked** (you can only read your own projects), and gated by the per-project Analytics grant.

## Conventions

A few conventions hold across every tool:

- **All tool inputs and outputs are JSON.** Tools that take an object pass it via the MCP `arguments` field; the schemas live in `mcp-server/src/tools/definitions.ts`.
- **`additionalProperties: false`.** Unknown parameters fail validation with `code: "invalid_arguments"` and a `fixHint` telling the agent what to drop.
- **Successful responses include a `summary` string** — a short human-readable description of what the tool returned. Agents can surface this directly to the developer.
- **Errors return a structured shape** — `{ code, message, fixHint?, retryable? }` — instead of throwing. The agent can decide whether to retry or surface the error.
- **Most tool calls require no account.** Discovery, guidance, validation, the simulator-driving tools, and search all work anonymously — no signup, no key, no payment. Three groups need a linked (free) account: minting browser-simulator sessions (`createSimulatorSession`), the `generateConnectionModule` scaffold step (HTTP 402 — it mints the account-bound project key; the informational first call is anonymous), and the account-scoped project tools — assistant config (`getAssistantConfig` / `setAssistantConfig` / `getGatewayUsage`), credentials (`getCredentialStatus` / `setCredential`), connection-page config writes (`setConnectionPageConfig` / `adoptConnectionPageFile`), and analytics (`getProjectAnalytics`). Those return error code `account_required` until you link — the account-scoped project tools on HTTP 401, and `createSimulatorSession` on HTTP 402 with a structured `auth_required` body that kicks off the device-code login.

## The canonical agent-driven flow

For a fresh project, the typical tool sequence is:

```text
getPlatformInfo → getCodeExample(pattern) → getCapabilityGuide(feature)
  → generateConnectionModule
  → <agent writes handler classes against the SDK>
  → validateIntegration → createSimulatorSession
  → <developer interacts> → getEventLog
```

For iteration: edit handler code → rebuild + reinstall → the app auto-reattaches to the same simulator session. No mutation tools needed for handler iteration; the simulator URL is stable.

Before shipping: `getProductionChecklist` → `getCredentialGuide`.

## Retired tools

Pre-pivot the MCP server also exposed `initSpec`, `updateSpec`, `validateSpec`, `getExampleSpec`, and `generateConsumer`. All five are retired with the pure-SDK pivot — the library no longer interprets a spec, so DSL authoring, patching, callback-dispatch generation, and detached spec validation are all dead surface. Handler code is now hand-authored against the SDK directly; see `getCodeExample` for canonical patterns and `getCapabilityGuide` for per-feature call shape.

## Per-category reference

The deep reference per tool lives on the category pages:

- **[Discovery and SDK reference →](/docs/mcp-server/tools/discovery)**
- **[Setup and Generation →](/docs/mcp-server/tools/generation)**
- **[Implementation Guidance →](/docs/mcp-server/tools/guidance)**
- **[Validation →](/docs/mcp-server/tools/validation)**
- **[Simulation →](/docs/mcp-server/tools/simulation)**
- **[Production →](/docs/mcp-server/tools/production)**
- **[Search →](/docs/mcp-server/tools/search)**

## Source of truth

Every claim on these pages is verified from `mcp-server/src/tools/definitions.ts` (input JSON Schemas) and the per-tool handler implementations under `mcp-server/src/tools/handlers/`. If a doc claim conflicts with the source, the source wins — file an issue and we'll reconcile.