Skip to main content
Glama
gbatistuta0

AppFactory

by gbatistuta0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

TestFlight Ship

testflight_ship
Destructive

Build, sign, and upload an iOS app to TestFlight end-to-end, including distribution signing, archive, and App Store profiles. Needs Maestro smoke tests passed and human approval for upload.

Instructions

Build, sign and upload a TestFlight build end to end: distribution signing, archive, App Store profiles, manual-signing export, asc builds upload (needs human approval).

Use when: shipping a build to TestFlight. Refuses unless the Maestro smoke flows passed (maestro_test) and App ID capabilities exist. Never submits for App Store review (use asc_submit_for_review for that). Not for: single build steps (build_archive, build_export_ipa, signing_*). Returns: {ok, build, ...} or an error / approval_required refusal.

Input Schema

NameRequiredDescriptionDefault
schemeYesXcode scheme name to build, e.g. 'MyApp'.
app_dirYesAbsolute path to the app project directory (contains app.spec.json), e.g. /Users/me/Apps/MyApp.
projectYesPath to the .xcodeproj or .xcworkspace to build, e.g. /path/App/App.xcodeproj.
bundle_idYesApp bundle identifier in reverse-DNS form, e.g. com.example.app.
approval_idNoApproval id from a previous approval_required refusal; omit on the first call. The human approves out-of-band with `appfactory approve <id>`, then call again with the same arguments and this id.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.5
    • addedInput schema / properties / app_dir / description
      Added value: +"Absolute path to the app project directory (contains app.spec.json), e.g. /Users/me/Apps/MyApp."
    • addedInput schema / properties / approval_id / description
      Added value: +"Approval id from a previous approval_required refusal; omit on the first call. The human approves out-of-band with `appfactory approve <id>`, then call again with the same arguments and this id."
    • addedInput schema / properties / bundle_id / description
      Added value: +"App bundle identifier in reverse-DNS form, e.g. com.example.app."
    • addedInput schema / properties / project / description
      Added value: +"Path to the .xcodeproj or .xcworkspace to build, e.g. /path/App/App.xcodeproj."
    • addedInput schema / properties / scheme / description
      Added value: +"Xcode scheme name to build, e.g. 'MyApp'."
  2. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructive/openWorld/non-idempotent, but the description adds genuinely non-derivable behavior: the tool refuses unless smoke tests passed, requires out-of-band human approval via approval_id, and can return an approval_required refusal rather than executing. Those gating semantics are the crux of calling this tool correctly.

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

Conciseness5/5

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

Three labeled blocks (purpose, 'Use when', 'Not for', 'Returns') that are front-loaded and free of filler. The telegraphic style costs nothing in clarity and every clause carries a routing or precondition fact.

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?

For a high-stakes orchestration tool, the description covers prerequisites, approval workflow, refusal modes, and sibling routing, while the output schema handles return-value structure (the brief '{ok, build, ...}' note is a bonus, not a crutch). No gap remains that would cause a mis-invocation.

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

Parameters3/5

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

Schema description coverage is 100% and the approval_id parameter is thoroughly documented in the schema itself, including the two-call approval dance. The description adds no additional parameter-level syntax or constraints, so the baseline 3 applies.

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?

States specific verbs and resource chain: 'Build, sign and upload a TestFlight build end to end,' then enumerates the steps (distribution signing, archive, App Store profiles, export, asc upload). It explicitly names what it is not (build_archive, build_export_ipa, signing_*), so an agent can separate it from the sibling build steps without reading schemas.

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?

Provides a 'Use when' trigger, hard preconditions (Maestro smoke flows passed via maestro_test, App ID capabilities exist), an explicit routing rule ('Never submits for App Store review – use asc_submit_for_review'), and a 'Not for' exclusion list. This is a textbook when/when-not/alternative section.

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

Deploy Server

Other Tools