Skip to main content
Glama
gbatistuta0

AppFactory

by gbatistuta0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Maestro Test

maestro_test

Run Maestro flows on a booted simulator to verify your app end to end, generating a JSON report required for TestFlight shipping and feature gates.

Instructions

Run the app's Maestro flows (.maestro/) on the booted simulator with the live Viewer, and write .appfactory/verify/maestro.json.

Use when: verifying the app end to end; testflight_ship and the features gate require every smoke flow green. The app must already be installed (build_for_sim + simctl install). Opens the Viewer at http://localhost:7777; there is no headless mode. Returns: {ok, flows: [{name, passed}], report path}.

Input Schema

NameRequiredDescriptionDefault
tagsNoComma-separated Maestro tag filter, e.g. 'smoke'; omit to run every flow.
deviceNoSimulator UDID to run on; omit for the booted simulator.
app_dirYesAbsolute path to the app project directory (contains app.spec.json), e.g. /Users/me/Apps/MyApp.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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 / device / description
      Added value: +"Simulator UDID to run on; omit for the booted simulator."
    • addedInput schema / properties / tags / description
      Added value: +"Comma-separated Maestro tag filter, e.g. 'smoke'; omit to run every flow."
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover mutation safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description goes beyond them with a genuinely useful trait: it opens an interactive Viewer at http://localhost:7777 and has no headless mode, plus it writes a report file. It omits expected runtime/duration and what happens on partial flow failure, so not quite a 5.

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 dense, front-loaded segments (action, when, returns) with zero filler. Every sentence carries actionable information for an agent deciding whether and how to call the tool.

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 test-runner tool it covers purpose, prerequisites, side-effect artifacts and the non-headless Viewer behavior; the output schema carries the return shape, and the description's brief 'Returns' restatement is harmless. Nothing an agent needs to invoke it correctly is missing.

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%, so tags, device and app_dir are already documented in the schema, including the tag-filter example and the 'omit for booted simulator' default. The description adds no parameter-level detail beyond what the schema provides, 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 a specific verb and resource ('Run the app's Maestro flows (.maestro/) on the booted simulator'), names the artifact produced ('.appfactory/verify/maestro.json'), and the live Viewer variant. An agent can distinguish this from build_test or build_for_sim without opening the schema.

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?

Explicit 'Use when: verifying the app end to end' plus a dependency statement that testflight_ship and the features gate require every smoke flow green. It also states the prerequisite chain (app must be installed via build_for_sim + simctl install), leaving nothing to inference.

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