Skip to main content
Glama
Sign In
Swipium

Swipium

by GeroPalombo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run a flow (or preview its execution plan)

qa_flow_run

Runs saved or inline YAML QA flows on a prepared mobile app, previews per-backend support in plan mode, and returns step-level failure diagnostics with screenshots and health.

Instructions

Run a YAML flow (saved, or inline flowYaml to batch known steps) on the prepared app; mode:"plan" previews per-backend support without a device. Server-side, fail-fast, with setup/teardown; mutating and OCR steps are consent-gated; a failure returns the step, screenshot, failureCode, and health. Pass flow (name/path) or flowYaml, plus variables. Steps: docs/flows.md#step-reference.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "qa_flow_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
flowNoFlow name under .swipium/flows, or a .yaml path.
modeNo
appiumNoplan: Appium session hints.
repeatNorun: repeat N times to classify flakes.
approveNo
backendNoplan: only this backend (default all five).
flowYamlNoInline flow YAML.
consentIdNorun: consent for mutating / OCR steps.
sessionIdNoRequired for run.
variablesNorun: ${VAR} values (over session inputs and SWIPIUM_* env); secret-like names are redacted.
projectRootNoplan: absolute app root for flow names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: server-side execution, fail-fast semantics, setup/teardown wrapping, consent gating for mutating and OCR steps, and a concrete failure payload (step, screenshot, failureCode, health). This tells the agent what will happen and what comes back on error, which the annotation flags alone do not convey.

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?

One dense paragraph, front-loaded with the primary action and the plan/run split before the behavioral notes. It is efficient but compressed to the edge of terseness (e.g. 'mode:"plan" previews'), requiring careful reading rather than skimmable structure.

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

Completeness4/5

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

For an 11-parameter, no-output-schema, mutating execution tool, the description covers the critical unknowns: execution model, consent requirement, failure return shape, and the file/docs reference for step syntax. Missing pieces are modest — prerequisites for run (sessionId is only visible in the schema) and the role of `approve`/`repeat` are not described.

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 82%, so baseline is 3; the description adds meaning on top by stating the flow vs flowYaml choice as alternative inputs and calling out variables and consent. It leaves `approve`, `repeat`, and `projectRoot` unaddressed in prose, but the schema descriptions cover most of those, so the gap is minor.

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

Purpose4/5

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

States a specific verb and resource ('Run a YAML flow ... on the prepared app') and explicitly splits the two modes, with 'plan' previewing per-backend support without a device. An agent can tell what the tool does, though it never names a sibling (e.g. qa_flow_check or qa_flow_compile) to contrast against, so differentiation is inferred rather than stated.

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

Usage Guidelines4/5

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

Gives clear operating context: it runs against the 'prepared app', accepts either a saved `flow` or inline `flowYaml`, and `mode:"plan"` is the no-device preview path. It omits explicit when-not-to-use conditions and any direct alternative (e.g. use the compile/check tool first), so it stops short of full routing guidance.

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