Tools reference

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:

The full, always-current tool list with input schemas is generated at /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:

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 →
• Setup and Generation →
• Implementation Guidance →
• Validation →
• Simulation →
• Production →
• 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.

Related