Validation tools
The Extentos MCP server's validation tools — inspectIntegration (read-only project snapshot) and validateIntegration (whole-project correctness gate before testing). The pre-test sanity checks the agent runs after structural changes.
Two validation tools answer "is this integration structurally correct?" before the agent points the simulator or a real device at it. Both are pure-read, no side effects.
inspectIntegration
Read-only snapshot of the project's Extentos integration state — manifest, generated-file hashes, dependency status, connection-page config. Use when the agent needs to know what's wired before making decisions.
When to use: before manual edits to understand current state; as a "what's already installed?" probe.
When NOT to use: for correctness checking (use validateIntegration instead).
Parameters: projectPath (optional; defaults to cwd).
Response: { found, manifest, generatedFilesStatus, dependency, drift, connectionPageConfig, gaps, summary }. gaps[] lists obvious missing pieces (no manifest, missing dependency, etc.); drift.fileDrift[] flags generated files whose normalized hash doesn't match the recorded value. The drift check is cosmetic-tolerant: line-ending differences (CRLF vs LF), trailing whitespace, and block-comment edits (e.g., trimming the KDoc atop ExtentosBootstrap.kt for readability) do NOT trip drift. Structural changes — rename, body edits, added/removed declarations — still do. Pre-R2-F-R2-5 the drift hash was byte-strict and tripped on whitespace + Windows line endings; the validator now accepts both the normalized hash and the legacy byte-hash for backward compatibility with manifests written by older scaffolds.
validateIntegration
Whole-project correctness check — manifest exists + parses, generated bootstrap file is on disk with the right marker + matching hash, dependency declared, library version current, declared permissions cover the manifest's declared capabilities, bootstrap actually calls ExtentosGlasses.create(...) / Extentos.create(...), AGP + Gradle versions meet the library's floor (Android), foreground-service hint is present when continuous-capture capabilities are declared.
When to use: after structural changes — new capability declared, dependency bumped, manifest edited. Before testing.
When NOT to use: for reading current state (use inspectIntegration).
Parameters: projectPath (optional).
Response: { valid: boolean, checks: Check[], summary }. Each check carries name, passed, severity (error/warn/info), details, optional fix hint. The agent reads the fix field and acts on it directly.
The vendor-transport checks
Two checks fire only when the project declares camera or display — a voice-only app needs neither, and flagging one would push you onto the credentialed Meta path the vendorless baseline exists to spare you.
| Check | What it verifies |
|---|---|
glasses_meta_declared | com.extentos:glasses-meta is in the build files — a direct coordinate or a gradle/libs.versions.toml entry. com.extentos:glasses is vendorless, so camera and display have no transport without it. |
meta_dat_repo_declared | settings.gradle.kts declares the Meta DAT GitHub Packages repository the mwdat-* artifacts resolve from. |
Both are warnings, not errors, and they are independent: a project upgraded from 1.x already declares the repository, so meta_dat_repo_declared passes while the dependency is still missing.
A missing glasses-meta does not fail in the browser simulator. The simulator serves camera and display from the SDK itself and never touches the Meta SDK, so every capability works there. It fails on real glasses, where the session resolves to the vendorless system-audio baseline and captures return a typed refusal. This check, and the startup advisory the SDK logs in simulator mode, exist because the simulator alone cannot tell you.
Retired validation tool
Pre-pivot the MCP server also exposed validateSpec — a pure JSON check against the AppSpec JSON Schema (extentos://schema/v1). Retired with the pure-SDK pivot: there is no spec to validate. Structural correctness lives in validateIntegration (does the project compile and link against the SDK), and per-call shape lives in the SDK type system itself (Kotlin/Swift compiler will reject a wrong call at build time).
Related
- Setup and Generation tools — what the agent calls before validation
- Simulation tools — what the agent runs after validation passes
- Tools overview — back to the full tool catalog
Related
Tools reference
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.
Setup and Generation tools
The Extentos MCP server's Setup and Generation surface — generateConnectionModule (the one-shot project scaffold that emits the bootstrap module, build-script changes, dependencies, permissions, and the integration manifest) plus the four connection-page-config tools (getConnectionPageConfig, setConnectionPageConfig, regenerateConnectionPageFile, adoptConnectionPageFile). After scaffolding, the customer (or their agent) writes handler classes against the SDK primitives surfaced by getCapabilityGuide / getCodeExample.
Simulation tools
Extentos MCP simulation tools — provision and operate browser-mode simulator sessions, plus agent-driven testing tools that close the E2E loop with no human.
Implementation Guidance tools
The Extentos MCP server's guidance tools — getVoiceCommandGuidance (analyze proposed wake / command phrases for UX issues) and getPermissions (derive exact platform permissions, Meta DAT requirements, and foreground-service needs from the declared SDK capability list). Side-quest helpers the agent calls during composition.
Simulation tools
Extentos MCP simulation tools — provision and operate browser-mode simulator sessions, plus agent-driven testing tools that close the E2E loop with no human.