Tools reference

The Extentos MCP server exposes a tight set of deterministic tools across 7 categories — discovery + SDK reference, generation, guidance, validation, simulation, production, 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.

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	`getPlatformInfo`, `getCapabilityGuide`, `getCodeExample`	First calls in any new task — read the capability catalog, look up per-feature call shape, peel from canonical patterns
Setup and Generation	`generateConnectionModule`	Scaffold the project. After scaffolding, the agent writes handler classes against the SDK primitives.
Implementation Guidance	`getVoiceCommandGuidance`, `getPermissions`	Side-quest helpers during composition
Validation	`inspectIntegration`, `validateIntegration`	Correctness gates — run after structural changes
Simulation	`createSimulatorSession`, `completeAuthLink`, `getEventLog`, `getSimulatorStatus`	Provision and operate browser-mode simulator sessions
Production	`getProductionChecklist`, `getCredentialGuide`	Pre-ship checks
Search	`searchDocs`	Search the Extentos conceptual documentation

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.
Tool calls require no account. Every tool works anonymously, with no signup, no key, no payment. The only gate that requires sign-in is createSimulatorSession (free email-only account, no payment) — every other tool is fully anonymous and unlimited.

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:

Source of truth

Every claim on these pages is verified from mcp-server/src/tools/definitions.ts (input JSON Schemas), mcp-server/src/tools/registry.ts (handler wiring), 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.