Swipium

Overview Schema Source Related Servers Discussions Admin

Guided exploration

qa_explore

Automatically explores a prepared mobile app as a background job, taps ranked safe actions, builds a screen graph, and records taps for test generation while skipping destructive actions.

Instructions

Explore the prepared app automatically as a job (poll qa_job_status): taps ranked safe actions, checks health, builds a screen graph, updates the app map, and records taps for qa_generate. Destructive actions (delete/pay/send/logout) are skipped unless one candidate is approved; an auth wall without credentials returns needs_input.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>"
    },
    "name": "qa_explore"
  }
}

Input Schema

Name	Required	Description
`goal`	No	Focus, e.g. "exercise the main tabs".
`depth`	No	Default 3. Not a depth limit: 1 turns off going back from a dead-end screen.
`approve`	No
`safeMode`	No	strict (default) \| balanced \| dry_run_destructive (list candidates, no taps) \| approved_destructive_candidate (one candidate, consent-gated). approved_destructive is refused.
`strategy`	No	crawl (default) \| task_planner (infer QA tasks first) \| hybrid.
`consentId`	No
`sessionId`	Yes
`maxActions`	No	Default 20.
`maxScreens`	No	Default 12.
`stopOnAuth`	No	needs_input at an auth wall without credentials (default true).
`accountCycle`	No	Allow logout on a disposable generated account (needs allowGeneratedData).
`generateSuite`	No	Also write + compile a POM suite from promoted paths.
`maxDurationMs`	No	Default 360000.
`includeTextEntry`	No	Type into fields that have a value source (default false).
`confirmHighImpact`	No	Required for payment/send/permission/delete candidates.
`allowGeneratedData`	No	Allow generated test data (test/staging).
`destructiveCandidate`	No	approved_destructive_candidate: the candidate from a dry_run_destructive run.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only say it is not read-only, not idempotent, and not destructive; the description goes further by disclosing the safety gating (delete/pay/send/logout skipped absent approval), the needs_input outcome at an auth wall without credentials, and the artifacts it writes (screen graph, app map, tap recordings). It does not discuss duration limits, failure/retry behavior, or what the job handle looks like, which keeps it off 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.

Conciseness4/5

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

Two sentences, front-loaded with the action and its outputs, then the safety/failure rules. Dense but every clause carries information; the second sentence is a long compound that could be split for easier scanning, but nothing is filler.

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 17-parameter, nested-object, no-output-schema tool, the description covers the job model, polling contract, safety gates, and terminal failure mode. Missing detail on return payload shape and on how goal/strategy/depth shape exploration is acceptable given polling is delegated to qa_job_status.

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 already 82%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: destructiveCandidate only makes sense after a dry_run_destructive run, and approval plus consent are what unlock a single destructive tap. It still leaves the interplay of depth, strategy, and goal to the schema alone.

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 ('explore the prepared app automatically as a job') plus the concrete outputs it produces: taps ranked safe actions, health checks, screen graph, app map update, and recorded taps for qa_generate. It also names the required follow-up sibling (qa_job_status), so an agent can distinguish this long-running exploration from single-step tools like qa_act.

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?

Clearly frames this as an asynchronous job that must be polled via qa_job_status, and gives the governing condition for the risky path: destructive actions are skipped unless one candidate is approved. It doesn't explicitly say when to prefer qa_act or qa_flow_run instead of a full exploration, so routing versus alternatives is only implied.

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