> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/mcp-server/tool-reference/support-and-migration.md).

# Support-to-Fix & Migration

MCP tool reference for ticket-driven bug reproduction, failure investigation, analytics coverage gap analysis, and test suite migration in ContextQA.

## Quick answer

MCP tool reference for ticket-driven bug reproduction, failure investigation, analytics coverage gap analysis, and test suite migration in ContextQA. Use this reference to choose the appropriate tools, understand their required inputs, and interpret their user-visible outputs.

## What this page covers

{% hint style="info" %}
**Who is this for?** SDETs, developers, and DevOps engineers integrating ContextQA with AI coding assistants (Claude, Cursor) or CI/CD pipelines.
{% endhint %}

This reference covers three groups: support-to-fix tools that turn support tickets and failure evidence into actionable tests, analytics and coverage tools that identify untested high-traffic flows, and migration tools for importing existing test repositories into ContextQA or exporting back to Playwright.

***

## Support-to-Fix

***

## reproduce\_from\_ticket

Creates and immediately executes a test case that reproduces the bug described in a support ticket or issue description; use this to verify a reported defect is reproducible before assigning it to an engineer.

**Category:** Support-to-Fix | **Authentication required:** Yes

### Parameters

| Name          | Required | Type   | Description                                                                                                                                           |
| ------------- | -------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| ticket\_text  | ✅        | string | Full text of the support ticket, bug report, or issue description. Include steps to reproduce, expected behaviour, and actual behaviour if available. |
| url           | ✅        | string | Base URL of the application where the bug should be reproduced.                                                                                       |
| name          | ❌        | string | Display name for the generated test case. Defaults to a name derived from the ticket text.                                                            |
| persona\_id   | ❌        | string | Custom agent persona to use during reproduction. Obtain from `list_custom_agents`.                                                                    |
| knowledge\_id | ❌        | string | Knowledge base to attach for domain context. Obtain from `list_knowledge_bases`.                                                                      |

### Returns

JSON with the created `test_case_id`, the generated test steps, and an `execution_id` for the immediate run. Use `get_execution_status` to monitor the reproduction result.

### Example

```json
{
  "ticket_text": "User reports they cannot complete checkout when using a promo code. Steps: 1) Add item to cart, 2) Proceed to checkout, 3) Enter promo code SAVE10 in the promo field, 4) Click Apply. Expected: discount applied and total updated. Actual: page freezes and shows a spinner indefinitely.",
  "url": "https://staging.example.com",
  "name": "Reproduce: Promo code freezes checkout"
}
```

### Related Tools

`investigate_failure`, `create_defect_ticket`, `execute_test_case`, `get_execution_status`

***

## investigate\_failure

Collects available evidence for a failed test result and returns the investigation bundle. Inspect the fields and artifacts actually returned; complete telemetry and a fixed response schema are not guaranteed.

**Category:** Support-to-Fix | **Authentication required:** Yes

### Parameters

| Name       | Required | Type    | Description                                                                                                                                                                        |
| ---------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| result\_id | ✅        | integer | Numeric ID of the failed test case result to investigate.                                                                                                                          |
| rerun      | ❌        | boolean | If `true`, can request a new execution after collecting the original evidence when its test-case ID is available. Defaults to `false`; a rerun request is not a completed verdict. |

### Returns

The evidence returned by the collection service, serialized as JSON, or an error. When rerun is requested, an additional rerun response or explanation may be present. Read the original evidence first and retrieve any new execution’s final result separately. See [finding and fixing flaky tests](/reporting/flaky-test-detection.md) for a workflow that preserves both attempts.

### Example

```json
{
  "result_id": 1042,
  "rerun": false
}
```

### Related Tools

`reproduce_from_ticket`, `get_root_cause`, `get_test_step_results`, `get_console_logs`, `get_network_logs`, `get_trace_url`, `get_ai_reasoning`, `create_defect_ticket`

***

## Analytics & Coverage

***

## analyze\_coverage\_gaps

Queries a connected product analytics integration to find high-traffic user flows that have no corresponding test coverage, returning a prioritised gap analysis for test creation.

**Category:** Analytics & Coverage | **Authentication required:** Yes

### Parameters

| Name                | Required | Type   | Description                                                                                                                                                              |
| ------------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| analytics\_provider | ✅        | string | Name of the analytics integration to query. Accepted values: `"mixpanel"`, `"amplitude"`. The integration must be configured in ContextQA workspace settings before use. |

### Returns

JSON with a `gaps` array ordered by traffic volume. Each item includes `flow_name`, `page_path`, `event_count` (30-day), `suggested_test_description`, and a `coverage_score` (0–100, where 0 means no tests at all). Also includes a `summary` with total uncovered sessions and estimated risk exposure.

### Example

```json
{
  "analytics_provider": "mixpanel"
}
```

### Related Tools

`generate_tests_from_analytics_gap`, `get_ai_insights`, `create_test_case`

