Check mobile app release readiness

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's 'read-only' statement is consistent. It adds useful behavioral context beyond the annotations: the specific checks performed and the EXPO_TOKEN prerequisite, though it does not disclose failure modes or what happens when prerequisites are missing.

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

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

The description is two tight sentences: the first front-loads the read-only preflight purpose and target platforms, and the second lists the checks and the required prerequisite. No filler or redundant restatement of the tool name.

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

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

For a read-only readiness tool with a rich output schema and clear annotations, the description covers the essential context: what is checked, which platforms are supported, and what must be configured first. It could be slightly more complete by explicitly saying to run this before start_mobile_release and that success means the release can proceed.

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

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

Schema description coverage is 0%, so the description carries some parameter burden. It indirectly explains target by naming 'internal TestFlight or Google Play internal testing,' which maps to the enum values, but it never mentions target or projectPath by name. projectPath is only covered by its schema default, leaving part of the parameter semantics implicit.

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

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

The description states a specific verb and resource: a 'read-only Expo/EAS preflight' that 'checks app identity, production build profile, generated workflow, internal-only Android track, EAS project link, and EXPO_TOKEN.' It clearly distinguishes itself from siblings by emphasizing read-only readiness checks rather than starting or monitoring a release.

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

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

The description makes the context clear: use as a preflight before internal TestFlight or Google Play internal testing, and it gives an explicit prerequisite: 'Run craveup apps configure first.' It does not explicitly contrast with siblings like start_mobile_release or get_mobile_release_status, but the intended placement is implied well.

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