MCP serverTools

Tools reference

The Extentos MCP server exposes 18 deterministic tools across 7 categories — discovery, generation, guidance, validation, simulation, production, and documentation. 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 18 deterministic tools 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:

CategoryToolsWhat they're for
Discovery and PlanninggetPlatformInfo, getExampleSpecFirst calls in any new task — read the catalog, study reference specs
Setup and GenerationgenerateConnectionModule, initSpec, generateConsumer, updateSpecScaffold the project and mutate the AppSpec
Implementation GuidancegetVoiceCommandGuidance, getPermissionsSide-quest helpers during composition
ValidationvalidateSpec, inspectIntegration, validateIntegrationCorrectness gates — run after every mutation
SimulationcreateSimulatorSession, completeAuthLink, getEventLog, getSimulatorStatusProvision and operate browser-mode simulator sessions
ProductiongetProductionChecklist, getCredentialGuidePre-ship checks
SearchsearchDocsSearch the Extentos documentation by topic

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.
  • Freshness tokens guard concurrent edits. Tools that mutate the spec (updateSpec, generateConsumer) require a basedOn: { hash, timestamp } token from inspectIntegration. Stale tokens fail fast — no silent overwrites of concurrent agent edits.
  • Tool calls do not count against the simulator-event meter. The 1000-event meter only counts BrowserSimTransport runtime events during a simulator session. MCP-server-side activity is always free.

The canonical agent-driven flow

For a fresh project, the typical tool sequence is:

getPlatformInfo → searchDocs → generateConnectionModule → initSpec
  → generateConsumer → validateIntegration → createSimulatorSession
  → (developer interacts) → getEventLog

For iteration: inspectIntegration (for the basedOn token) → updateSpecgenerateConsumer (if handlers/streams added) → validateIntegration.

Before shipping: getProductionChecklistgetCredentialGuide.

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.