Skip to main content
Glama
Sign In
Swipium

Swipium

by GeroPalombo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Mobile QA release audit

qa_mobile_audit

Run mobile app release-readiness audits in plan or execute mode, covering smoke, account lifecycle, store compliance, resilience, and full release gates; log failed or blocked checks with evidence.

Instructions

Release-readiness audit: plan (default, no device) or execute. profile: smoke, account_cycle (create/logout/login/reset on a disposable account), store_compliance, resilience (offline/relaunch/rotation; airplane mode is consent-gated), release_gate (all). execute needs a prepared session, logs failed/blocked checks to the issue ledger, passes nothing without evidence.

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": {
      "profile": "<profile>"
    },
    "name": "qa_mobile_audit"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNo
approveNo
profileYes
consentIdNoexecute: consent for the airplane-mode toggle.
sessionIdNo
targetAppNo
offlineModeNoresilience: drive offline state.
projectRootNo
sourceRevisionNo
allowGeneratedDataNoRequired for account_cycle.
allowTestAccountDeletionNoPermit deleting disposable test accounts (never a real account).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only give a coarse safety profile (readOnly=false, destructive=false, idempotent=false); the description adds real behavior: execute requires a prepared session, failed/blocked checks are written to the issue ledger, airplane-mode toggling is consent-gated, and results are evidence-gated. It does not disclose whether execute blocks or returns a job handle, which matters given the qa_job_status sibling.

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?

Dense but front-loaded: the mode distinction comes first, then the profile catalog, then execution requirements. Telegraphic phrasing like 'release_gate (all)' and 'passes nothing without evidence' is efficient, though the abbreviation occasionally costs a little clarity.

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

Completeness3/5

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

For an 11-parameter, mutation-capable tool with a nested object and no output schema, the description covers mode, profiles, prerequisites, and the ledger side effect but says nothing about the return shape or execution lifecycle (blocking vs. job-based). An agent could still call it, but would be uncertain about what to expect after invocation and what 'approve' gates.

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?

With 36% schema coverage across 11 parameters, the description meaningfully interprets the two most important ones: it defines mode's two values and gives semantics for all five profile enum values, and links consentId to the airplane-mode toggle and sessionId to 'prepared session'. However, approve, targetApp, projectRoot, sourceRevision, allowGeneratedData, and allowTestAccountDeletion receive no explanation in the description, leaving half the surface undocumented.

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?

The description opens with a specific verb+resource: 'Release-readiness audit' with plan/execute modes, and enumerates the five profiles with brief parenthetical semantics. It is unambiguous what the tool does, though it never names a sibling (e.g. qa_flow_check, qa_first_run) to differentiate scope.

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?

It distinguishes the two modes clearly ('plan (default, no device) or execute') and states the prerequisite for execution ('execute needs a prepared session'). Profile descriptions imply when each is appropriate, but there are no explicit when-not conditions or pointers to alternatives for individual checks.

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