Validation tools

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.

---

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