---
title: Validation tools
description: 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.
type: reference
platform: mcp
related:
  - /docs/mcp-server/tools
  - /docs/mcp-server/tools/generation
  - /docs/mcp-server/tools/simulation
---

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.

<Callout type="warn">
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.
</Callout>

---

## 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](/docs/mcp-server/tools/generation)** — what the agent calls *before* validation
- **[Simulation tools](/docs/mcp-server/tools/simulation)** — what the agent runs *after* validation passes
- **[Tools overview](/docs/mcp-server/tools)** — back to the full tool catalog