Skip to main content
Glama
gbatistuta0

AppFactory

by gbatistuta0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Pipeline Next

pipeline_next
Read-onlyIdempotent

Returns the next mandatory pipeline step and its instructions for manually driving an app build, requiring run options confirmation unless skipped.

Instructions

Return the next mandatory pipeline step with its instructions.

Use when: driving the pipeline manually. Refuses until run options are confirmed (run_options, run_options_save) unless skip_options_check. Not for: the autonomous loop with retry budgets (use orchestrator_next_action). Returns: {ok, stage, instructions} or setup_required / options-not-confirmed errors.

Input Schema

NameRequiredDescriptionDefault
app_dirYesAbsolute path to the app project directory (contains app.spec.json), e.g. /Users/me/Apps/MyApp.
skip_options_checkNoIf true, do not require run_options_save to have been called first. Default false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 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 / skip_options_check / description
      Added value: +"If true, do not require run_options_save to have been called first. Default false."
  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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it refuses until run options are confirmed and returns specific error modes (setup_required / options-not-confirmed). However, the core precondition is also implied by the schema's skip_options_check description, so this is strong but not maximally additive.

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?

The description is front-loaded with purpose, then scannable 'Use when', 'Not for', and 'Returns' sections. Every sentence carries actionable information, and there is no filler.

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?

The tool's purpose, gating condition, alternative, and error modes are all covered, and an output schema exists so return-value details need not be exhaustively restated. Nothing an agent needs in order to call 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 both parameters are already fully documented in the input schema. The description only mentions skip_options_check in passing and adds no syntax, format, or usage detail beyond what the schema provides; baseline 3 is appropriate.

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: 'Return the next mandatory pipeline step with its instructions.' It also explicitly differentiates from the closest sibling by naming the alternative for the autonomous loop (orchestrator_next_action), so an agent can distinguish it without opening another 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?

Provides direct when-to-use guidance ('driving the pipeline manually'), explicit exclusions ('Not for: the autonomous loop with retry budgets'), and the exact replacement tool. It also states the gating precondition and the escape hatch, leaving no ambiguity about when this tool is appropriate.

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