Skip to main content
Glama
extentos

extentos

validateIntegration

Validate integration readiness before testing: checks manifest, dependencies, permissions, and toolchain, returning a graded report with errors/warnings to prevent failed test runs.

Instructions

Pre-test gate that runs ~15 severity-tiered checks over the whole project — manifest present + parses, generated-file markers + hashes, dependency declared, library-version freshness, Android Meta-DAT repo declaration, bootstrap wiring (ExtentosGlasses.create / Extentos.create), connection-page config, toolchain (AGP/Gradle) floors, foreground-service hints, and permissions. The permissions check DERIVES the permissions your declared capabilities imply and verifies they're present in the REAL app/src/main/AndroidManifest.xml elements (Android) or the app target's Info.plist keys (iOS) — the runtime source of truth, not the manifest JSON's permissions array. Returns { valid, checks, summary }: each checks[] entry is { name, passed, severity?: 'error' | 'warn' | 'info', details?, fix? }. valid is true when zero ERROR-severity checks fail; warn/info are advisories that don't block. summary reads 'Safe to test' ONLY at zero warnings — any warning demotes it to 'review before testing'. So treat this as a graded readiness report, not a binary pass/fail. USE after making changes, before testing. DON'T USE for reading state without judging it (use inspectIntegration).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectPathNoAbsolute (or cwd-relative) path to the project root. Optional — defaults to the MCP server's current working directory (process.cwd()); pass it explicitly whenever the project isn't the cwd.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: runs checks, returns structured output with severity tiers, explains 'valid' flag logic and summary demotion, and notes permissions check derivation from runtime source. No hidden traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: starts with purpose, lists checks, explains output format, and provides usage guidance. Every sentence adds information, though slight trimming could improve conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully details the return structure (checks array with fields, valid flag, summary with demotion logic). No aspect of tool behavior or result is unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional parameter. The description adds value by explaining the default behavior (cwd) and when to pass explicitly, beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a 'pre-test gate' that runs ~15 severity-tiered checks over the project, listing specific check categories. It distinguishes from sibling tool 'inspectIntegration' which is for reading state without judging.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'USE after making changes, before testing. DON'T USE for reading state without judging it (use inspectIntegration)'. Provides clear context for when to use and when not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/extentos/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server