qa-mcp-server

Overview Schema Source Related Servers Discussions Admin

run_test_suite

Runs a pre-configured Android test suite by name and optional device serial, using only server-declared suites with fixed arguments and exporting the serial for the run.

Instructions

Run a pre-configured test suite by name (exported ANDROID_SERIAL = serial). Only suites declared in the server config can run; arguments cannot be changed.

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

Input Schema

Name	Required	Description	Default
`name`	Yes	Name of a suite configured by the server operator.
`serial`	No

Output Schema

Name	Required	Description	Default
`name`	Yes
`junit`	No
`passed`	Yes
`dry_run`	Yes
`exit_code`	Yes
`truncated`	Yes
`duration_s`	Yes
`output_tail`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnly=false, destructive=false and closed-world, so safety is covered. The description adds real context beyond them (the serial is exported into the test process as ANDROID_SERIAL, suites are operator-configured and immutable), but says nothing about runtime, blocking behavior, or what happens on test failure.

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 tight sentences with the main action and its hard constraints front-loaded. The parenthetical '(exported ANDROID_SERIAL = serial)' is efficient but slightly cryptic in its telegraphic phrasing.

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?

With an output schema and annotations present, the safety and return-value burden is lifted, and the config/immutability constraints are stated. However, for a test-runner the agent still lacks the operationally important detail of whether the call blocks and how long a suite typically takes.

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?

At 50% schema coverage, the description compensates usefully: it explains that `name` must match an operator-declared suite and that `serial` is injected as the ANDROID_SERIAL environment variable, a mapping the schema does not state. It still leaves the serial pattern constraints to the schema.

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 pre-configured test suite by name. That is plainly distinct from the device-control siblings (tap, screenshot, install_apk), though it never names an alternative or explains how it relates to launching apps.

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 a clear context constraint: only suites declared in the server config can run, and arguments cannot be changed, which steers the agent away from trying to parameterize a run. It stops short of stating prerequisites such as needing a connected device or what to do if the named suite is unknown.

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

Deploy Server