Skip to main content
Glama
Sign In
Swipium

Swipium

by GeroPalombo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Start a QA session

qa_start_session

Open a QA session to run snapshots, actions, and flows against a mobile app on emulators or simulators, with configurable time, action, and screenshot budgets plus fixture preconditions.

Instructions

Open a QA session for the low-level tools (qa_snapshot, qa_act, flows); qa_test_this opens its own. projectRoot defaults to MCP roots > SWIPIUM_PROJECT_ROOT > CLAUDE_PROJECT_DIR > a project-like cwd. Default budget: 30 min / 60 actions / 40 screenshots. fixtures declare preconditions; unmet ones report blocked, not failed.

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_start_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
budgetNoOverride default budget caps.
profileNoBudget class.
fixturesNoPreconditions, merged with .swipium/fixtures.json: {name, requiredState?, ...} (docs/tools.md#qa_start_session).
sensitiveNoRefuse all screenshots, recordings, and on-screen evidence.
projectRootNoAbsolute app path.
responseModeNoOutput detail: compact (summary + URIs), normal (default, + JSON), verbose (all JSON, element objects).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, closed-world, non-idempotent operation, so the description's job is to add context — which it does: default budget caps (30 min / 60 actions / 40 screenshots), the projectRoot resolution precedence chain, and the semantic that unmet fixtures report 'blocked' rather than 'failed'. What it omits is session lifecycle behavior (does opening twice fail? when does it expire?), which is exactly the kind of trait an agent needs for a stateful opener.

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?

Front-loads the core action and the sibling distinction, then packs defaults, path resolution, and fixture semantics into a few dense clauses with no filler. It is telegraphic to the point of terseness in places (semicolon-chained sentences), which slightly raises parsing cost, but nothing is wasted.

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 a stateful session opener with no output schema, it covers budgets, project resolution, fixture preconditions, and a privacy switch, which is most of what an agent needs before calling. The remaining gap is lifecycle: what the call returns (session handle/URI) and how or when the session ends is never stated.

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 description coverage is 100%, so the baseline is 3; the description earns above that by explaining behavior the schema cannot: projectRoot fallback order (MCP roots > SWIPIUM_PROJECT_ROOT > CLAUDE_PROJECT_DIR > project-like cwd), the concrete default budget values behind the nested budget object, and the blocked-vs-failed meaning of fixtures plus the merge with .swipium/fixtures.json. It leaves profile enum meanings ('guardrail', 'full_smoke') and responseMode tradeoffs undocumented beyond the schema.

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 ('Open a QA session') and scopes it explicitly to the low-level tools qa_snapshot, qa_act and flows, while naming qa_test_this as the sibling that does NOT need it. An agent can route between the two session entry points without opening either schema.

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 when-to-use guidance by pairing the tool with the siblings that consume the session and excluding qa_test_this. It stops short of stating prerequisites or failure modes (e.g. what happens if a session already exists), so it is clear context rather than a full decision rule.

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