Loading ToolBench
Swipium MCP server for simulator-based mobile QA workflows, evidence capture, app maps, and generated test suites.
Swipium has 42 tools with significant definition gaps. Most tools have minimal descriptions (10-50 chars, well below the 194-char baseline). Input schemas are present but sparse: many tools accept only sessionId with no additional parameters documented. Parameter descriptions are largely absent or trivial. No output schemas are documented. Error handling is not visible in tool definitions. The server conflates multiple concerns in single tools (e.g., qa_bundletool handles conversion, caching, device-specific builds, and installation). Tool names use qa_ prefix but lack clear verb-noun structure (qa_act, qa_flow, qa_generate are vague). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. This is a domain-specific QA automation server with ambitious scope but poor definition quality for LLM consumption.
Perform an action on the target device
Control app installation and lifecycle
Query and manage app knowledge map
Assert visual properties of UI elements
Build the mobile app
Convert an Android App Bundle (.aab) into an installable APK set using bundletool, cached under .swipium/artifacts/. An .aab is NOT directly installable — this is the conversion step before qa_prepare_target. Default mode builds a UNIVERSAL .apk (works on any device). Pass connectedDevice:true to build a DEVICE-SPECIFIC APK set (--connected-device) and install:true to push it via bundletool install-apks. Uses the debug keystore by default (emulator/dev OK). Returns typed blockers (BUNDLETOOL_MISSING/AAB_NEEDS_BUNDLETOOL, AAB_BUILD_APKS_FAILED, AAB_DEVICE_SPEC_FAILED, AAB_INSTALL_FAILED, ANDROID_SIGNING_FAILED). Runs as a job; poll qa_job_status.
List available capabilities and tools
Vague tool names lack clear verb-noun structure. 'qa_act', 'qa_flow', 'qa_generate', 'qa_wait' do not convey what action occurs. LLMs cannot infer intent from names alone.
Most tool descriptions are under 30 characters (e.g., 'Diagnostic tool for Swipium setup and environment', 'List available capabilities and tools'). Baseline is 194 chars. Descriptions lack WHEN to use, WHAT it returns, and prerequisites.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. Responses are opaque.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
Check health of the target device/app
Clear overlay elements from screen
Detect project context and environment
Control device settings and state
Diagnostic tool for Swipium setup and environment
Explore the app UI
Feature-focused testing workflows
Execute first-run setup
Define and execute a test flow
Repair and fix test flows
Generate test cases or code
Retrieve a session artifact
iOS-specific operations
Manage QA issues and observations
Check status of a running job
Control Metro bundler for React Native
Run mobile app audit checks
Control network conditions
Add a note to the session
Create a QA plan
Prepare iOS target device/simulator
Prepare target device/emulator for testing
Generate a test report
Resolve build artifacts
Resolve target device/simulator
Record screen activity
Capture a screenshot from the target device
Run smoke tests
Capture a snapshot of the app state
Start a new QA session
Manage test suites
Manage durable test suites
Generate a test for the current screen
Wait for conditions
WebDriverAgent control for iOS
Most tools accept only sessionId parameter with no additional inputs documented. Tools like qa_plan, qa_doctor, qa_capabilities have empty or minimal input schemas, making them inflexible and forcing agents to guess required context.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot distinguish safe reads from destructive writes. qa_bundletool (install:true), qa_build, qa_app_control should be marked destructive.