Skip to main content
Glama
extentos

extentos

getProductionChecklist

Receive a personalized production-readiness checklist with conditional steps for smart-glasses apps, based on declared capabilities, handlers, and BYOK services. Use it before launch.

Instructions

Return a personalized production-readiness checklist based on the SDK capabilities the app uses, the handlers it declares, and the BYOK services it integrates. Returns { ready, steps, summary }: ready is true when no step has status 'needed'; each steps[] entry is { category, description, status: 'done' | 'needed' | 'optional', details, fix?, requiredScopes?, affectedHandlers?, codeChange?: { file, hint } }. Steps are conditional — streams add a foreground-service step, voice/camera/audio add a real-hardware-verification step, and declared BYOK services (or the Phase 3 conversation runtime) add an API-keys step. Pass projectPath so the Meta-account and credential-swap steps read the project's real build state and report 'done' instead of 'needed'. Cross-links: getPermissions for the exact permission set the Permissions-Audit step verifies, getCredentialGuide for the per-provider key setup the API-Keys step needs, validateIntegration for the structural pre-test gate. USE when going to production. DON'T USE during development.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handlersNoNames of the handlers the app declares (labels the API Keys step's affectedHandlers). Does NOT by itself trigger the API Keys step — declare `services` for that.
platformYes
servicesNoBYOK provider names the app actually integrates (e.g. ["anthropic", "openai"]). The trigger for the API Keys step — a DAT-native app (capture_photo + speak) or a Phase 4 managed-gateway app declares none and skips it.
projectPathNoAbsolute (or cwd-relative) path to the project root. Optional — when given, the Meta-Developer-Account and Credential-Swap steps read the real build state (Android extentos_meta_credentials.xml / iOS Info.plist MWDAT dict) to mark themselves 'done' vs 'needed'. Omit → every step is assumed not-yet-done.
capabilitiesYesCapability names from getPlatformInfo.features[].name. Drives the streams / hardware-verify / permissions-audit steps.
Behavior5/5

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

No annotations provided, so description fully discloses conditional behavior (streams, voice/camera/audio, BYOK services) and how projectPath affects step status. No contradiction.

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?

Relatively long but each sentence adds necessary detail. Front-loaded with purpose and return structure. Could be slightly more concise but appropriate for complexity.

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?

Complete coverage of all aspects: parameter behavior, conditional steps, cross-references, usage context. No output schema but return format is explained in detail.

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 80% (high), but description adds valuable context beyond schema: e.g., handlers do not trigger API Keys step, services do; projectPath enables real build state reading. Validates baseline 3 and adds extra value.

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?

Description clearly states it returns a personalized production-readiness checklist based on capabilities, handlers, and BYOK services. It specifies output structure { ready, steps, summary } and cross-links to sibling tools, distinguishing its role.

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 when going to production. DON'T USE during development.' Cross-references getPermissions, getCredentialGuide, and validateIntegration as alternatives for specific needs.

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