***

## Migration Platform

***

## analyze\_test\_repo

Analyzes a repository available to the configured execution environment to detect its framework, enumerate test files, and estimate the test count. Confirm filesystem access and the current tool schema before calling it.

**Category:** Migration Platform | **Authentication required:** Yes

> **Execution boundary:** A path supplied to a hosted MCP tool is not automatically a path on your laptop. Confirm which service reads the repository and how it receives access. Do not assume analysis stays local or that signing in grants remote filesystem access. Analyze before migrating, then review the dry-run output.

### Parameters

| Name       | Required | Type   | Description                                                                  |
| ---------- | -------- | ------ | ---------------------------------------------------------------------------- |
| repo\_path | ✅        | string | Absolute repository path accessible in the configured execution environment. |

### Returns

JSON with `detectedFramework` (e.g. `"cypress"`, `"playwright"`, `"selenium"`, `"jest"`), `language`, `testFiles` (array of relative file paths), and `estimatedTestCount` (integer).

### Example

```json
{
  "repo_path": "/home/dev/projects/my-app/e2e"
}
```

### Related Tools

`migrate_repo_to_contextqa`, `export_to_playwright`, `query_repository`

***

## migrate\_repo\_to\_contextqa

Parses an accessible test repository and creates ContextQA test cases. Use `dry_run=true` first to preview the conversion without creating cases. Review assertion and fixture coverage; parsing is not proof of equivalent execution.

**Category:** Migration Platform | **Authentication required:** Yes

### Parameters

| Name       | Required | Type    | Description                                                                                                                                               |
| ---------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| repo\_path | ✅        | string  | Absolute repository path accessible to the migration service; not automatically your coding client's local path.                                          |
| app\_url   | ✅        | string  | Base URL of the application under test. Used to contextualise migrated steps.                                                                             |
| framework  | ❌        | string  | Override the auto-detected framework. Useful when detection is ambiguous. Accepted values: `"cypress"`, `"playwright"`, `"selenium"`, `"jest"`.           |
| dry\_run   | ❌        | boolean | If `true`, returns a preview of what would be migrated without creating anything in ContextQA. Defaults to `false`. Always run with `dry_run=true` first. |

### Returns

JSON with `migratedCount` (integer), `skippedCount` (integer), `createdTestCaseIds` (array of integers), and a `summary` message. In dry-run mode, `createdTestCaseIds` is empty and `migratedCount` reflects the projected count.

### Example

```json
{
  "repo_path": "/home/dev/projects/my-app/e2e",
  "app_url": "https://staging.example.com",
  "dry_run": true
}
```

Once the dry-run output looks correct, re-run with `"dry_run": false` to complete the migration.

### Related Tools

`analyze_test_repo`, `export_to_playwright`, `get_test_cases`

***

## export\_to\_playwright

Generates a Playwright project for explicitly selected cases and returns a JSON file manifest. A coding client with authorized filesystem access can save the returned files locally. The hosted tool does not write them onto the developer's computer.

**Category:** Migration Platform | **Authentication required:** Yes

### Parameters

| Name            | Required | Type              | Description                                                                               |
| --------------- | -------- | ----------------- | ----------------------------------------------------------------------------------------- |
| test\_case\_ids | ✅        | array of integers | Explicit nonempty list of cases to export. Do not omit it to request the whole workspace. |
| project\_name   | ❌        | string            | Project name. Inspect the returned manifest for generated filenames and configuration.    |

### Returns

JSON with `project_name`, `file_count`, `files` (entries containing `path` and `content`), and `summary`. Inspect the actual manifest; do not assume a TypeScript-check configuration or a local output directory was created. Save only relative paths inside an approved empty directory, reject path traversal, and review sensitive files before sharing.

### Example

```json
{
  "project_name": "storefront-tests",
  "test_case_ids": [10, 11, 12, 45, 46]
}
```

### Acceptance limits

The current generator can emit non-blocking `aiVerify` placeholders that assume success, manual `aiAgent` checkpoints, assumed-true conditional branches, loops rendered once, and plaintext values in `credentials.env`. A green run is insufficient until required assertions and control flow are restored and credentials use approved secret handling. `AI_STEP_MODE=fail` rejects manual checkpoints but does not repair assumed-success verification.

Follow [export and portability](/testing-with-ai-coding-agents/export-and-portability.md) to review every gap and validate a clean standalone run plus a seeded-defect failure before using the export as release evidence. This reference describes the reviewed implementation; your connected manifest remains authoritative for current parameters and availability.

### Related Tools

`migrate_repo_to_contextqa`, `analyze_test_repo`, `export_test_case_as_code`, `get_test_cases`

***

## Related documentation

[MCP tool reference overview](/mcp-server/tool-reference.md) · [Test generation tools](/mcp-server/tool-reference/test-generation.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/mcp-server/tool-reference/support-and-migration.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
