Execution

This page is generated from the live QualityMax MCP registry. Examples use placeholders; replace them with values for your workspace.

`accept_pending_tests`

Purpose

Accept pending test proposals for a project, writing them into the framework. Can accept a single test or all proposed tests.

Parameters

Parameter	Type	Required	Description
`project_id`	`integer`	Yes	Project ID
`pending_test_id`	`string`	No	Specific pending test ID to accept (omit to accept all proposed tests)

Return shape

The live registry does not declare a response schema. Expect a tool-specific JSON result and handle success, error, and result fields defensively.

Worked example

{
  "arguments": {
    "project_id": 1
  },
  "tool": "accept_pending_tests"
}

`apply_patch_and_run`

Purpose

Patch an automation script and immediately re-run it, returning one compact result. Use this instead of update_script followed by run_tests: it collapses the fix-and-verify loop into a single round trip. Continue iterating when the failure is a test defect; preserve assertions when the evidence indicates an application defect.

Parameters

Parameter	Type	Required	Description
`script_id`	`integer`	Yes	Automation script ID to patch and run
`patch`	`array`	Yes	Anchored edits applied in order; each old_string must match exactly once unless replace_all is set.
`expected_version`	`string`	No	Reject the patch if the script changed since this version was read
`base_url`	`string`	No	Base URL for the application under test
`auth_profile_id`	`integer`	No	Secret-free project auth-profile reference
`execution_service`	`string`	No	Execution service; auto selects the compatible managed runner
`headless`	`boolean`	No	Run in headless mode
`include_logs`	`boolean`	No	Include full stdout/stderr and console logs
`include_trace`	`boolean`	No	Include trace details
`include_artifacts`	`boolean`	No	Include safe unsigned legacy artifact links and opaque receipt references (no resolver)

Return shape

The live registry does not declare a response schema. Expect a tool-specific JSON result and handle success, error, and result fields defensively.

Worked example

{
  "arguments": {
    "patch": [],
    "script_id": 1
  },
  "tool": "apply_patch_and_run"
}

`get_execution`

Purpose

Get a test execution’s status, timing, and outcome. Log entries and artifact paths are counted by default and returned only when explicitly requested. Safe unsigned legacy links are separate from opaque receipt references, which have no download resolver.

Parameters

Parameter	Type	Required	Description
`execution_id`	`string`	Yes	Execution ID (e.g., exec_123_1234567890) or result_id (integer)
`include_receipt_details`	`boolean`	No	Include versioned receipt lineage, revisions and terminal evidence
`include_logs`	`boolean`	No	Return the full log entries instead of just a count
`include_artifacts`	`boolean`	No	Return safe unsigned legacy artifact links and opaque receipt references (no resolver)

Return shape

The live registry does not declare a response schema. Expect a tool-specific JSON result and handle success, error, and result fields defensively.

Worked example

{
  "arguments": {
    "execution_id": "your-execution-id"
  },
  "tool": "get_execution"
}

`run_native_test`

Purpose

Run a Rust (cargo test) or Go (go test -json ./...) automation script and return a normalized result with console_logs, passed/failed/total, stdout, stderr, and a duration. Use this when you have a compiled-language script (framework: rust_cargo or go_test) and want the native runner path. For Playwright / pytest scripts, use run_tests instead.

Parameters

Parameter	Type	Required	Description
`script_id`	`integer`	Yes	Automation script ID. Framework is read from the script record.
`base_url`	`string`	No	Optional BASE_URL exported to the test subprocess (for integration tests).

Return shape

The live registry does not declare a response schema. Expect a tool-specific JSON result and handle success, error, and result fields defensively.

Worked example

{
  "arguments": {
    "script_id": 1
  },
  "tool": "run_native_test"
}

`run_tests`

Purpose

Execute tests and return a compact result. For maximum test effort, continue the autonomous loop from get_test_capabilities after each result: diagnose failures and then cover the next gap. Supports Playwright tests or verified generated Appium mobile flows and returns a compact per-script summary (status, duration, failure reason, next action). Worker-backed runs are asynchronous; poll get_execution using the returned execution_id. Full stdout/stderr, traces, and artifact paths are opt-in — request them only when the compact failure is not enough to act on.

Parameters

Parameter	Type	Required	Description
`script_ids`	`array`	Yes	List of automation script IDs to execute
`environment`	`string`	No	Environment to run tests in
`base_url`	`string`	No	Base URL for the application under test
`auth_profile_id`	`integer`	No	Project auth-profile reference for managed Playwright execution; credentials are never returned
`execution_service`	`string`	No	Execution service; auto selects the compatible managed runner
`android_app_package`	`string`	No	Optional Android package override for managed Appium scripts
`android_app_activity`	`string`	No	Optional Android launch activity override for managed Appium scripts
`mobile_test_data`	`object`	No	Runtime values declared by the canonical mobile flow; values are never persisted
`headless`	`boolean`	No	Run tests in headless mode
`include_logs`	`boolean`	No	Include full stdout/stderr and console logs
`include_trace`	`boolean`	No	Include trace path and trace id
`include_artifacts`	`boolean`	No	Include safe unsigned legacy artifact links and opaque receipt references (no resolver)

Return shape

The live registry does not declare a response schema. Expect a tool-specific JSON result and handle success, error, and result fields defensively.

Worked example

{
  "arguments": {
    "script_ids": []
  },
  "tool": "run_tests"
}

`test_deployed_environment`

Purpose

Test a deployed environment end-to-end. Discovers the UI, generates a Playwright test, and executes it. The run is ephemeral unless project_id is provided, in which case a linked test case, script, and result are saved. Returns pass/fail with test code and screenshots.

Parameters

Parameter	Type	Required	Description
`url`	`string`	Yes	URL of the deployed environment to test (e.g. https://my-app.preview.example.com)
`description`	`string`	Yes	Natural language description of what to test (e.g. ‘verify the users table displays 25 users with name, email, role and date columns’)
`max_steps`	`integer`	No	Maximum navigation steps for discovery (default: 15)
`timeout`	`integer`	No	Test execution timeout in seconds (default: 60)
`project_id`	`integer`	No	Project ID to save the generated test into. When provided, a test case, linked script, and execution result are persisted, making the script available for Insert Tests Into Repo.

Return shape

The live registry does not declare a response schema. Expect a tool-specific JSON result and handle success, error, and result fields defensively.

Worked example

{
  "arguments": {
    "description": "your-description",
    "url": "https://example.com"
  },
  "tool": "test_deployed_environment"
}